Memory Mapping

Learn about the Memory Map component in Autosar and how it infuences the source code

In a resource-constrained environment, such as an ECU, it's vital to take advantage of the hardware resources at your disposal, along with using these resources efficiently. This is specially true for memory. As much as we would love to have infinite amounts of memory, it becomes expensive. And the rising security needs makes it important for the every day Autosar developer to have control over the memory allocations. Hence, MemMap was born.

MemMap is a BSW module that takes part in basically all the code (generated or not) that goes into an ECU. Its main purpose is to map code and data to specific memory sections. The advantages are many, and they aren't limited to the ones described before. Some key points are:

• More efficient use of RAM - Recent microcontrollers are desinged in a 32-bit architecture, and the RAM memory will follow a 32-bit alignment for your variables. If your variables are allocated in the order they show up in your source code, your build process is likely to leave gaps when the entire variable cannot be allocated within the current 32 bits (this can be caused, for example, by allocating a 32-bit variable when you allocated an 8-bit variable right before), it will leave a gap and skip to the next 32-bit aligned address. Now, imagine how many bytes we are losing. MemMap circumvents this by allowing you to map memory sections based on a specific alignment.

• Take advantage of specific memory properties - Depending on your use case, you'll want/need to take advantage of the underlying properties of your architecture. Some of these properties include, but are not limited to: RAM that is not initialized after a reset, RAM sections that allow you to use instructions to manipulate bits (specially useful for bit-masked variables), use of internal flash for code that is used more often (and external flash for the opposite reason), and very importantly, take advantage of protected memory sections for security-sensitive variables.

• Share code and data between the bootloader and your application - More often than not, your bootloader will share some functionalities with your application (if they are developed in the same place, which can happen) or data. Sometimes you might want to check specific conditions that are established on one side or the other, and sharing some variables between both of them seems as a very good choice. MemMap simplifies this process too.

Now, that you know why, let's talk about how MemMap is used. This will not come to you as a surprise, if you ever used compiler pragmas before, or if you have stood around long enough to work in Autosar. For the others, MemMap looks like this:

    #define EEP_START_SEC_VAR_16BIT
    #include “MemMap.h”

    static uint16 EepTimer;
    static uint16 EepRemainingBytes;

    #define EEP_STOP_SEC_VAR_16BIT
    #include “MemMap.h”

As you can see by the example, we encapsulate the section of code we want the memory mapping applied to with the specific macro and include the memory mapping file when we call the macro to start and stop the section-specific mapping.

Now, let's take a look at the syntax for the section macro, which is generated by the MemMap module, according to our Arxml file for your component:

    <MODULE>_<START/STOP>_SEC_<TYPE>[_<INIT_POLICY>][_<ALIGNMENT>]  

The module will be, of course, the name of your component, or the name of the BSW module. Software Components will also include the MODULE name as a prefix of the MemMap include file name (to learn more about Software Components, make sure to check our article Types of Software Components (opens in a new tab)). BSW modules do not have this prefix, as you can see by the example. For the variable type, many options are available, and you can create specific types, on the MemMap module, if need be. Nonetheless, some of the most commonly used are: CODE, VAR (variables), CONST (constants) and CALIB (calibrations, to learn more about this topic please consult the article Calibration Overview (opens in a new tab)). As for the init policy, which is not required, it can be: INIT (initialized with an init value after reset), CLEARED (cleared after reset), POWER_ON_INIT (initialized on power on), POWER_ON_CLEARED (cleared on power on) or NO_INIT (not initialized). The alignment can also be left unspecified. The options regarding it, though, are: BOOLEAN (bits), 8BIT, 16BIT, 32BIT (depending on the alignment) and UNSPECIFIED (unknown). Lastly, it is common to find another notation, as older versions of Autosar used another.

Lastly, we will find out what is inside a MemMap file:

    #define MEMMAP_ERROR

    #ifdef EEP_START_SEC_VAR_16BIT 
        #undef EEP_START_SEC_VAR_16BIT
        #define START_SEC_DATA_16BIT
    #elif
    #ifdef START_SEC_DATA_16BIT
        #pragma section data "sect_data16"
        #undef START_SEC_DATA_16BIT
        #undef MEMMAP_ERROR
    #endif
    #ifdef STOP_SEC_VAR_16BIT 
        #undef STOP_SEC_VAR_16BIT 
        #undef MEMMAP_ERROR
    #elif 
    #ifdef STOP_SEC_DATA_16BIT
        #pragma section data "sect_data16" restore
        #undef STOP_SEC_DATA_16BIT
        #undef MEMMAP_ERROR
    #elif 
    
    #ifdef MEMMAP_ERROR
        #error "MemMap.h, wrong pragma command or section does not exist"
    #endif 

So, from top to bottom, we have the definition of MEMMAP_ERROR, which will tell our compiler in case something goes wrong, through an #error directive on the bottom and the start and stop macros for each section. Inside them, you can find some pragmas, which can be configured for each kind of section inside the MemMap module.

As some final thoughts, I hope MemMap makes more sense to you, as we went through the why, how and what, regarding this very useful module in the Autosar stack.

Author: Micael Coutinho (opens in a new tab)

References:

• Specification of Memory Mapping - Autosar Specification (opens in a new tab)