前言

前几个月针对公司自己的芯片写了个程序，这个程序有个硬性要求，就是能用的FLASH空间只有4KB，之前已经写得差不多了，最终占用空间3.6KB。

这不，最近又得加需求，还剩一点点FLASH空间可以使用，这该如何是好。需求已经加过来了，不行也得行啊。所以就得去优化之前的代码了，这就得研究比较底层的东西了。

我们的芯片与其它的MCU芯片用起来都差不多一样。我们在用ST的时候，编译完成，会生成很多文件，其中有一个.map文件，里面包含的信息就是工程 ROM/FLASH 和 RAM 的占用情况 。

之前只是关心.map文件的最后几行的 ROM/FLASH占用信息，如：

这次就得认真的学习一下这个文件了，只有清楚的知道这些信息才可以很好的进行代码优化 。下面我们来一起学习一下STM32的.map文件。（以下内容来自野火及安富莱教程文档）

map文件

要生成 map 文件，MDK 中如下选项要选上：

将工程全编译，且没有错误后，双击这里就可以看到生成的 map 文件了：

map文件的内容可分为如下几部分：

1、节区的跨文件引用（Section Cross References）
2、删除无用节区（Removing Unused input ps from the image）
3、符号映像表（Image Symbol Table (Local Symbols Global Symbols)
4、存储器映像索引（Memory Map of the image）
5、映像组件大小（Image component sizes）

1、节区的跨文件引用

这部分主要是不同文件中函数的调用关系。  在这部分中，详细列出了各个.o 文件之间的符号引用。

由于.o 文件是由 asm 或 c/c++源文件编译后生成的，各个文件及文件内的节区间互相独立，链接器根据它们之间的互相引用链接起来，链接的详细信息在这个Section Cross References一一列出。

例如，开头部分说明的是 startup_stm32f429_439xx.o 文件中的“RESET”节区分为它使用的__initial_sp符号引用了同文件“STACK”节区。

也许我们对启动文件不熟悉，不清楚这究竟是什么，那我们继续浏览，可看到 main.o文件的引用说明，如说明 main.o 文件的 i.main 节区为它使用的 LED_GPIO_Config 符号引用了 bsp_led.o 文件的 i.LED_GPIO_Config 节区。

有时在构建工程的时候，编译器会输出 “Undefined symbol xxx (referred from xxx.o)” 这样的提示，该提示的原因就是在链接过程中，某个文件无法在外部找到它引用的标号，因而产生链接错误。

2、删除无用节区

map 文件的第二部分是删除无用节区的说明，见代码清单：

这部分列出了在链接过程它发现工程中未被引用的节区，这些未被引用的节区将会被删除(指不加入到*.axf 文件，不是指在*.o 文件删除)，这样可以防止这些无用数据占用程序空间。

例如，上面的信息中说明 startup_stm32f429_439xx.o 中的 HEAP(在启动文件中定义的用于动态分配的“堆”区)以及 stm32f4xx_adc.o 的各个节区都被删除了，因为在我们这个工程中没有使用动态内存分配，也没有引用任何 stm32f4xx_adc.c 中的内容。

由此也可以知道，虽然我们把 STM32 标准库的各个外设对应的 c 库文件都添加到了工程，但不必担心这会使工程变得臃肿，因为未被引用的节区内容不会被加入到最终的机器码文件中。

对于这个部分功能，用户最好将 MDK 中这个选项勾上，然后全编译工程，效果会比较好：

3、符号映像表

map 文件的第三部分是符号映像表(Image Symbol Table)， 见代码清单 51-12。

这个表列出了被引用的各个符号在存储器中的具体地址、占据的空间大小等信息。

如我们可以查到LED_GPIO_Config 符号存储在 0x080002a5 地址，它属于 Thumb Code 类型，大小为 106 字节，它所在的节区为 bsp_led.o 文件的 i.LED_GPIO_Config 节区。

4、存储器映像索引

map 文件的第四部分是存储器映像索引(Memory Map of the image)， 见代码清单：

映像文件可以分为加载域（Load Region）和运行域（Execution Region） 。

简单的说，加载域就是程序在 Flash 中的实际存储，而运行域是芯片上电后的运行状态，通过下面的框图可以有一个感性的认识：

通过上面的框图可以看出，RW 区也是要存储到 ROM/Flash 里面的，在执行映像之前，必须将已初始化的 RW 数据从 ROM 中复制到 RAM 中的执行地址并创建 ZI Section（初始化为 0 的变量区）。

本工程的存储器映像索引分为 ER_IROM1 及 RW_IRAM1 部分，它们分别对应 STM32内部 FLASH 及 SRAM 的空间。

相对于符号映像表，这个索引表描述的单位是节区，而且它描述的主要信息中包含了节区的类型及属性，由此可以区分 Code、 RO-data、 RW-data及 ZI-data。

例如，从上面的表中我们可以看到 i.LED_GPIO_Config 节区存储在内部 FLASH 的0x080002a4 地址，大小为 0x00000074，类型为 Code，属性为 RO。而程序的 STACK 节区(栈空间)存储在 SRAM 的 0x20000000 地址，大小为 0x00000400，类型为 Zero，属性为RW（即 RW-data） 。

5、映像组件大小

map 文件的最后一部分是包含映像组件大小的信息(Image component sizes)，这也是最常查询的内容，见代码清单  ：

这部分包含了各个使用到的*.o 文件的空间汇总信息、整个工程的空间汇总信息以及占用不同类型存储器的空间汇总信息，它们分类描述了具体占据的 Code、 RO-data、 RW-data及 ZI-data 的大小，并根据这些大小统计出占据的 ROM 总空间。

综合整个 map 文件的信息，可以分析出，当程序下载到 STM32 的内部 FLASH 时，需要使用的内部 FLASH 是从 0x0800 0000 地址开始的大小为 1456 字节的空间；当程序运行时，需要使用的内部 SRAM 是从 0x20000000 地址开始的大小为 1024 字节的空间。

总结

对照着这个map文件再看看我的程序，就可以知道哪里占的flash空间多了。硬件相关的部分已经用寄存器来操作，协议处理部分占用的flash空间最多。

最后，对于.map文件，我们一般只需要了解最后几行即可。如果想要深入学习，可以参照野火及安富莱的教程文档进行学习。

扫码或长按关注

回复「 篮球的大肚子」进入技术群聊