1

AUTOSAR Memory Stack

(MemStack)
 2

Introduction to MemStack
 3

Introduction

Automotive applications need to retrieve stored information even after a

power cycle:
- Sunroof pisition,
- Seat position,
- Access key,
- Calibration data,
- Diagnostic messages,
- etc.

- Memory stack modules shall be provided by Basic Software in order to

ensure the data storage and maintenance.
 4

How to provide Non volatile memory

EEPROM Data Flash

Electrically Erasable
Programmable Read-Only Memory

Write Size Erase Size Write Size Erase Size

Granularity Granularity Granularity Granularity

Page size = Sector size Page size < Sector size

Typical values:
Page size = 4 or 8 Bytes
Sector size = Page size
Application data CAN be written always
at the same address
Typical values:
Page size = 4 or 8 Bytes
Sector size = e.g.16 kB
Application data CANNOT be written
always at the same address
 5

Below, you will find list of AUTOSAR MemStack modules:

 6

MemStack Architecture
 7

Non-Volatile Memory Manager (NvM)

 8

NvM overview:
NvM Manager manages all data requests to the EEPROM/Flash used as
non-volatile memory
• NvM offers the following features:
- Each block can be synchronized with a permanent RAM
area
- The block consistency can be guaranteed by CRC16 or
CRC32
- The blocks can be single (no redundancy), redundant (block
duplicated) or Dataset
(n different values of the same block with no redundancy).
- Priorization scheme: a priority can be assigned to each block
- Protection scheme: some blocks can be Write-protected or
Write-once
- Immediate protects important data
 9

What is a NvM block ?

• NvM block consists of:

- One or several NvM blocks (physical storage in non volatile memory – Eeprom or
Flash)
- One optional RAM Block, belonging to the application, that will be synchronized
with the NvM block
- One optional ROM block, belonging to the application, contains the default
contents (will be restored in the block in case of problems during the initialization)
 10

Read/Write request in NvM:

• Two ways:
- Synchronization on power transitions only
• All data are moved from NvM to RAM during LP to HP transition (ReadAll)
• The application works with the data in RAM and marks them as valid (to
be saved) or invalid (not to be saved). This is done with the API
NvMSetRamBlockStatus
• All the data marked as valid are saved to NvM during the HP to LP
transition (WriteAll)
- On-demand block Writes
• All data are moved from NvM to RAM during LP to HP transition (ReadAll)
• The data are written to NvM in runtime on request by the API
NvMWriteBlock
• During the HP to LP transition (WriteAll), the blocks that need to be saved
are saved
• This strategy does more Runtime accesses to NvM, but saves the blocks
imediately in NvM
 11

Interactions Overview of NvM:

 12

Write Data Path Example

 13

Flash EEPROM emulation (Fee)

 14

Data Flash Layout:

- Bank description – Bank is the FEE Erase Granularity
- Data Flash is divided in banks -Each bank is delimited by a header and a
footer
Bank 1 – Start Address Bank Header Bank Start
Bank Address
1 Bank 1 – End Address

Bank 2 – Start Address

Bank Data
Bank 1
2 Storage
Bank 2 – End Address
Area

Bank 3 – Start Address

Bank
3 Bank 3 – End Address
Bank Footer Bank End
Address
 15

Data Flash Layout:

- Bank description – Bank header and footer description

Bank Header Header structure:

Bank
FEE10 xx Checksum Invalidate Last Block Address
Counter

Data Footer structure:

Storage
Area Bank
FEE10 xx Checksum Invalidate
Counter

• Bank counter -> Used to identify the newest and the oldest banks
• FEE10xx -> Marker (with version xx) for bank recognition
Bank Footer
• Invalidate field -> Banks marked before erase
• Last Block Address -> Speed up initialization of full banks
 16

Data Flash Layout:

- Block description – Block is the FEE Write Granularity
- The data area of the banks is filled with blocks

Bank Header
Blocks are recognized thanks to their footer:

Block A
Id ➔ Fee Block Id
Size ➔ NvM data length (Appli data + CRC)
Block B
Invalidate ➔ Flag indicating if the block is valid
Block C
46 ➔ Fixed marker used to search block footer
DataStorage
Area
Switched ➔ Flag indicating if the block instance is switched
Bank Footer
Each block is chained to the previous one:
Offset ➔ Address offset to previous block
Fee Footer
NvM Data
Offset Id Size Invalidate 46 Checksum Switched
 17

APIs
 18

NvM provides 2 types of APIs:

• Synchronous APIs
-These requests are processed immediately
-They return a status reflecting the completion of the requested action (success/failure)

• Asynchronous APIs
-Requests that need a long processing time
-These requests are queued and are processed in “background”
-The API returns a status that indicate if the operation was accepted (queued) or rejected
-If the operation is accepted, the application is informed of the result through
 19

Synchronous APIs: Asynchronous APIs:

- NvM_SetDataIndex
-NvM_GetDataIndex
-NvM_SetBlockProtection
-NvM_GetErrorStatus
-NvM_GetVersionInfo
-NvM_SetRamBlockStatus
The useful ones:
- NvM_SetDataIndex
- NvM_GetErrorStatus
- NvM_SetRamBlockStatus
- NvM_ReadBlock
-NvM_WriteBlock
-NvM_RestoreBlockDefaults
-NvM_EraseNvBlock
-NvM_CancelWriteAll
-NvM_InvalidateNvBlock
-NvM_ReadAll
-NvM_WriteAll

- NvM_ReadBlock
- NvM_WriteBlock
- NvM_InvaliddateNvBlock
 20

Example: Sequence diagram of NvM access for use case – Store at

shutdown
 21

Thank you ☺