Fixed NonVolatile Variables
Contents
Fixed Nonvolatile Variables
This is a description of assigning variable values to nonvolatile and fixed nonvolatile memory locations, and how to change such values given the respective assigned memory attributes.
Nonvolatile Variables
What is a nonvolatile value? When a variable is defined as nonvolatile, this indicates the variable value that exists before a controller is turned off, is to be stored and retained so that it is still available after it is turned back on (key cycle). Physically, the variable would be stored in EEPROM, which can maintain information with power off (unlike RAM, which is volatile, that is, not retained with power off).
Upon the key-on event, the stored nonvolatile value is read from EEPROM and written into RAM (in the application, every nonvolatile variable also has a "shadow" variable in RAM). While the application runs, the RAM variable can be written to or read from as many times as necessary. Then, when the application detects a key-off, the application prompts the saving of that RAM variable back to EEPROM. This is a “controlled shutdown.” This practice reduces the need for EEPROM writes (which have about a 100k limit) so that data is only written to EEPROM on a key-off.
Note: A controlled shutdown (with the writes to EEPROM) is supported only if a power supply to the module other than that of the key switch (ECUP) is available to save these variables after key-switch power is lost; in the some modules, it is from the battery input. Also note that if all module power (key-switch and battery) is suddenly lost when the application runs, the value of the nonvolatile variable on the next key-on will be that as last saved during the last controlled shutdown.
If battery power is lost during the controlled shutdown procedure (that is, when data is being stored to EEPROM), all nonvolatile variables will revert to their default values (that as initialized in the application) to avoid corrupted data.
Fixed Nonvolatile Variables
What is fixed nonvolatile value? Sometimes variables and their values have to be retained not just through a key-cycle, but through a module reprogramming; to do this, the variables are defined as "fixed nonvolatile."
Physically, when fixed nonvolatile variables are defined, a portion of EEPROM is reserved for these variables; this is the fixed nonvolatile space. When a model is built with fixed nonvolatile variables, the programmed module reserves specific addresses in EEPROM for these variables.
For example, one of the first fixed nonvolatile variables was the RunTime variable. The application looks for the RunTime data in the exact same spot in EEPROM from the previous program. However, on the first program, the fixed nonvolatile space is initialized (through the Fixed Nonvolatile Manager block in the application) to its default values, because the previous program did not necessarily reserve that EEPROM address for RunTime. If one were to read from that memory at that time, the data most likely would not be correct. Also, on any subsequent program where the fixed nonvolatile space changes, it is necessary to re-initialize that data. Note that if battery power is lost during the controlled shutdown procedure when fixed nonvolatile variables are being stored, the values may be completely incorrect on the next key cycle because only a portion of the memory may have been written (there is no check to revert back to default values like the other non-fixed nonvolatile variables, as described above).
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: - 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
As mentioned previously, 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 off in order to execute the shutdown processes, including saving variable values to nonvolatile memory. If battery power is switched off or fades away before the variables can be written to nonvolatile, nonvolatile variables may revert to their default values and fixed nonvolatile variables may be only half-written (thus appearing “corrupted” on the next key-on).
In an application which uses the MPRD block in MotoHawk in typical fashion,* the nonvolatile variables get saved to the EEPROM when the application detects key-off ONLY (the MPRD block detects the key-switch off). Typically, power to the key-switch input “wakes” up the module and starts executing the application. When the key-switch is switched off and power is lost to the key switch input, the application can still run (if there is power to the module at a battery input). If a switch characterization in the model detects the key-switch off event, a shutdown process executes, which includes stopping the application and saving nonvolatile RAM shadows to EEPROM. This is the only way to save nonvolatile variables to EEPROM! So, for instance, if a program has several fixed nonvolatile variables change, if one then re-programs without a key-off/on sequence, the latest fixed nonvolatile values (that can be seen in MotoTune, which are the RAM values) will not appear because they were not saved.
* The user can configure the MPRD block for different behavior, if need be, which might not support the typical operation described here.
