记一次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 = 384K
DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
RAM_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
需要注意的是该使用该关键词后定义在该段的数据需要手动初始化(未验证)。
更多拓展
ST中文网有个文档有介绍STM32CubeIDE链接文件相关内容,《LAT0816 - STM32CubeIDE实用技巧之ld链接文件》,可以下面地址下载到:
https://gitcode.com/Open-source-documentation-tutorial/3ad05