Nonvolatile Storage

NonVolatile storage allows the user to retain data whilst the Target is turned off (un-powered). The data is available for use once power is restored. The storage device used varies across targets and have different sizes and performance. Typically storing data to the devices is many times slower than for RAM (Volatile) storage. Therefore the NonVolatile data is loaded into RAM (Volatile) on Target boot, allowing the user fast read and write access.

Data is saved back to the NonVolatile store on demand via the Store NonVolatile block. Typically this block is executed during Key Off shutdown via the Main Power Relay Driver (MPRD) block.

Data is saved on-demand because NonVolatile storage devices typically have limited write cycles (endurance). Once the endurance of the device has been exceeded it may become unreliable leading to corrupt data read. The endurance of the NonVolatile storage in each Target is different and should be considered in the application design to ensure operation is within safe limits. Due to endurance limitations MotoHawk provides mechanisms to detect and take action on errors.

NonVolatile storage types

Two types of NonVolatile DataStore Definitions are available.

NonVolatile

The NonVolatile data type provides a system that ensures the stored NonVolatile data is compatible with the runnning application. It does this by recording the 'Format' or structure of the data along with the data. A compatibility check is performed on power-up to ensure compatibility. This allows updated applications to be re-programmed whilst retaining the NonVolatile data if so desired. If an upgraded application has fewer, more or altered size NonVolatile variables it will be deemed incompatible and factory defaults will be applied.
Note:If Fixed NonVolatile variables are added or removed, the NonVolatile area gets relocated. This results in factory defaults being applied to the NonVolatile data.

Behaviour options are configured via the NonVolatile Definition block.

Fixed NonVolatile

The Fixed NonVolatile data type allows the user to specify the order and location of Fixed NonVolatile variables via the Fixed NonVolatile Manager Definition block. There is no compatibility check and therefore relies on the user to ensure that and upgraded application can interpret the stored data and is compatible with the new application. This allows for greater flexibility such that new Fixed NonVolatile data items can be added such that on upgrade the remaining Fixed NonVolatile data can be retained. The Fixed NonVolatile Manager block must be present in the model in order to support Fixed NonVolatile DataStores.

Buffering

Varying buffering mechanisms are available that provide enhanced reliability and protection at the expense of resource consumption.

Single Buffering

Single Buffering is the default operation for most Targets. Only one copy of data is retained in the NonVolatile storage.

Only use single buffering if there is insufficient storage available in double buffer mode and the data stored is not critical.
Single buffering can be subject to data loss and corruption under some conditions (see below)

Features:

Non Volatile

All NonVolatile memory region area is available for data
Data can be corrupted if power is removed during a Store operation.
Factory defaults are applied if corruption occurs (due to unexpected power loss or device failure)

Fixed Non Volatile

All NonVolatile memory region area is available for data
Data can become incoherent or corrupted if power is removed during a Store operation.
Corruption or incoherency due to unexpected power loss or device failure are not reported or actioned by the system.

Double Buffering

Double buffering ensures that data cannot be corrupted due to an expected power down. It splits the NonVolatile storage memory in half and stores two copies of the data. A data bank is only marked as 'good' once a Store operation is complete. Therefore the user is guaranteed to have valid data on power up.

Note: It is strongly recommended that double buffering be used in all applications for the above reason.

Double Buffering is automatically enabled on some Targets (Notably LECM) and no further action needs to be taken. For other targets a Buffered NonVolatile EEPROM Definition block enables the feature.

Features:

Non Volatile

NonVolatile storage area available is approximately half of the available memory region area.
Data is protected from unexpected power loss during save.
If a device failure occurs, the system will use the other 'good' data bank (where possible)
Data reverts to factory defaults if both banks of data become corrupted due to device failure or software incompatibity.

Fixed Non Volatile

Fixed NonVolatile storage area available is approximately half of the available memory region area.
Data is protected from unexpected power loss during save.
If a device failure occurs, the system will use the other 'good' data bank (where possible)
Data reverts to factory defaults if both banks of data become corrupted due to device failure or software incompatibity.

Status and Failure management

MotoHawk provides NonVolatile Status and Fixed NonVolatile Status blocks that allow the user to query the state of the non-volatile storage. it reports current activity, error status and action taken if error.

Special considerations

The user should be aware that the Store NonVolatile block takes a finite time. The application is permitted to continue executing, and therefore to mantain Data Coherency the user must avoid altering NonVolatile data during the store process.

Factory Defaults

An application specifies initial values for data in the MotoHawk model (See DataStore Definition). These values are termed the factory defaults.

Factory defaults are applied when:

The system is unable to recover valid data.
Via Instrumentation Tool parameters
The NonVolatile Restore block. (Does not apply to Fixed NonVolatiles)

Nonvolatile Storage