In the first part, we talked about strategy that we can incorporate in the NVM manager to avoid corruption of NVM blocks. In the present article, we will talk about some other concepts to about NVM corruption.

During the transmition of data by some specific medium, there is the posibility that the data was damaged or corrupted. To validate that the data has no damage, there are different validations methods, such as CRC, Hammings bits or RAID 5; those types of validations depends of the robustness that the system requires.

If we decided to use checksums in the microcontroller, we need to be aware that is much better to use checksums in small units of NVM (NVM blocks that are defined based in the functionality they have). This is because, if we use a checksum in large units of NVM, a simple mismatch of a few bits will produce a throwing of the whole unit of NVM, which in short term affects directly the CPU load and in long term affects the wearing out of NVM cells.

The moments where we need to validate the NVM is in certain time than the microcontroller is reset or whenever the physical NVM or the shadow RAM (if there is one) changed.

Talking about the shadow RAM, it is necessary always refresh the shadow RAM in every microcontroller initialization and periodically depending of the functionality of the NVM block whose it is related.

When we use redundancy to validate NVM data, usually is a good idea, if the NVM size permits it, to use three copies of the same data. This approach is better because if it detects that 2 copies are similar but the third one is corrupted, then it can refresh just the corrupted NVM copy instead of refreshing all the NVM copies (behavior that happens when we use two copies).



Leave a Reply

Your email address will not be published.