Research on STM32 Memory distribution

Research on STM32 memory distribution

2016-2-2

I run Ucos encountered a very strange problem, run a period of time will be inexplicable into the Hardfault function, causing the system to panic. Later, according to the stack debugging, found each call function is not the same, is very puzzling. Through the map file finally concluded that in the system initialization time in the flash read out the system configuration parameters, in the system running process will write flash, and flash definition of the address and program code storage location overlap, a write data erased some functions, An unknown instruction error occurs when calling to these functions. Separating this parameter from the definition of the address will solve the problem. However, the beginning of this address is written, as the program code continues to increase, the consumption of flash on the chip will also increase, is a dynamic growth process, not aware of the likelihood of conflict. So in the project development process periodically check the definition of the parameter storage address, or simply define the parameter storage address before the program address.

Learn more about the compiled STM32 project today, stack memory distribution, and help with understanding stack size allocations. Open a STM32F103RET6-based project with 512KB of built-in Flash and 64KB SRAM, as you can see through the map file:

Name	Position	Address	Note
Reset resetting vector	Flash	0x08000000	The first code for power-on execution
Library Function Code Snippet	Flash	0x08000144	Library functions called in the program, such as string processing functions, memory allocation functions, etc.
User-defined function code snippet	Flash	0x08001110	Project template function library, user-defined function compiled code, sorted by the first letter of the function name
. constdata	Flash	0x0800d07c-0x0800d680	User-defined constants
Remaining space	Flash

Name	Position	Address	Note
. Data	Sram	0x20000000	Data segments, and the initialized global variables
. BSS	Sram	0x20000268	Uninitialized global variables
Heap (heaps)	Sram	0x200033e8	Start the file definition of the heap space, the program calls malloc free allocated memory on the heap
Stack (Stack)	Sram	0x200073e8	Start the stack space for the file definition, and the local variable space in each function is allocated on the stack
Remaining space	Sram

For example, in this project, the flash custom parameter stores the address, not defined before 0x0800d680.

         In addition, it can be seen that in SRAM, the allocated storage is the global variable area, uninitialized variable area, heap, and stack. Note that if the heap and stack definitions are too small, the default definition of the program is not big, once the use of a large local variable, it is possible to cause stack space overflow, covering the heap space or even the above global variable area, causing the system error problem. For example, in the process of doing IAP, every time to write 512 bytes to flash, because the large size of the flash block on the STM32 chip is 2K, before writing to read first, the call to write the function when the automatic creation of a 2K-size local variable, because the stack is growing upward, will naturally overwrite the heap and the global variable area , causing an unknown error. Depending on the resource of the on-chip SRAM, it is better to make the heap and stack suitably larger, for example, each set to 4K size.