I believe that friends with greater project development experience have encountered memory overflow problems, so how do you analyze such problems? Have you ever met HardFault_Handler and analyzed map?
First, let’s talk about the configuration of map in MDK-ARM. In fact, in MDK-ARM, we can output the corresponding (we need) content in the map file according to our own circumstances (different configurations). By default, all information is output.
Project -> Options for Target -> Listing：You will see the following configuration interface:
See the above picture, I believe you should understand what the map file is about.
mapThe contents of the document can be roughly divided into five categories (according to the order of map files):
1.Section Cross References：Module and segment (cross) cross reference;
2.Removing Unused input sections from the image：Remove unused modules;
3.Image Symbol Table：Map symbol table;
4.Memory Map of the image：Memory (mapping) distribution;
5.Image component sizes：Storage size.
The following chapters give a detailed account of the contents of the map file for MDK-ARM.
Ⅰ、Section Cross References：Module, segment (entry) cross reference
The configuration should be checked on:Cross Reference
Section Cross References：Modules, segments (entries) cross-references refer to the modules, segments (defined entries) generated by each source fileMutually referenced relationships。
For example:
main.o(i.System_Initializes) refers to bsp.o(i.BSP_Initializes) for BSP_Initializes
Intend:
mainThe System_Initializes function (i.System_Initializes) in the module (main.o) refers to (or calls) the BSP_Initializes function in the BSP module (bsp.o).
Tips:
main.oIt is the target file module generated by main.c source file.
I.System_InitializesIs the entry of the System_Initializes function.
Ⅱ、Removing Unused input sections from the image：Remove unused modules
The configuration should be checked on:Unuaed Sections Info
This option is well understood. It is the module that is not called in our engineering code.
Finally, there is a statistical message:
52 unused section(s) (total 2356 bytes) removed from the image.
1.A total of 52 segments were not called.
2.The size not being invoked is 2356 bytes.
Ⅲ、Image Symbol Table：Mapping symbol table
The configuration should be checked on:Symbols
Image Symbol Table：The mapping symbol table is the table that stores the corresponding address in each segment (this is more important).
SymbolsDivided into two categories
1.Local Symbolslocal
2.Global SymbolsOverall situation
Content points
1.Symbol Name：Symbol name
2.Value：Store corresponding addresses;
You will find addresses like 0x0800xxxx and 0x2000xxxx.
0x0800xxxxRefer to code, variables stored in FLASH.
0x2000xxxxRefer to variables such as Data stored in memory RAM.
3.Ov Type：Types of symbol correspondence
There are probably several types of symbols: Number, Section, Thumb Code, Data, etc.
Careful friends will find that the global and static variables are located in the memory RAM of 0x2000xxxx.
4.Size：Storage size
This is easy to understand. We suspect that memory overflow can be analyzed by looking at the size of the code storage.
5.Object(Section)：Segment target
This generally refers to the module where it is located.
Ⅳ、Memory Map of the image：Memory (mapping) distribution
The configuration should be checked on:Memory Map
Memory Map of the image：Memory (mapping) distribution, content is relatively more, is also an important one.
Image Entry point : 0x08000131：Refers to the mapping entry address.
Load Region LR_IROM1 (Base: 0x08000000, Size: 0x000004cc, Max: 0x00080000, ABSOLUTE):
The loading area is located at the LR_IROM1 start address 0x08000000, the size of 0x000004cc, and the maximum size of this area is 0x00080000.
Execution area:
Execution Region ER_IROM1
Execution Region RW_IRAM1
This area actually corresponds to the area in our target configuration, as follows:
Content points
1.Base Addr：Storage address
0x0800xxxxFLASHAddress and 0x2000xxxx memory RAM address.
2.Size：Storage size
3.Type：type
Data：data type
Code：Code type
Zero：Uninitialized variable type
PAD：This type is placed in this location in the map file, but it is not the type here. To translate, we can only say “supplementary type”.
ARMThe processor is 32-bit, and if you define an 8-bit or 16-bit variable, there’s the rest, which is the “supplement” part, and you’ll find that none of the other options have corresponding values.
4.Attr：attribute
RO：Storage and segments in ROM
RW：Storage and segments in RAM
5.Section Name：Segment name
It can also be said to be the entry category name, just like the modules and segments in Section Cross References in Chapter 1.
Probably include: RESET,.ARM,.Text, I,.Data,.Bss, HEAP, STACK and so on.
6.Object：target
Ⅴ、Image component sizes：Storage size
The configuration should be checked on:Size Info
Image component sizes：Storage size, in fact, the main module is to store and store the size information.
This section is believed to be understandable, we compile the project, in the compilation window will generally see similar to the following paragraph of information:
Program Size: Code=908 RO-data=320 RW-data=0 ZI-data=1024
Code：Refers to the size of the code;
Ro-data：Refers to constant data besides inline data.
RW-data：RW, initialized variable data;
ZI-data：Refers to uninitialized (ZI) variable data;
Code、Ro-data：Located in FLASH;
RW-data、ZI-data：Located in RAM;
Reminder: the data initialized by RW-data will be stored in Flash, and the upper power will be moved from FLASH to RAM.
The relationship is as follows:
RO Size = Code + RO Data
RW Size = RW Data + ZI Data
ROM Size = Code + RO Data + RW Data
More specific content can be seen in the article:KeilCompile and store related notes and expand
The above information is a more comprehensive summary, if you do not want to see the details of those modules, only to see the summary of accounting information can be configured to check only “Totals Info” and compare information:
This article is transferred from https://blog.csdn.net/ybhuangfugui/article/details/75948282