 |
|
|
This MotoHawk™ block double buffers non-volatile data in a manner that will allow the application to recover from a bad EEPROM write sequence (for example, from an uncontrolled power down or EEPROM cell failure) through the use of a previously stored good copy. Half of the total EEPROM is sacrificed to achieve this functionality.
motohawk_buffered_eeprom
MotoHawk_lib/Data Storage Blocks
Saves non volatile data to half of an equally divided EEPROM. At each shutdown, the software will write the current key cycle's accumulated data to the half of EEPROM with the oldest non volatile data. This should ensure that there is always a backup of the non volatile data that is reloaded in the event that a non volatile write failure (like from a bad power down) or an EEPROM cell failure. When reprogramming, the developer can choose to either reload non volatile data from factory default settings, or re-use non volatile data from the previous program as outlined in Non Volatile Definition. If this block is added or removed from a model, or the CRC array size changed, it will cause a load of factory defaults for non-volatile and fixed non-volatile data after reprogramming.
Note 1: Some Targets support double buffering by default (E.g. LECM). In these cases this block and it's settings have no effect.
Note 2: Usage of the Buffered EEPROM block is not allowed with asynchronous data storage as defined in Non Volatile Definition.. Applications can use either buffered EEPROM, or asynchronous data storage.
Note 3: Not all Targets use EEPROM technology to support NonVolatile storage. Therefore perfomance and endurance ratings may vary.
| Parameter Field | Values | Comments/Description |
|---|---|---|
| Allow Localized Cell Failure | Checkbox | Leaving the check box unchecked means that a cell failure in EEPROM data (due to reaching the write cycle limitation of the EEPROM hardware), can and will be detected and the half of EEPROM the failure is found in, along with all its data will be disregarded. Checking the box will mean that cell failures in EEPROM data will not be detected. This would put the onus on the application to determine which data has failed and is no longer usable. Under this scenario, the good data still in EEPROM would continue to be updated. |
| Number of CRC Array Entries | Integer from 2 to 255 | Because the EEPROM writes only half of its memory every key cycle, the lifetime of the EEPROM hardware is increased by a factor of two. When this block is included in an application, the EEPROM will house a CRC array that is used to determine which half of EEPROM contains the most recent data, that data's CRC and whether EEPROM data was written properly. The CRC array is allowed to be sized based on the needs of the application. The number of indices in the CRC array should be more than the most frequently written EEPROM data, so that the first write cycle limitation failure of EEPROM occurs in the data and not the CRC array. The desire to have the first EEPROM failure in the data portion is twofold. One, this blocks usefulness is lessened if it reduces the lifetime of the EEPROM hardware to less than that of the data portion as would occur if the same index of the CRC array was written every key cycle, and two, the data in the CRC array is critical to proper operation of the EEPROM data and any cell failure in this area could cause the restoration of factory defaults even if both halves of the EEPROM contained good data. For example, if the application writes a piece of EEPROM every key cycle, the CRC array size can be as small as two. This will maximize the size of the EEPROM data portion by minimizing the size of the CRC array portion in EEPROM and still allow the EEPROM to have the lifetime gains mentioned earlier. If the application's most frequently written NVM is every ten key cycles, the number of CRC array entries should be at least ten. |
| Copyright 2009-2015 Woodward Corporation. All Rights Reserved. | Visit Us: mcs.woodward.com |