Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to generate the map file of STM32". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "how to generate the map file of STM32"!

Preface

A few months ago, I wrote a program for the company's own chip, and this program has a mandatory requirement, that is, the only FLASH space that can be used is 4KB, which has been written almost before, and finally occupies the space 3.6KB.

This is not, recently have to add demand, there is still a little bit of FLASH space to use, what to do. The demand has been added, so you have to do it even if you can't. So you have to optimize the previous code, which means you have to study something at the bottom.

Our chips are almost the same as other MCU chips. When we use ST, we compile and generate a lot of files, including a .map file that contains information about the occupancy of the project ROM/FLASH and RAM.

Previously, I was only concerned with the ROM/FLASH occupancy information for the last few lines of the .map file, such as:

This time, you have to study this file carefully. Only by knowing this information clearly can you optimize the code. Let's learn about the .map file of STM32. (the following is from the wildfire and Amfli tutorial documentation)

Map file

To generate a map file, the following options should be selected in MDK:

After compiling the project without errors, double-click here to see the generated map file:

The contents of the map file can be divided into the following sections:

1. Cross-file reference of section area (Section Cross References)

2. Delete the useless section (Removing Unused input sections from the image)

3. Symbol image table (Image Symbol Table (Local Symbols Global Symbols))

4. Memory Image Index (Memory Map of the image)

5. Image component size (Image component sizes)

1. Cross-file reference of section area

This part is mainly about the calling relationship of functions in different files. In this section, symbol references between .o files are listed in detail.

Because the .o file is compiled and generated by the asm or cAccord + source file, the files and the sections within the file are independent of each other, the linker links them according to their cross-references, and the details of the link are listed in this Section Cross References.

For example, the opening section states that the "RESET" section in the startup_stm32f429_439xx.o file is divided into the _ _ initial_sp symbol it uses that references the "STACK" section of the same file.

Maybe we are not familiar with the startup file, do not know what this is, then we continue to browse, we can see the reference description of the main.o file, such as indicating that the i.main section of the main.o file references the i.LED_GPIO_Config section of the bsp_led.o file for the LED_GPIO_Config symbols it uses.

Sometimes when building a project, the compiler will output a prompt such as "Undefined symbol xxx (referred from xxx.o)" because during the linking process, a file cannot find its referenced label externally, resulting in a link error.

2. Delete the useless section

The second part of the map file is a description of deleting useless sections, as shown in the code listing:

This section lists the sections that it found unreferenced in the project during the link process, and these unreferenced sections will be deleted (not added to the * .axf file, not deleted in the * .o file), which prevents these useless data from taking up program space.

For example, the above information indicates that the HEAP in startup_stm32f429_439xx.o (the "heap" area defined in the startup file for dynamic allocation) and the sections of stm32f4xx_adc.o have been deleted because dynamic memory allocation is not used in our project and there is no reference to anything in stm32f4xx_adc.c.

From this, we can also know that although we add the c library files corresponding to the peripherals of the STM32 standard library to the project, do not worry that this will make the project bloated, because the unreferenced section content will not be added to the final machine code file.

For this part of the function, you'd better check this option in MDK, and then compile the project completely. The result will be better:

3. Symbol image table

The third part of the map file is the symbol image table (Image Symbol Table), as shown in listing 51-12.

This table lists the specific address of the referenced symbols in the memory, the amount of space occupied, and other information.

For example, we can find that the LED_GPIO_Config symbol is stored in the 0x080002a5 address, it belongs to the Thumb Code type, the size is 106bytes, and its section area is the i.LED_GPIO_Config section of the bsp_led.o file.

4. Memory image index

The fourth part of the map file is the memory image index (Memory Map of the image), as shown in the code listing:

Image files can be divided into load domain (Load Region) and run domain (Execution Region).

To put it simply, the loading domain is the actual storage of the program in Flash, while the runtime domain is the running state of the chip after power up. We can have a perceptual understanding through the following block diagram:

As you can see from the block diagram above, the RW area is also stored in ROM/Flash, and before executing the image, you must copy the initialized RW data from ROM to the execution address in RAM and create ZI Section (the variable area initialized to 0).

The memory image index of this project is divided into ER_IROM1 and RW_IRAM1 parts, which correspond to the space of FLASH and SRAM in STM32 respectively.

Compared with the symbolic image table, the unit described by this index table is the section area, and the main information it describes contains the types and attributes of the node area, so that Code, RO-data, RW-data and ZI-data can be distinguished.

For example, from the table above, we can see that the i.LED_GPIO_Config section is stored in the 0x080002a4 address of the internal FLASH, the size is 0x00000074, the type is Code, and the attribute is RO. The STACK section (stack space) of the program is stored in the 0x20000000 address of SRAM, the size is 0x00000400, the type is Zero, and the attribute is RW (that is, RW-data).

5. Image component size

The last part of the map file contains information about the size of the image component (Image component sizes), which is also the most frequently queried content, as shown in the code listing:

This section contains the space summary information of each used * .o file, the space summary information of the whole project and the space summary information of different types of memory, which classifies and describes the specific size of Code, RO-data, RW-data and ZI-data, and calculates the total ROM space occupied according to these sizes.

Combining the information of the whole map file, it can be analyzed that when the program is downloaded to the internal FLASH of STM32, the internal FLASH that needs to be used is the space of 1456 bytes starting from the address of 0x0800 0000; when the program is running, the internal SRAM is the space of 1024 bytes starting from the address of 0x20000000.

At this point, I believe you have a deeper understanding of "how to generate the map file of STM32". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.