How NvM Works Internally

Learn what happens to your NvM variable from the moment you write it

NvM (Non-Volatile Memory) is a specific type of memory that gets "somehow" stored at a certain point in time, in such a way that after a soft or a hard reset, the values you wrote are magically... there! If you are like us and do not like black magic, today is the time when we find out what happens to your variable from the moment you write it until the moment your code reads it back, a few power cycles later.

So, we already have overviewed NvM, in our article NvM Overview (opens in a new tab). Feel free to take a look into it, as we will complement on the knowledge from there, although, it's not mandatory. Let's start from the bottom, just like a Drake song.

• Non-Volatile Memory - NvM a memory that keeps its information when power is absent, as opposed to volatile memory, which loses all of its information when it gets powered off. The Autosar NvM module we know, uses this in the background. Of course, you might be wondering "can we not replace all the SRAM and DRAM with NvRAM?", well, while that could be a possible end goal in computing, NvRAM capabilities are not there, yet. These memories have further limitations in memory size, energy consumption and life cycle that make them inadequate as the primary memory of a system. The most common type found in classic Autosar ECU's is EEPROM (Electrically Erasable Programmable ROM), which is ROM organized in floating-gate transistors.

• Initialization of RAM blocks - As we have mentioned in our previous article about the NvM, we have two regions at play: one from RAM and one from our non-volatile memory. At startup, the NvM blocks get written into RAM, to the variables we are using in runtime, via the API NvM_ReadAll. This API is called by the BswM (BSW Mode Manager), so you don't need to worry about it too much. You can learn more about this module in our article BswM Overview (opens in a new tab), where we show you the importance of this module and its internal structure.

• Writing to a RAM block - When we write to a variable that is stored in an NvM block, we are actually writing to a regular variable in RAM. This will lead to the NvM changing the state of our block, to symbolize that our NvM block is different than RAM, and yes, we have to be careful with concurrent access from multiple parts of our application. How do we propagate the changes to the NvM?

• Writing to the NvM - We can do this explicitly, after writing to our RAM variable, via the NvM_WriteBlock API and waiting patiently for feedback from the NvM module, or we wait for shutdown, as in shutdown the NvM_WriteAll API will be called by the BswM, writing back all the RAM changes to the NvM bloks.

Just as a final thought, the states for a RAM block in the NvM are described below:

FIM interaction with other modules, in the Autosar Layered architecture

Alright, now that you understand the internals of the NvM module, we hope you can tame this beast and use it to your advantage!

Author: Micael Coutinho (opens in a new tab)

References:

• Specification of NVRAM Manager (opens in a new tab)