Analyzing the MAP File Generated by MDK for Cortex-M3 Microcontroller

Recently, I started updating a series of articles on the Cortex-M3 core microcontroller, which will involve basic knowledge of assembly, analysis of startup processes, map file analysis, etc. I will continue to update, and I welcome everyone to follow.

This article is the third in the series.

Part One: Section Cross Reference – Analysis of File Reference Relationships

The main focus is on the mutual references between the modules generated by various source files.

For example, the first sentence: startup_stm32f10x_hd.o(RESET) refers to startup_stm32f10x_hd.o(STACK) for __initial_sp

This means that the RESET section in the startup_stm32f10x_hd.o file (generated from the startup_stm32f10x_hd.s file) references a global symbol __initial_sp in the STACK section of the startup_stm32f10x_hd.o file, which could be a global variable or a function. The subsequent text conveys this meaning.

Part Two: Removing Unused Input Sections from the Image.

This involves removing unused functions from the executable image to reduce the size of the program.

Part Three: Image Symbol Table – A Table of All Symbols in the Image

Local Symbol: Local symbols include static functions from each module as well as public functions. If anyone understands this better, please enlighten me.

Global Symbol: Global symbols include global variables and public functions from various file modules.

The most important part is these two statements:

Local Symbols

Symbol Name Value Ov Type Size Object(Section)

../clib/angel/boardlib.s 0x00000000 Number 0 boardinit3.o ABSOLUTE

../clib/angel/boardlib.s 0x00000000 Number 0 boardinit2.o ABSOLUTE

../clib/angel/boardlib.s 0x00000000 Number 0 boardinit1.o ABSOLUTE

../clib/angel/boardlib.s 0x00000000 Number 0 boardshut.o ABSOLUTE

../clib/angel/dczerorl2.s 0x00000000 Number 0 __dczerorl2.o ABSOLUTE

../clib/angel/handlers.s 0x00000000 Number 0 __scatter_zi.o ABSOLUTE

Ov Type isNumber does not occupy space, value is always address 0, size is also 0

Ov Type isSection startsoccupying space, value is always the address of the interrupt vector (for example0x08004000), size is the size of the label, aligned to 4 bytes

RESET 0x08004000 Section 428 startup_stm32f429xx.o(RESET)

!!!main 0x080041ac Section 8 __main.o(!!!main)

!!!scatter 0x080041b4 Section 52 __scatter.o(!!!scatter)

!!dczerorl2 0x080041e8 Section 90 __dczerorl2.o(!!dczerorl2)

!!handler_zi 0x08004244 Section 28 __scatter_zi.o(!!handler_zi)

.ARM.Collect$$_printf_percent$$00000000 0x08004260 Section 0 _printf_percent.o(.ARM.Collect$$_printf_percent$$00000000)

.ARM.Collect$$_printf_percent$$00000003 0x08004260 Section 6 _printf_f.o(.ARM.Collect$$_printf_percent$$00000003)

.ARM.Collect$$_printf_percent$$00000009 0x08004266 Section 6 _printf_d.o(.ARM.Collect$$_printf_percent$$00000009)

.ARM.Collect$$_printf_percent$$0000000C 0x0800426c Section 6 _printf_x.o(.ARM.Collect$$_printf_percent$$0000000C)

.ARM.Collect$$_printf_percent$$00000014 0x08004272 Section 6 _printf_s.o(.ARM.Collect$$_printf_percent$$00000014)

.ARM.Collect$$_printf_percent$$00000017 0x08004278 Section 4 _printf_percent_end.o(.ARM.Collect$$_printf_percent$$00000017)

Global Symbols

Symbol Name Value Ov Type Size Object(Section)

Analyzing the MAP File Generated by MDK for Cortex-M3 MicrocontrollerEdit

。。。。

Analyzing the MAP File Generated by MDK for Cortex-M3 MicrocontrollerEdit

。。。。。

Analyzing the MAP File Generated by MDK for Cortex-M3 MicrocontrollerEdit

。。。。

Analyzing the MAP File Generated by MDK for Cortex-M3 MicrocontrollerEdit

。。。。

Analyzing the MAP File Generated by MDK for Cortex-M3 MicrocontrollerEdit

In the map file,Local Symbols finally found:

Analyzing the MAP File Generated by MDK for Cortex-M3 MicrocontrollerEdit

0x20011a3c + 4 = 0x20011a40, so global variables are immediately followed by the stack (heap&stack)

Heap size is 0x2000 = 0x20013a40 – 0x20011a40

Stack size is 0x2000 = 0x20017a40 – 0x20013a40

The top of the stack is 0x20017a40 , this position is consistent with the space arrangement in the startup file:

Stack_Size EQU 0x4000;

AREA STACK, NOINIT, READWRITE, ALIGN=3

Stack_Mem SPACE Stack_Size

__initial_sp

##Analysis: DefinitionStack_Size is a constant0x4000, usingAREA pseudo-instructionto define a segment of data space,the segmentis namedSTACK, with attributesNOINIT, READWRITE, ALIGN=3,then usingSPACE to allocate a segment of space, labeled Stack_Mem , with a space size of Stack_Size, immediately followed by the label__initial_sp becausethe Stackgrows from high address to low address, sothe last address of the Stack is__initial_sp

; <h> Heap Configuration

; <o> Heap Size (in Bytes) <0x0-0xFFFFFFFF:8>

; </h>

Heap_Size EQU 0x2000;

AREA HEAP, NOINIT, READWRITE, ALIGN=3

__heap_base

Heap_Mem SPACE Heap_Size

__heap_limit

PRESERVE8

THUMB

Part Five: Memory Map of the Image

Execution Region ER_IROM1 (Base: 0x08000000, Size: 0x00046398, Max: 0x00080000, ABSOLUTE) – This section refers to FLASH, and the size is obviously the used FLASH size, including Code + RO_data. The details of each object file occupying FLASH are listed below.

Execution Region RW_IRAM1 (Base: 0x20000000, Size: 0x00008eb0, Max: 0x00010000, ABSOLUTE, COMPRESSED[0x00000350]) – This section refers to on-chip SRAM, and the size is the size of RW_data + ZI_data occupying on-chip SRAM, so the main stack pointer MSP = 0x20000000 + 0x8eb0, and when the program starts running, MSP begins allocating addresses for local variables from this address.

Execution Region ER$$.ARM.__AT_0x680830D0 (Base: 0x680830d0, Size: 0x00001024, Max: 0x00001024, ABSOLUTE, UNINIT) – Because I assigned the address for the file structure variable to external SRAM, the map file also includes some information about the external SRAM, but only the size of this file structure variable, which is 0x1024.

Part Six: Image Component Sizes

It lists the sizes of each component of the code, RO, RW, and ZI of all .c files used in the project, and then the sizes of each component of the library files added to the project.

From the last sentence, it can be seen:

Code (inc. data) RO Data RW Data ZI Data Debug Library Name

91574 2618 16290 1296 680 81428 STemWin522_CM3_OS_Keil.lib

1538 64 133 16 0 1788 mc_w.l

818 0 0 0 0 1080 mf_w.l

———————————————————————-

94120 2682 16432 1320 684 84296 Library Totals

STenWin522_CM3_OS_Keil.lib occupies (94120 + 16432 +1320) bytes of FLASH, (1320 + 684) bytes of SRAM, so this is why emWin requires at least a 2K memory microcontroller!!!

Reference:Analysis of the .map file generated by Keil MDK for STM32 – keil generated map canape – CSDN Blog

Leave a Comment