STM32 memory management and understanding of heap and stack

Today I read the memory management code carefully, and then looked at the relevant knowledge of the stack. I figured out some things that I didn’t understand before, and wrote them down for easy reference later. I also hope that everyone can point out what’s wrong and then modify it.    

First, let's take a look at the memory structure of stm32.

Flash, SRAM registers and I/O ports are organized in the same 4GB linear address space. The accessible memory space is divided into 8 major blocks of 512MB each.

FLASH stores the downloaded program.

SRAM is used to store data in running programs.

Therefore, as long as you do not expand the memory externally, everything in the written program will appear in these two memories.

This is a premise!

Stack Cognition

1. Stack in STM32.

I have been confused about this, which has led to a lot of logical confusion. First of all, it should be explained that the microcontroller is an integrated circuit chip that integrates CPU, RAM, ROM, multiple I/O ports and interrupt systems, timers/counters and other functions. The CPU includes various bus circuits, calculation circuits, logic circuits, and various registers. Stm32 has general registers R0-R15 and some special function registers, including the stack pointer register. When stm32 runs the program normally, an interrupt comes, the CPU needs to push the value in the register into the RAM, and then store the address of the data in the stack register. When the interrupt processing is completed and exited, the data is popped to the previous register, which is done automatically in C language.

2. Stack in programming.

In programming, we often mention the stack. To be more precise, it is an area in RAM. Let's first understand a few explanations:

(1) All the contents in the program will eventually appear only in flash and RAM (not expanded externally).

(2) Segmentation is the process of storing similar data types in one area for easier management. However, as mentioned above, data in any segment will eventually end up in flash and RAM.

In C language, there are stack, heap, bss, data and code segments. You can search Baidu to find out what data is stored in each segment. Let's focus on analyzing STM32 and the division of segments in MDK.

Code, RO-data, RW-data, ZI-data segments under MDK:

Code is used to store program code.

RO-data stores const constants and instructions.

RW-data is a global variable that stores a non-zero initialization value.

ZI-data is used to store uninitialized global variables or global variables whose initialization value is 0.

Flash=Code + RO Data + RW Data;

RAM= RW-data+ZI-data;

This is the size of each segment that can be obtained after MDK compilation, and the corresponding FLASH and RAM size can also be obtained. However, there are two data segments that will also occupy RAM, but they will only be occupied when the program is running, that is, the heap and the stack. In the startup file .s file of stm32, there is a stack setting. In fact, the memory occupation of this stack is allocated from the address after the RAM is allocated to RW-data+ZI-data above.

Heap: is the memory area that the compiler calls dynamic memory allocation.

Stack: It is the place where local variables are stored when the program is running, so if the array of local variables is too large, it may cause stack overflow.

The size of the stack is unknown after the compiler compiles the program. It is known only at runtime, so you need to be careful not to cause a stack overflow. Otherwise, you will get a hard fault.

3. Stack and its memory management in OS.

The stack of an embedded system, no matter what method is used to obtain memory, feels similar to the heap in programming. Currently I know of two ways to obtain memory:

(1) Use a large global variable array to enclose a piece of memory, and then use this memory for memory management and allocation. In this case, the memory occupied by the stack is as mentioned above: if the array is not initialized, or the array initialization value is 0, the stack occupies the ZI-data part of the RAM; if the array initialization value is not 0, the stack occupies the RW-data part of the RAM. The advantage of this method is that it is easy to logically know the origin and destination of the data.

(2) Use the RAM that is not used by the compiler for memory allocation, that is, manage and allocate part or all of the remaining RAM after removing RW-data+ZI-data+compiler heap+compiler stack. In this case, you only need to know the first address and the last address of the remaining memory, and then start digging with the first address to determine how much memory to use. Make a linked list, link the memory acquisition and release related information, and you can manage the memory in time. There are many different algorithms for memory management, which I will not explain in detail. In this case: the memory allocation of the OS does not conflict with its own local variables or global variables. I struggled with this for a long time before, thinking that the variables in the function were also obtained from the system's dynamic memory. This method makes it easier to understand the beginning and end of your own address.

I feel that neither of these two methods is better, because it is just a way to obtain memory. The clever part lies in the management and allocation of memory.