AUTOSAR Memory Stack: NvM Blocks, Redundancy and Write Strategies

The problem

ECUs must store calibration data, fault memory and learned values such as odometer and SOC across power cycles, often in microcontroller flash that wears out and can be interrupted mid-write. The AUTOSAR memory stack, NvM, MemIf and Fee or Ea, handles this with block types, CRCs and redundancy. The choice of write strategy affects integrity, start-up time and flash life.

Objectives

• Specify non-volatile data blocks for an EV ECU with integrity and timing needs.
• Implement NvM-style block management with native, redundant and dataset blocks.
• Implement flash EEPROM emulation on the STM32F103 internal flash.
• Test integrity under resets during writes.
• Compare write strategies on latency, start-up time and flash wear.

What you need

Key concepts

NvM block types

Native blocks hold one copy; redundant blocks hold two copies so one survives corruption; dataset blocks hold several selectable instances, such as calibration sets.

RAM mirror

The working copy of a block in RAM. The application reads and writes the mirror; NvM copies it to or from non-volatile memory on request or at shutdown.

Flash EEPROM emulation

Flash can only be erased in whole pages and has limited erase cycles, so Fee writes new versions of records sequentially and moves valid data to a fresh page when one fills.

Write strategy

When data is written: immediately on change, periodically or only at shutdown with WriteAll. Each choice trades data loss risk against flash wear and shutdown time.

Step-by-step guide

1. 1

   Specify the data blocks

   Define the non-volatile data of an EV ECU: an odometer value updated often, a fault memory table, a calibration dataset with three selectable sets, learned SOC and capacity values, and a configuration block with VIN-style identifiers. For each block record size, update rate, loss tolerance, whether it needs redundancy, its default values and its CRC type. Decide the write strategy you expect for each and justify it.

   Checkpoint: A block table with size, update rate, block type, CRC, defaults and proposed write strategy.

2. 2

   Study the flash constraints

   From the STM32F103 reference manual, record the flash page size, programming width, erase time, programming time per half-word and the specified endurance in erase cycles. Choose two or more pages at the end of flash for emulation, away from the program image, and adjust the linker script so code never uses them. Calculate the expected wear per page for each candidate write strategy from your block table.

   Checkpoint: A flash constraints table and a wear estimate per strategy, with the reserved pages in the linker script.

3. 3

   Implement the flash driver and Fee

   Write a flash driver with page erase and half-word program, with the flash unlocked only during operations. Build a Fee layer on two or more pages: each record holds block ID, length, a sequence counter, data and a CRC, appended to the active page. Reading a block returns the newest record with a valid CRC. When a page fills, copy the latest valid record of each block to the next page, then mark pages so the switchover is recoverable.

   Checkpoint: PC-side and on-target tests show write, read and page switchover returning the latest data.

4. 4

   Implement the NvM layer

   Implement NvM services on top of Fee: ReadBlock, WriteBlock, RestoreBlockDefaults, ReadAll at start-up and WriteAll at shutdown, processed asynchronously by a main function so the application never blocks. Implement block types: native, redundant with two independent copies and a rule for which copy wins, and dataset with an index. Calculate CRCs over the RAM mirror and use defaults when no valid copy exists. Expose job results for each request.

   Checkpoint: Unit tests show correct behaviour for each block type, including a corrupted copy in a redundant block.

5. 5

   Connect an application component

   Model a small application component in Simulink with AUTOSAR Blockset that keeps the odometer and learned values in NvM blocks, using NvM service ports to request writes. Generate code and connect its RTE calls to your NvM. Use the keypad to simulate driving distance, request writes and trigger shutdown, and show values and job status on the LCD. Log every NvM job and its result over UART.

   Checkpoint: Odometer and learned values survive a normal shutdown and restart with matching values.

6. 6

   Test resets during writes

   Build an automated test: a hardware timer fires at a random delay after a write starts and forces a system reset through NVIC_SystemReset or a watchdog, so resets land at different points of programming and page switchover. After restart, the firmware reports over UART which blocks were restored, whether they hold the old or new value, and whether any default was used. Run thousands of cycles from a Python script.

   Checkpoint: A results table showing, for each block type, the share of resets that left old, new or default data, with zero undetected corruption.

7. 7

   Compare write strategies

   Run the same simulated drive profile with three strategies for the odometer: write on every change, write every fixed distance, and write only at shutdown. Measure the number of flash writes and erases, the average and maximum write latency, the shutdown time for WriteAll and the maximum distance that could be lost on an unexpected reset. Project flash life from measured erase counts and the specified endurance.

   Checkpoint: A comparison table of writes, erases, latency, shutdown time, possible data loss and projected flash life.

8. 8

   Measure start-up and timing

   Measure ReadAll time at start-up with a nearly empty page, with a full page and just after a switchover, using the DWT cycle counter or a GPIO and timer. Measure main function execution time and check it fits within its period. Measure flash and RAM use of each layer. Note the effect of the number of records per page on read time, because finding the newest record means scanning the page.

   Checkpoint: Start-up and per-cycle timing figures for different page fill levels, plus memory use per layer.

9. 9

   Report

   Document the block design, flash constraints, Fee and NvM implementation, reset test method and results, strategy comparison and timing. Recommend a write strategy for each block type and justify it with the measurements. Compare your design with a production AUTOSAR memory stack configured from ARXML, which adds features such as immediate-priority jobs, write verification and job queues, and note what you left out.

   Checkpoint: A report with reset-test statistics, strategy recommendations and the full source.

Testing & validation

• Correct read, write and page switchover in unit and on-target tests.
• No undetected corruption over thousands of random resets during writes.
• Redundant blocks recover from one corrupted copy.
• Measured flash erases per strategy and projected flash life.
• ReadAll start-up time at different page fill levels.

Expected results

A working NvM-style memory stack on the STM32 kit with measured integrity under resets, write latency, start-up time and flash wear for different block types and write strategies.

Take it further

• Add an external I2C EEPROM with an Ea layer and compare.
• Detect supply loss early and write critical blocks before brown-out.
• Add write verification by reading back after each write.
• Model the memory stack timing and wear in Simulink to explore strategies before testing.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.