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) when the module boots, allowing the user fast read and write access.

Data is saved back to the NonVolatile store on demand via the Store NonVolatile block. Typically the data only needs to be saved when the module Powers Off and therefore the application has conveniently been provided with the Main Power Relay Driver (MPRD) block which executes the Store and exposes a manual option to store via instrumentation tool control.

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 count the number of writes (Buffered NV - Age) and detect NonVolatile Status so that the application can 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 or more NonVolatile variables, of if any of those variables change in data type or array size, it will be deemed to be software 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, or with the Memory Region Definition block when Memory Regions are in use.

Fixed NonVolatile

Sometimes variables and their values must be retained through a programming cycle when new NonVolatile values have been added. To do this, the variables are defined as "fixed nonvolatile."

The Fixed NonVolatile data type allows the user to fix the 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 at the end of the list, and on upgrade the prior Fixed NonVolatile data can be retained. The Fixed NonVolatile Manager block must be present in the model in order to support Fixed NonVolatile DataStores.

MotoHawk does not allow an application to be built if the user has not acknowledged the order of all variables which are assigned as Fixed Nonvolatile.

Reprogramming a Module where Fixed Nonvolatile variables are added

Assume a module has a application X with some fixed nonvolatile memory content defined. Suppose a user wants to put application Y onto that module, that contains one new Fixed NonVolatile variable. When building the application Y, the user would add the new variable to the end of the Fixed NonVolatile list. The FixedNonVolatileRestoreOnFirstStartup calibration option would be set to “Load saved application values on next startup.” On reprogramming application Y, all of the prior saved Fixed NonVolatile variables from application X will be retained.

Note: Because the Fixed NonVolatile region has changed in size, the NonVolatile (storage type) area following it gets relocated. This results in factory defaults being applied to the NonVolatile data.

Reprogramming a Module where the Fixed Nonvolatile Space Changes

Assume a module has a program X with some fixed nonvolatile memory content defined. Suppose a user wants to put program Y onto that module, a program which defines a different fixed nonvolatile space than the residing program X (such as, if fixed nonvolatile space was added for the first time, more fixed nonvolatile variables were added, fixed nonvolatile variables were re-ordered via the manager block in the application, etc.). So, when program Y is loaded onto the module, the user would want to initialize the values of the fixed nonvolatile variables to their respective default values to avoid erroneous values taken from whatever may have been in that allotted memory space previously with program X. One way to do this is by the following example steps (assuming a Program X and Program Y as described previously):

Create an offline calibration from Program in MotoTune (select File -> New -> Calibration from Programming File).
Perform any transfer/upgrade as necessary from master calibrations, and save result as Ycal.
In the Ycal program in MotoTune, navigate to System/NonVolatile, and double-click on FixedNonvolatile Storage Config

Note: The FixedNonVolatileRestoreOnFirstStartup may be set to “Load saved application values on next startup.” This is typically the correct setting; this is what fixed nonvolatile is intended to do -- maintain values from the previous program. But in this case, there is a need to initialize those values to their default values. So, change setting for now to “Load factory defaults on next startup.”

Merge Ycal with Y, save as Ymrg.
Program Ymrg onto the module. Key-off the module, and then key-on. All fixed nonvolatile variables are initialized to their default values.
Change the FixedNonVolatileRestoreOnFirstStartup setting back to “Load saved application values on next startup,” so that if a user eventually does transfer/upgrade this cal to a new cal to be merged with a new program where the fixed nonvolatile space hasn’t changed, the values will be kept across the programming cycle.

Battery Input Considerations

Battery voltage (the voltage to the battery pin on the module, if available) has to be maintained for a period after a key-off is detected in the application in order to execute the shutdown processes which include saving variable values to nonvolatile memory. If battery power is lost before all of the variables can be written, nonvolatile variables may be corrupted, contain previous saved information or restored to their default values depending on the buffering scheme used.

When an application uses the MotoHawk MPRD block in its default configuration, the nonvolatile variables get saved when the application detects key-off.

Online and Offline NonVolatile variable updates

It’s important to note that changing NonVolatile parameters via an instrumentation tool when Online and Offline results in different behavior.

When Online, the RAM copy of the NonVolatile variable is altered, and it must be saved back to the storage device prior to full power down in order to preserve the values. (Typically on key-off by the MPRD block)

When Offline edits to NonVolatile variables are made, an alteration is made to the ‘Factory Default’ values that are merged back into a programming file.

Buffering

Several 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 many Targets. Only one copy of data is retained in the NonVolatile storage, and the entire storage device is available for data..

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)

Single Buffered NonVolatile regions can suffer data corruption if power is removed during a Store operation and factory defaults will be applied.

Single Buffered FixedNonVolatile regions can also suffer data corruption if power is removed during a Store operation but the 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 as it avoids the possibility of data corruption.

The space available for data storage is half the physical memory region size due to the need to maintain a copy.

There are currently two Double Buffer drivers, Legacy and Buffered NV. It is recommented that Buffered NV is used in preference has it supports additional status and data protection features. It can be enabled explicitly by using the Memory Region Definition block.

The Legacy double buffer driver is enabled using the Buffered NonVolatile EEPROM Definition block.

The Buffered NV driver is automatically enabled by default on newer Targets (Eg: LECM), and in those cases the Buffered NonVolatile EEPROM Definition is ignored and a build warning is produced.

For details of upgrading between drivers and how the drivers work, see Memory Region - Managing Non Volatile legacy help.

NonVolatile Data will revert to factory defaults only if both banks of data become corrupted or because of software incompatibility on upgrade. (see storage type description above)

FixedNonVolatile Data will revert to factory defaults only if both banks of data become corrupted.

Memory Region considerations

Originally MotoHawk was restricted to two regions of NonVolatile data, termed Fixed NonVolatile and NonVolatile. It became difficult to meet safety considerations and manage different kinds of data with different update and security requirements. Because of this Memory Regions support was added.

Memory Regions allow the physical Non-Volatile memory to be divided into arbitrarily sized sections and each assigned a controlling driver (Eg: Buffered NV) Each region can be Stored on demand indipendently and each mantains it's own status and configuration. This means that a user can divide the NonVolatile allocation into sections of different priority for example DataLogging, Critical Configuration parameters, Runtime data, Adaptive information, user configuration etc. This separate control largely negates the need to use Fixed NonVolatile storage type as finer control is available.

Example 1, a simple application X defines 70% of the physical memory as NonVolatile. Later application X is upgraded and additional NonVolatile data is required. In order to avoid resetting the original NonVolatile data to Factory Defaults, a new region can be allocated that is located following the existing region and built into application Y. When application Y is programmed, all the NonVolatile data from application X is preserved when application Y executes.

Example 2, Application X contains critical configuration data set on manufacture, datalogging information updated every 1min and Engine information saved each power down. Critical configuration data would be placed in a region, with Mirror mode set. Writes only occur on demand via instrumentation tool. DataLogging is a separate region updated regularly by the application. Because of frequent updates endurance limits could be reached, however datalogging is not considered critical and will not corrupt other data. Engine information would be in a third region, in standard double buffering mode saved on shutdown for the best endurance.

It is recommended that new applications make use of MemoryRegion support for greatest flexibility.

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. It is possible to use the NonVolatile Status Get block to determine if a Store NonVolatile operation is in progress.

Factory Defaults

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

Factory Default values can be edited offline and re-merged into a new programming file.

Factory defaults are applied when:

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

Nonvolatile Storage