Understanding Map Files in Keil

What is a map file?

In simple terms, a map file is a mapping file that combines programs, data, and IO space after compilation by the compiler.

Many highly skilled engineers first think of analyzing the map file when encountering memory overflow or out-of-bounds situations. The map file provides important information such as function sizes and entry addresses.

The most common occurrence in Keil is that after compilation, the compilation window displays information about program and data sizes, similar to the following:

Program Size: Code=1112 RO-data=320 RW-data=0 ZI-data=1632

This piece of information actually summarizes the program and data information, which is compiled from individual modules and detailed in the map file.

About Map Files in Keil

Map files in the Keil software are important for analyzing bugs in projects; many memory-related bugs can be shared through the map file.

How to open a map file?

The most direct and simplest method: double-click the project target to open the map file (note to double-click the project target, not the project or file group). As shown in the figure below:

Of course, you can find the location of the map file (in the Listings folder) and open it with an editor tool.

Map file output content configuration:

The configuration of the output information for the map file is located at: Project -> Options for Target -> Listing, as shown in the figure below:

Main configurations include:

Memory Map: Memory Mapping
Callgraph: Call Graph
Symbols: Symbols
Cross Reference: Cross References
Size Info: Size Information
Totals Info: Total Information
Unused Section Info: Unused Module Information
Veneers Info: Veneer Information

We can check the corresponding information based on our needs for output.

Note:

A. By default, all information is outputted

B. These configurations are a combination relationship

Classification of map file contents:

From the output configuration above, we can see that the map file generally includes the following five categories of information:

(1) Section Cross References: Module and Section (Entry) Cross References

(2) Removing Unused input sections from the image: Removing Unused Modules

(3) Image Symbol Table: Mapping Symbol Table

(4) Memory Map of the image: Memory (Mapping) Distribution

(5) Image component sizes: Storage Component Sizes

The following chapters will provide detailed explanations of the five categories of content generated by the map files of Keil MDK and ARM Compiler 5 components.

Descriptions of Each Module

1. Section Cross References: Module and Section (Entry) Cross References

Check in configuration: Cross Reference

Section Cross References: Module and Section (Entry) Cross References refer to the relationship of mutual references between modules and sections generated by each source file.

For example:

main.o(i.System_Initializes) refers to bsp.o(i.BSP_Initializes) for BSP_Initializes

This means:

The System_Initializes function (i.System_Initializes) in the main module (main.o) calls the BSP_Initializes function in the bsp module (bsp.o).

Note:

A. main.o is the target module generated from the main.c source file

B. I.System_Initializes is the entry of the System_Initializes function

2. Removing Unused input sections from the image: Removing Unused Modules

Check in configuration: Unused Sections Info

This category is easy to understand; it generates a list in the map file of modules (or functions) in our code that have not been called.

For example:

Removing stm32f10x_gpio.o(i.GPIO_AFIODeInit), (20 bytes).

This means:

The GPIO_AFIODeInit module (function) in the stm32f10x_gpio.c file has not been called, with a code size of 20 bytes.

Finally, there is a statistical information:

52 unused section(s) (total 2356 bytes) removed from the image.

(1) A total of 52 sections have not been called;

(2) The total size of unused sections is 2356 bytes;

3. Image Symbol Table: Mapping Symbol Table

Check in configuration: Symbols

Image Symbol Table: Mapping Symbol Table refers to the table storing the corresponding addresses of each section (the image has removed some middle content).

Symbols are divided into two main categories

Local Symbols: Local
Global Symbols: Global

Key Points of Symbol Content

(1) Symbol Name: Symbol Name

For naming and classification, please refer to the official reference document provided at the end.

(2) Value: Corresponding storage address

You will find addresses like 0x0800xxxx, 0x2000xxxx.

0x0800xxxx refers to code, variables, etc., stored in FLASH.

0x2000xxxx refers to variables and Data stored in RAM.

(3) Ov Type: Type of the symbol

Symbol types generally include: Number, Section, Thumb Code, Data, etc.;

Careful readers will notice: global, static variables, etc., are located in the 0x2000xxxx memory RAM.

(4) Size: Storage size

This is easy to understand; it refers to the size occupied by the current line Symbol.

(5) Object (Section): Target section

This generally refers to the module (source file) in which it is located.

4. Memory Map of the image: Memory (Mapping) Distribution

Check in configuration: Memory Map

Memory Map of the image: Memory (Mapping) Distribution is relatively extensive and an important item.

Main Introduction:

Image Entry point : 0x08000131: refers to the mapping entry address.

Load Region LR_IROM1 (Base: 0x08000000, Size: 0x00000598, Max: 0x00080000, ABSOLUTE):

Indicates that the loading area is at the starting address of LR_IROM1, 0x08000000, with a size of 0x00000598, and this area has a maximum size of 0x00080000.

Execution Regions:

A. Execution Region ER_IROM1

B. Execution Region RW_IRAM1

This area corresponds to the regions in our target configuration, as shown in the figure below:

Key Points of Content:

(1) Base Addr: Storage Address

0x0800xxxx FLASH address and 0x2000xxxx RAM address.

(2) Size: Storage Size

(3) Type: Type

Data: Data Type

Code: Code Type

Zero: Uninitialized Variable Type

PAD: This type in the map file is placed here; it cannot be counted as a type here. If translated, it can only be described as a “padding type”.

The ARM processor is 32-bit; if an 8-bit or 16-bit variable is defined, some portion will remain, which refers to the “padding” part, and you will find that the other options behind it do not have corresponding values.

(4) Attr: Attributes

RO: Stored with segments in ROM

RW: Stored with segments in RAM

(5) Section Name: Section Name

This can also be referred to as the entry classification name, similar to the modules and sections referred to in the first chapter “Section Cross References”.

It generally includes: RESET, .ARM, .text, i, .data, .bss, HEAP, STACK, etc.

(6) Object: Target

5. Image component sizes: Storage Component Sizes

Check in configuration: Size Info

Image component sizes: Storage Component Sizes mainly summarizes the storage size information of modules.

This chapter’s content is believed to be understandable; after compiling the project, we generally see similar information in the compilation window:

Program Size: Code=1112 RO-data=320 RW-data=0 ZI-data=1632

Code: refers to the size of the code;

Ro-data: refers to constant data other than inline data;

RW-data: refers to read-write (RW), initialized variable data;

ZI-data: refers to uninitialized (ZI) variable data;

Reminders:

A. Code, Ro-data: Located in FLASH;

B. RW-data, ZI-data: Located in RAM;

C. RW-data initialized data will be stored in Flash, and upon power-up, it will be moved from FLASH to RAM.

The relationships are as follows:

RO Size = Code + RO Data

RW Size = RW Data + ZI Data

ROM Size = Code + RO Data + RW Data

The above map information is a comprehensive summary; if you do not want to look at detailed information about those modules, you can only check “Totals Info” in the configuration to compare the information:

END

Source: strongerHuang

Copyright belongs to the original author. If there is any infringement, please contact for deletion.。

Related posts

Leave a Comment Cancel reply