C Memory Layout
In Autosar, MemMap takes over the memory distribution of the system. Learn about C memory layout and its particularities in Autosar here
We always like to state the importance of the Memory Mapping module in Autosar. Whether it's for functional safety purposes (you can learn the very basic concepts of functional safety in our article What is Functional Safety (opens in a new tab)), to share information between different parts of your build (such as bootloader and application), or specific needs of your modules (for example, some variables have different initialization schemes), it's crucial to control the memory layout of your ECU. That is the exact purpose of MemMap, and why we covered it multiple times in our website, in the articles Memory Mapping (opens in a new tab) and Memory Mapping Allocation Keywords (opens in a new tab). Although having to write the very specific MemMap code can be annoying and error-prone (and if you ever came across MemMap errors, sometimes it's just an uppercase instead of a lowercase, and that can be very frustrating), one cannot understate what this module does for us.
Today, we will take a step further, by reviewing our concepts of C programming and refreshing the C memory layout on our minds. Firstly, the memory layout is how your C building process organizes all the code and data into the memory of your microcontroller, or ECU, more correctly, as you can have external Flash chips, for example. We already went around to explaining what MemMap does and why we need it, so, today, we will learn about all the memory sections on a macro (C) level and the particularities Autosar adds to the mix.
So, every program in C that does some kind of functionality will have the following memory layout:
The memory layout of a C program
As you can see by the picture above (where the sizes are completely arbitrary and only for diagram purposes), we have:
-
Stack - This is the RAM where your arguments for function calls, local function variables (stack frame) and thread context are stored
-
Heap - One of the biggest confusions is stack and heap, so, pay close attention. Heap is where your dynamically allocated variables go into. Every time you call a malloc or a free API, you are using the heap
-
.text - The .text segment contains your source code and constants, which are not supposed to be changed in runtime, and have read-only access (unless you are using a trick called memory overlay, which we covered a bit in our article Calibration Overview (opens in a new tab), but we will go into further details in the near future, so stay tuned)
-
.data - The .data segment contains the initialized variables of your source code. But, all of them? Because we remember telling you about local function variables getting stored in the stack. So, what's the catch? Well, there are two types of .data: local, which we use for module-static variables, which are global to the scope of a C module but local when it comes to the global scope of the C program, and global, where the global variables in the scope of a C progam are contained. And all the local variables to a function are stored inside the stack. Another side note: the initialization value of an initialized variable is stored in Flash memory, and the respective value gets assigned in the C startup code
-
.bss - The .bss segment is where the variables we do not initialize go into. The global and local scopes are also valid for the .bss section
See? The memory layout is not that complicated anymore. Now you just need to go an extra stop: the particularities the Autosar OS adds to the mix. These are not many, but they have a bit of influence on what you can and cannot do in this OS. Considering the automotive Software as this very safe and secure environment, it will make sense (hopefully). You cannot dynamically allocate anything. The malloc and free APIs are forbidden, and your code will spit out a funky linking error. The same goes for the thread stack. Your OS is defined statically, so, you cannot create any resource, such as a thread or a counter in runtime, or even allocate more stack dynamically, if need be. There is no "if need be". These dynamic shenanigans cannot happen in runtime. We talk in a bit more detail about the OSEK OS, the OS which served as the base for the Autosar OS in the articles OSEK OS Overview (opens in a new tab) and OSEK OS in Practice (opens in a new tab). If you want to learn more about the Autosar OS, it's a good place to start.
Alright, so now that you know so much about memory allocation and layour in Autosar, what are the next steps we can take? Well, we can learn more about the linker and the memory protection and application partitioning in Autosar. These are topics we are going to cover in the near future, so we advise you to stay tuned and subscribe to our mailing lis. See you soon!
Author: Micael Coutinho (opens in a new tab)
References:
© AutosarToday —@LinkedIn