Fundamentals of NVM in AutoSAR Part-1.
Published: 2024-01-30 11:39:17

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.
 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d7psp1yivvat80jk7vty.png)
 
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
 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/am4ay0uudebtgglhtxzh.png)
 
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.
 
 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/frjckne3mhp0hn4t0qtb.png)
 
 
**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.