Table of content

Introduction

Scope

The scope of this Application Note is to provide an overview on the EEPROM Abstraction Module described by AUTOSAR and in particular provide more details on how the Layout Migration Algorithm is implemented in RTA-BSW.

Every time there is a change in the EEPROM Layout (e.g. a new block is added, a block is removed, the length of a block is changed) the Migration Algorithm will be started and will be able to rework the EEPROM Layout. This will allow to optimize and use efficiently the memory space in EEPROM.

Definitions and Abbreviations -

BSW: AUTOSAR Basic Software, Hardware independent service layer.

RTE: AUTOSAR Real Time Environment.

OS: AUTOSAR Operating System.

SWC: Software Component.

EEPROM: Electrically Erasable and Programmable ROM (Read Only Memory)

EA: EEPROM Abstraction Module

EEP: EEPROM Driver

AR: AUTOSAR

AN: Application Note

Toolchain

It is assumed you are using the RTA-CAR 9.2.0 toolchain:

Prerequisites

It is assumed that the Reader has good knowledge of AUTOSAR Methodology and Architecture, as well a good understanding of the Memory Stack specified by AUTOSAR.

References

The following AUTOSAR documents are useful references if you want to read more about this topic:

AUTOSAR Website - Specification of Flash EEPROM Emulation

AUTOSAR Website - Specification of EEPROM Driver

AUTOSAR Website - Specification of EEPROM Abstraction

EA and EEP in AUTOSAR MemStack

Overview and Terminologies

In general, the AUTOSAR Memory Stack is composed by all the AR BSW modules that are used to handle the storage of data into the non-volatile memory devices. The physical devices that can be used for this purpose are:

• DFlash
• External Flash
• Serial EEPROM (via SPI Bus)

The usage of EEPROM emulation which uses internal Data Flash of the microcontroller is generally preferred since less expensive than external EEPROMs. However, in this AN we will focus mainly on the EA module (EEPROM Abstraction) which manages the data organization and accesses to any serial SPI EEPROM.

As specified in AR documents, the EA Module "abstracts from the device specific addressing scheme and segmentation and provides the upper layers with a virtual addressing scheme and segmentation as well as a “virtually” unlimited number of erase cycles". It provides to the upper layers a virtuall addressing scheme and segmentation.

The EEPROM Driver, which is collocated in the MCAL Layer, is usable for both internal and external EEPROMs and provides low-level services to read, erase, write and compare the EEPROM data content. If the EEPROM is internal, the Driver accesses the microcontroller hardware directly, instead if the EEPROM is an external the Driver could use SPI (in most cases) to access the device.

EA implementation in RTA-BSW

In this section we describe how RTA-BSW implements the EA module and in particular what is the EEPROM layout created by this module.

Layout Overview

In the picture below you can observe the overall Layout of the EEPROM established by the RTA-BSW EA module. Every layer will be described in more detail later.

On the top of the layout there is a 64Byte area of Reserved Data used by the EA algorithm, which contains information on start/end addresses, migration, CRCs etc. After the reserved section, the EEPROM section used to store block data starts. All blocks (except permanent blocks) are located in this area.

Below the block data area, there is the Clipboard area, used as support for the Migration Algorithm. Finally, placed at the bottom of the EEPROM, we have the Permanent Blocks area.

Reserved Data Section

The picture below details how the Reserved Data area is composed. It contains:

• Migration Marker: this is an Hex code which is used to understand if a migration is needed/running/completed
• Start Address of the Reserved Area
• Layout End Address: last usable address for storing blocks data
• Offset Layout Start Address: this is the initial address in which the blocks data can be to be stored. It is delimited by the Layout End Address
• CRC16
• Clipboard Start Address: this address identify where the Clipboard area is located in the EEPROM
• EEPROM Size
• Reserved space

Layout Blocks

After the Reserved Area data, the Layout Blocks area starts. This area is used by the EA to place all the blocks data. As visible in the pictures below, each block starts with16Bytes of information called "Index Table".

Here some more details on each field which composes the Index Table:

• Pattern: It is a default block search pattern to identify the start of the header (0xAFFE80)
• Flag: identifies the type of the block
  • 0:  security level
  • 1: Reserved
  • 3 : invalid flag

  • 4 : permanent block flag

  • 5…7: Reserved

• Block Index: This is the Persistent ID of the Block
• Block Version: Write Cycle counter
• Header Checksum (CRC16)
• Data Checksum (CRC32)

What is a Permanent/Survival Block

Each block can be configured as "Survival Block" using the EA parameter EaRbSurvival. This parameter is usually automatically configured based on the configuration you have in the NvM Module. Therefore if you marked the NvM block as a Permanent Block, then the EA will configure the corresponding EA Block to be a Survival Block. This parameter changes the migration behaviour for the specific block, in case it is not within the new layout . This means that all the blocks marked as survival will not be delated during migration, even if the block is not part of the layout anymore.

Permanent Blocks Area and Reserved Block

All the Permanent Blocks are located in a specific area of the layout, at the very bottom of the available EEPROM memory space (called Permanent Area).  In order to address the Permanent Blocks, a Reserved Block is created in the EEPROM layout. The Reserved Block will exist only if there is at least one Survival/Permanent Block configured and it stores the offset to the permanent area for each of the configured survival blocks.

Clipboard

The Clipboard is an area of the EEPROM used to support the migration of data to new layouts. It is a temporary area where the blocks can be copied in case they need to be migrated. In this way, the EA can keep a copy of the block which is moving over. The Clipboard is cleared after the migration is concluded. To ensure the migration is possible, the Clipboard must have enough space to allow the copy the greatest EA Block configured.

EA Migration Algorithm

General concept

The Migration Algorithm is used by the EA in case the Layout from the NvM has been changed. Using this Algorithm, the EA migrates the EEPROM to a new layout. This is possible when:

• New blocks are added
• Existing blocks are removed
• There are changes in the Block Lengths
• There are changes in the Block settings (e.g. there is a security level change associated to that block)

The EA is able to understand when a migration is needed using the Migration Marker. This is an hex code generated out of the following information:

• Persistent ID
• Block Length
• Security Level
• Survival Feature (enabled or disabled)

The EA compares the Migration Marker with the stored marker in the old layout header. If the marker is different, then the migration is needed. When the migration is completed, the Migration Marker is updated in the layout header.

Initialization Phase

The init phase is executed calling the EA_Init function, where the Ea_Rb_MigrationInit is called. This last function contains the state machine which is able to assess if the EEPROM migration is needed or not. This is possible reading the migration marker and comparing it with the value generated based on the configuration. When a different migration marker is detected in the EEPROM, the initialization proceeds and it starts to read all the blocks which exists in EEPROM.

Different cases are handled during the initialization: for example, in case of errors in the CRC or the layout of the migration header is corrupted, the algorithm proceeds to read the header redundant copy. If all the copies are corrupted there are manual searches into the EEPROM to try to find the correct information. Also, the Migration Header Info is updated with Layout End and EEPROM real size information.

Migration Example

In this section we want to present a migration example to clarify the importance of the algorithm in saving EEPROM space. Let's assume we are starting from the following EEPROM Layout:

and after a while we decide to remove block 11 and add two new blocks: 25 and 77. The new Layout will be the following:

In order to get to a status where the EEPROM space is fully optimized, the migration algorithm will be applied. The following pictures will show what the migration algorithm will do, step by step, in order to move from the initial layout to the final layout presented in the previous two pictures above.

In Step1, the block 44 is recognised to be a Permanent Block and therefore is moved directly at the bottom of the EEPROM, in the Permanent Area.

In Step2 the block 66 and 55 needs to be moved, because they need to leave some space for the new block 77. Therefore in Step2 and Step3 the Block 66 and Block 55 are temporary copied in the Clipboard

               Step1                                                       Step2                                                     Step3

Now there is enough space to place the new block 77, which is copied in Step4 at the expected location. In Step5 and Step6 the Block 66 and 55 are copied back in the EEPROM Layout and the Clipboard is cleared from the temporary data.

           Step4                                                       Step5                                                        Step6

Now it is needed to free some space for adding the new block 25. In order to do so, in Step7 the algorithm makes a temporary copy of Block 22 and in Step8 writes the new Block 25. Finally, in Step9 the Block 22 is copied back in the new location inside the EEPROM Layout and the Clipboard temporary copy is cleared.

The last Step10 represent the update of the Migration header with the new information of the layout and especially with the new Migration Marker, which is updated so that the EA will know that the migration has been successfully completed. During the next power on and the next initialization, the EA will check again the Migration Marker in the Migration header and if it corresponds to the one computed on the basis of the EEPROM Layout, the EA will understand that the EEPROM is up to date and there is no migration needed.

         Step7                                                       Step8                                                        Step9                                                          Step10

Limits and constraints

The main constraint of EA Migration Algorithm regards the Clipboard space. The Clipboard must be big enough to ensure that the two largest Block can be copied there. In this way, the Migration can be guaranteed in all cases. Otherwise, in some cases the Migration cannot be executed due to lack of clipboard space and the EA will return an error similar to MIGRATION_NOT_POSSIBLE.

Clipboard Space = Size of the first biggest Block + Size of the second biggest Block

Also, there are some warnings that are returned in the following cases:

• survival block dimension too high > 1000Bytes
• normal block dimension too high > 3000Bytes
• more than half of the blocks are configured as survival blocks

If not needed, the Migration Functionality can always be disabled with the appropriate RTA-BSW configuration.