Memory Mapping Allocation Keywords
There are multiple keywords to map all variables on the ECU according to your application needs. Learn about them here
Within the bounds of an ECU, a resource-constrained hardware with hard real-time and special safety and security needs, it's necessary to use take advantage of the underlying memory layout, by allocating the data into special sections and reap the performance, security and safety benefits which will arise from it. Not to mention, an efficient and optimized Software always leads to a cheaper product, keeping your boss happy.
In order to take advantage of the memory layout of your ECU, Autosar contains the MemMap (Memory Mapping) module, which abstracts you from the preprocessor directives/pragmas and underlying linker-specific sections, which are arguably two of the hardest areas to master in microcontroller architecture. We already explained how the MemMap magic happens, but if you need a better refresher, you can read our article Memory Mapping (opens in a new tab). There, we explain the basics of this mechanism, along with its advantages.
Today, we'll build on this article, by discussing the most common keywords and their use. To start, let's take a look at the syntax, and after we'll look at all the options available for each section and their use. So, a section is usually defined as follows:
<MODULE>_<START/STOP>_SEC_<TYPE>[_<INIT_POLICY>][_<ALIGNMENT>] Keep in mind, the aforementioned structure can have some slight variations. For example, in some types you can specify an ASIL (safety) level or the core scope. But, let's start small, as these are sporadic and you are most likely not to use them. At least, you will expect them if they show up on your source code. Now, if we divide the former example into smaller chunks:
-
MODULE - Name of your Autosar module, which is taken by the Autosar code generator from the Arxml file you provide. In it, all sections used by your code should also be present, as these are the sections being generated for each module's _memmap.h file. If you are uncomfortable with Arxml files, maybe it's a good time to go into our article Arxml Files and Software Components (opens in a new tab), and you will be a pro in no time.
-
START/STOP - This is where most people fail. All START_SECTION must be followed by a STOP_SECTION. If not, you may run into those pesky linker errors nobody wants to see. It's an undefined behavior which can lead to countless hours of debugging, so watch out.
-
TYPE - This is where it starts to get interesting. According to the TYPE you define in MemMap (and the type qualifiers, which have to be taken into consideration, as they provide subtle hints of where your variables should be placed when the linker is deciding where to allocate them - const, restrict, volatile, ...), the variables will be placed into specific sections. The TYPEs defined in the Autosar layered architecture are as follows, although you can also create your own custom TYPEs, depending on your memory layout and application needs:
| TYPE | Description |
|---|---|
| VAR | Most common allocation type. Used for global or static variables |
| CONST | Also very common. Used for constant allocation |
| CALIB | Used for calibrations, which are constants that you will want to calibrate in runtime. You can learn more about calibration in the article Calibration Overview (opens in a new tab) |
| CODE | Used to map code into the specific areas defined in your architecture |
| VAR_FAST | Variables that need bitwise access or are frequently used in the source code |
| VAR_SLOW | Varibles that are used rarely |
| INTERNAL_VAR | Used for variabes that are accessed by a calibration tool |
| VAR_SAVED_ZONE | Used for RAM buffers of variables that are saved in non-volatile memory. If you are unfamiliar with non-volatile storage in Autosar, you can check our article NvM Overview (opens in a new tab) |
| CONST_SAVED_RECOVERY_ZONE | Used for ROM buffers of variables stored in non-volatile memory |
| CARTO | Used for cartography constants |
| CONFIG_DATA | Used for constants that should reside in a segment for module configuration |
| CALLOUT_CODE | Used to map code into the callouts for BSW modules |
| CODE_FAST | Used for code that is accessed very often |
| CODE_SLOW | Used for code that is rarely accessed |
| CODE_LIB | Used for code belonging to libraries of BSW modules or Software Components |
- INIT_POLICY - Although optional, this parameter has the power to turn your variable into something safer and more predictable, or can turn your greatest dreams into nightmares. My advice is to use the initialization policy lightly and only if you know exactly why you need it. Nonetheless, the init policy can be considered as part of functional safety, as its use if often inteded to keep the variables from its scope in a predictable and safe state, every time the ECU is turned on. We recommend you take a jump into functional safety article, in What is Functional Safety (opens in a new tab). The INIT_POLICYes available are:
| INIT_POLICY | Description |
|---|---|
| NO_INIT | Variables are never initialized or cleared |
| CLEARED | Variables are initialized to zero after every reset |
| INIT | Variables initialized with its init value after every reset |
| POWER_ON_CLEARED | Variables initialized to zero only after power-on resets |
| POWER_ON_INIT | Variables initialized with its init value only after power-on resets |
- ALIGNMENT - Lastly, we have the optional alignment. This is useful if you are running low on memory, as you can optimize those fragments in the memory space and put all variables of the same size together. Hence, you ensure an efficient use of memory, without wasting any resources with padding bytes that are nothing but empty space. The possible alignments are:
| ALIGNMENT | Description |
|---|---|
| BOOLEAN | Used for bits |
| 8BIT | Used when to align your section's contents to 8 bits |
| 16BIT | Used when to align your section's contents to 16 bits |
| 32BIT | Used when to align your section's contents to 32 bits |
| UNSPECIFIED | Used when the provided aligments do not apply to your section |
Now that you are a pro when it comes to memory mapping, I hope your applications start running smoother. And with the knowledge you just acquired, you can optimize your applications to perform safer, faster and ensure an efficient resource usage. Happy coding!
Author: Micael Coutinho (opens in a new tab)
References:
© AutosarToday —@LinkedIn