Fundamentals of NVM in AutoSAR Part-1.
Kumar001repo
Posted on January 30, 2024
Hello Readers, 👋😃
My name is Shiva Kumar M, and I work at Luxoft India as a Junior Software Developer. Luxoft has given me several opportunity to work on various projects, which has inspired me to learn the essential processes involved in developing in the NVM in AutoSAR part-1.
Introduction
In AUTOSAR the NvRAM Manager (NvM) module is responsible, for managing the nonvolatile memory of the ECU. SWCs only interact with the NvM when it comes to reading from or writing to nonvolatile memory. The NvM takes care of all the abstractions and safeguards for the nonvolatile memory.
The MemIf module along with its underlying modules Ea and Fee handle the abstraction of memory devices within the ECU.
The NvM operates independently from the hardware. It treats nonvolatile memory as abstract memory blocks exclusively. Each block is assigned a handle (or block ID) number and administrative data.
Applications do not have access to nonvolatile memory. They rely on NvM to provide all interfaces. With these interfaces applications can only interact with a copy of the block stored in RAM. The NvM ensures consistency checks. Synchronizes data between RAM and NV memory.
The NvM interacts with AUTOSAR modules including;
EcuC; responsible for initialization startup and shutdown
SchM; responsible for scheduling during operation of the ECU
MemIf; responsible for accessing abstracted memory devices
Dem; responsible for logging faults related to NvM operations.
Crc; responsible for integrity and consistency checks on data
In addition to these modules NvM also interacts with modules such, as BswM, Det and Csm.
All software components (applications) that utilize volatile memory communicate with the Non Volatile Memory Manager (NvM) via the Runtime Environment (RTE).
An overview of the interactions, in the NVRAM Manager;
The NvM modules component model defines four types of Basic Storage Objects, which together constitute a block. These objects are defined by AUTOSAR as follows;
1. RAM Block; This represents the portion of the NvRAM block stored in RAM.
2. The NV Block represents the volatile section of the NvRAM block. 3. The ROM Block if included defines the default data, for the NV block. It is provided by the application.
4. The Administrative Block is a component of the NvRAM block that specifies its properties. This block is exclusively used internally by the NvRAM module. Is not accessible to any module outside of NvRAM Manager.
Block Management Types:
The NvRAM block supports types of Block Management as supported by AUTOSAR. These types include;
1. Native Block Management; This type comprises 1 NV Block, 1 RAM Block, 0 to 1 ROM Blocks and 1 Administrative Block.
2. Redundant Block Management; This type includes 2 NV Blocks, 1 RAM Block, 0 to 1 ROM Blocks and 1 Administrative Block. It provides data corruption resilience through having two copies of the NV block.
3. Dataset Block Management; This type consists of 1 to n (where n <256) NV Blocks, along, with a RAM Block, m (where m can be any number) ROM Blocks and an Administrative Block. A Dataset Block represents an array of blocks containing NV/ROM data elements. The application can only access one element from this dataset at a time.
NVRAM Component Model
The NVRAM Component Model is an aspect, in the initialization process of the NvM module within AUTOSAR. Before EcuM can proceed with this initialization it is crucial to ensure that all the modules that NvM relies on are properly initialized. The recommended approach is to start from the bottom and work our way up in terms of sequence.
This means initializing the device drivers for nonvolatile memory devices, followed by the communication drivers, for external nonvolatile devices.
First we need to set up the nonvolatile devices. After that we can initialize the nonvolatile memory abstraction modules such, as FEE/EA. Once the memory devices are prepared we proceed to initialize MemIf. Finally at the end NvM is. The non volatile memory is ready, for use.
The NvM initialization process consists of two steps.
- The first step involves initializing the state machine and queue of the NvM. Once this is completed the second step is to load all the nonvolatile (NV) data from memory to RAM. However depending on the data size this loading process can take an amount of time. It may not be ideal, for an ECUs initialization sequence to spend a time fetching all the data during power on. Therefore it is crucial to fetch the necessary blocks immediately upon power on.
To accomplish the step of initialization EcuM calls upon NvM_Init(). For the step both EcuM and BswM collaborate to invoke NvM_ReadAll(). This function queues all the NvRAM blocks that have been enabled with NVM_SELECT_BLOCK_FOR_READALL.
The function Then NvM_MainFunction() processes these blocks in a manner. Stores them, in the RAM. Before reloading the NV data of a block it first checks if the RAM block data is still valid. This validity can be ensured by having a checksum for each block. If the RAM data is valid the NV data won't be reloaded. During power on when there are no data, in RAM all the NV blocks will be loaded.
The BSW scheduler periodically runs NvM_MainFunction() which handles all queued jobs related to the NvM module.
State of RAM Block
RAM blocks have states that are defined by their validity (VALID/INVALID). Whether their content has been modified (CHANGED/UNCHANGED).
VALID/UNCHANGED
The state indicates that the information, in the RAM block matches the information in the NV block. A RAM block is considered to be in this state when the recent read or write operation was successful and there have been no indications of any changes from the application. This is the desirable state, for a RAM block.
This will continue in next article will with examples.
If you have any questions or comments, please let me know below.
Thank you for reading.
Posted on January 30, 2024
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.
Related
