记一次STM32编译生成BIN文件过大的问题（基于STM32CubeIDE）

文章目录

问题描述
解决方法
更多拓展

问题描述

最近在一个项目中使用了 STM32H743 单片机（基于 STM32CubeIDE GCC 开发），它的内存分为了 DTCMRAM RAM_D1 RAM_D2 …等很多部分。其中 DTCM 的速度是比通常的内存要快的，缺点是不支持DMA。

这个项目对性能有一定需求，所以修改了链接脚本 STM32H743VITX_FLASH.ld，需要用到DMA部分的数据手动定位到 RAM_D1 ，其它部分默认定位到 DTCMRAM 。

修改后的链接脚本大致如下（删除了与本文关系不大的内容）：

/* Specify the memory areas */
MEMORY
{FLASH (rx)     : ORIGIN = 0x08020000, LENGTH = 384KDTCMRAM (xrw)  : ORIGIN = 0x20000000, LENGTH = 128KRAM_D1 (xrw)   : ORIGIN = 0x24000000, LENGTH = 512K
}/* Define output sections */
SECTIONS
{/* Initialized data sections goes into RAM, load LMA copy after code */.data :{} >DTCMRAM AT> FLASH/* Uninitialized data section */.bss :{} >DTCMRAM/* User_heap_stack section, used to check that there is enough RAM left */._user_heap_stack :{} >DTCMRAM.ram_d1 :{. = ALIGN(4);. = ALIGN(4);} >RAM_D1
}

链接脚本中我把大部分数据都定位到了 DTCMRAM ，然后添加了一段 ram_d1 区域，后续代码中使用下面方式就可以把数据定位到这个区域：

__attribute__((section(".ram_d1"))) uint8_t buffer[256];

到这里正常调试或者生成 .elf .hex 文件都没啥问题，但是生成的 .bin 文件就会非常大（几百MB）：
在这里插入图片描述

问题的原因是因为固件数据几个区域不连续，间断的空间都用默认数据进行了填充，导致了 .bin 文件非常大。

解决方法

使用 NOLOAD 指令可以处理该问题：

  .ram_d1 (NOLOAD):{. = ALIGN(4);. = ALIGN(4);} >RAM_D1

需要注意的是该使用该关键词后定义在该段的数据需要手动初始化（未验证）。