NVM stands for Nonvolatile Memory; it is a subset of memory types that retains its value even when the power supply of the chip gets lost.
In this article we will talk about NVM blocks. If you like to have more information about memories, look at the Embedded Systems::Memory article.
Depending of the type of NVM memory, you have the smallest number of bytes that can be erased in a single operation, this is called NVM cell. Modifying NVM cells can be either by the application SW or from a “tester” device. If the NVM can be modified on anytime by the application, the data must be stored in an EEPROM-like device; this is called Functionally Dynamic NVM. If in contrast, the NVM can be modified only by the tester by uploading “configuration files” into Flash. These configurations are compiler constants.
When you are managing a NVM memory, you will save related data in blocks. So called NVM blocks are instances of NVM memory that contains a set of data that the developer defined to be together.
Each NVM block might obtain several attributes thru managing as for example:
- NVM blocks can have RAM image that makes easier the access (read and write).
- If a NVM block has a RAM image, then this RAM image can be secured by application thru periodic checks against a defined content.
- Each NVM block can have a guarantee of consistency by CRC16 or CRC32.
- NVM blocks can have data redundancy, meaning, multiple instances of data items are located in memory as a backup if one of them became invalid. If for example during a modification, there is an interruption in the writing process, then the NVM unit can be contradictory, so the system has a backup of the data to use. This is often necessary for Functional Safety related modules. Usually, data redundancy uses different physical areas to store the same data value.
- NVM blocks have priority over others.
- You can define write protection for each NVM block.
- If there is a SW mapping change over the NVM, you can define NVM blocks that can maintain their value in these mapping changes.
- NVM blocks can be stored in a dataset. This dataset is defined by the developer which usually wants heterogeneous data for a specific functionality access.
The NVM block can be saved in the NVM specific location (primary location), in the RAM image (easy access to the application, and sync with the primary location), and optionally in ROM (default values that are only accessed by application – used to restore NVM blocks during initialization).
NVM Block Sizes
In practice, it is not a good choice to have large NVM blocks, for example, if we have a NVM block with low priority which is large, and then it will delay the writing of higher priority NVM blocks producing serious failures in the system. Other reason is that maybe there are changes in only one or two bytes and having a large NVM block will make the whole block to be refreshed. If there is the use of pages to simulate EEPROM in Flash, making NVM block too large will make the effect of an elephant in small room. This means that large NVM blocks will make page swap more frequent, affecting the CPU load directly. Nevertheless, take care of making NVM block too small, because this will produce an increase in the NVM configuration tables.