In previous articles, we talked about type of memories and the concept of NVM blocks. Having cleared these themes, we can start talking about several concepts that are important in the NVM managing.
As we described in the article of NVM blocks, functionally dynamic NVM is controlled by application. Application can have access to this NVM type anytime. This type of storage shall be on EEPROM
The managing of this type of NVM came with several concerns; first we need to be very aware of how NVM shall response in the fluctuations of voltage in the power supply.
There are systems that need to survive a temporary power outage without turning off and making a reset, usually within this surviving you need to identify and report promptly the outage; making actions to prevent damage in components and/or extend the time of survival.
You might want to define a strategy to allow/disallow writing of NVM blocks based in the voltage in the power supply. It is a good idea to have an “upper limit” range of voltage where it is permitted to have NVM modifications. For example, 10 V… Maybe your system can stand above 6 v, but disallowing the NVM modification at 10V then you avoid the corruption of NVM during a quick voltage decrease to nonfunctional voltage range and give the system enough time to write the NVM block. By the way, this is another good reason to avoid large NVM blocks as the system lasts more writing them.
Another good idea is to notify the completion of NVM blocks modifications to determine if an NVM update is complete (though you can have several protections as redundancy) making the HW to supply enough energy. This concept is called coherency, normally we use CRC-16 or CRC-32 to compare the target and source of data to have notion that the data was transmitted/stored correctly. Depending of your strategy you can use a flag, simple checksum or a sequential number instead of the CRCs.
The NVM manager shall hold the change of state of the microcontroller until the NVM finish its updating, for example the NVM manager stop the Warm reset and verifies the NVM updating to turn off the microcontroller and report the Warm Reset.
NVM also need be update with the priorities by the NVM manager. The developer should sort the NVM blocks based in the importance of each NVM block. This strategy ensures the quickest updating of the importance NVM blocks and gives flexibility to throw some information that are not that important. Also take in account that this strategy is used along with tasks of single NVM blocks updating to reduce the CPU load. For example, the refreshing of the block from a low priority peripheral can be updated in low frequency (an event or 160 mS for example).
The last opinion for today discussion, it is that the memory has to be watched out for wearing out. NVM has a lifetime, if we modify the data of NVM cells often, in some point, that NVM cell might start malfunctioning (Sometimes the NVM cell starts returning invalid values when they are red). To prevent the wearing out of NVM, we need to understand how many times the specific item is modified and determine if it can last more than the lifetime of the system. Also, there are solutions to prolong the lifetime of data in a NVM cell, for example, one that is useful is the use of multiple buffers to determine if a NVM cell is wearing out.