Taking the hello_world software simulation of the Cortex-M3 SoC chip as an example:
We will first explain with the compilation results from Keil; the GCC compilation will be discussed in another article.
Zoom in:
-
① Code is a series of ARM instruction codes stored in eflash;
-
② RO DATA is read-only data;
-
③ RW DATA consists of non-zero initialized global and static variables, which need to be moved from flash to sram;
-
④ ZI DATA (zero initialize) is the size of the memory area initialized to zero (including zero-initialized global and static variables + heap + stack).
In simple terms, when the program runs,
the space occupied by the chip FLASH is: Code + RO Data + RW Data,
the space occupied by the chip RAM is: RW Data + ZI Data;
Open the hex file and look at the first four bytes 0x2000_0368.
Surprisingly, the first 4 bytes of the hex file are the initial value of the main stack pointer (MSP).
Size of the main stack pointer:
0x2000_0368 – 0x2000_0000 (starting address of SRAM)
= 0x368 (decimal 872),
which is exactly RW-data (8) + ZI-data (864) = 872 in size.
This explains the confusion about how the MSP main stack pointer is generated. It also proves that the size of RAM is indeed equal to the size of RW + ZI.
Theoretically, during initialization, the stack pointer should be assigned the highest address of RAM, as shown in the figure below, assigning the stack pointer 0x2000_0000 + 0x10000 = 0x2001_0000;
However, when compiling with Keil, Keil does not generate the HEX’s first 4 bytes (i.e., the initial value of MSP) according to the highest address of RAM, but according to:
The sum of the capacity of global and static variables + Heap_Size + Stack_Size, as the first 4 bytes of the HEX file.
It is generally better to use 0x10000 + 0x2000_0000 (starting address of RAM) as the initial value of MSP, but Keil does not do this. Keil only uses this value for compilation checks: checking whether the space occupied by global and local static variables (including both zero-initialized and non-zero-initialized parts) + heap + stack exceeds the value of 0x10000 in the red box above. If it exceeds, it will report a compilation error.
When compiling, Keil will direct the memory required for C library functions like malloc and free to the heap memory area. When we continuously malloc memory from the heap, the malloc function will check whether the memory used by the program exceeds Heap_Size. If it does, it will return NULL.
If we do not intend to use dynamic memory allocation provided by the C library, but intend to use our own memory heap management program, or even do not plan to use dynamic memory allocation at all, in these cases, we can set the heap size to 0 directly without using the standard library’s malloc.
Additionally, there is an important question: what are the vector values in the interrupt vector table? How do they point to the entry address of the interrupt service function?
For example, for the reset interrupt service function: Reset_Handler, the naming of this function cannot be arbitrary. The names of the interrupt service functions must match the corresponding vector names in xx_start.s, so that the CPU can find the entry address of the corresponding interrupt service function from the vector table. In other words, the vector value read from the corresponding interrupt position in the vector table is the PC value, and the CPU fetches the interrupt service function instructions from that PC address.
Moreover, the corresponding vector names in xx_start.s all have a WEAK suffix, which means that each interrupt service function can be overridden by interrupt service functions developed by software personnel.
Thank you for reading the article. If the article is useful, please click “Like” or share it.
