文章目錄
- 問題描述
- 解決方法
- 更多拓展
問題描述
最近在一個項目中使用了 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
需要注意的是該使用該關鍵詞后定義在該段的數據需要手動初始化（未驗證）。
更多拓展
ST中文網有個文檔有介紹STM32CubeIDE鏈接文件相關內容，《LAT0816 - STM32CubeIDE實用技巧之ld鏈接文件》，可以下面地址下載到：
https://gitcode.com/Open-source-documentation-tutorial/3ad05
)
)
