1. 现象黑屏 启动 HardFault先别急着怀疑屏幕驱动最近在一个 STM32H743 项目上把 CubeMX 工程从旧版固件包升级到 CubeH7 1.13.0重新生成代码后一烧录屏幕直接黑。调试器全速跑程序永远停死在 HardFault_Handler。我一开始怀疑是 LTDC 配置、SDRAM 时序、DMA2D 中断哪里没配对毕竟 H7 显示链路坑多。但把所有外设初始化全部注释掉只留 SystemClock_Config 和 GPIO居然还是 HardFault。到这一步基本可以断定问题根本不在一堆驱动里而是发生在 startup 阶段还没跑到 main 就崩了。关键词就是 STM32H7 上的 startup HardFault以及 CubeH7 1.13.0 的 linker template。H7 的启动流程比 M4/M0 要敏感得多因为它的 RAM 不是一个块而是 DTCM、ITCM、AXI SRAM、D2 域 SRAM、D3 域 SRAM 各自独立链接脚本只要在内存布局上动一点手脚轻则变量初值不对重则直接触发 BusFault 升级成 HardFault。后来我打开生成的链接脚本对着启动汇编文件一看真相非常“基础”CubeH7 1.13.0 的模板把 .data/.bss 拆到了 DTCM 和 AXI SRAM 两个 RAM 区域但 startup 文件里的数据拷贝和清零循环只处理了其中一块。另一块 RAM 里的变量根本没从 Flash 复制初值也没被清 0等于让程序拿着随机值去跑不黑屏不 HardFault 才怪。这篇文章会把整个排查链路、Root Cause 和解决办法写清楚。如果你也遇到 H7 工程烧录后没反应、进 HardFault、屏幕黑的组合问题我建议你先别急着怀疑屏幕先查启动代码和链接脚本大概率能省下大半天。2. 第一轮排查外设全砍HardFault 依旧于是怀疑启动代码2.1 最小复现到“只剩 SystemClock_Config”我当时做了一个最小复现实验CubeMX 里把所有外设全部 disable只保留最基础的 RCC重新生成工程编译烧录。神奇的事情来了——如果所有外设都关掉工程不崩但只要我把 LTDC、DMA2D 这些比较大块的东西加回去或者手动声明一个几百 KB 的全局数组HardFault 就回来了。这个现象很典型本质上不是某个外设的驱动写得有问题而是“变量/数据总量一旦超过某个临界点链接脚本就会把一部分 .data/.bss 排到第二个 RAM 区域”从而触发启动阶段初始化缺失。最小工程可能所有代码和数据都塞在同一个 RAM region 里问题不暴露一旦数据量大、内存占用变复杂链接器的段布局发生切换坑就显现了。所以当你遇到“小工程正常、大工程必崩”的 HardFault最好先怀疑链接脚本而不是逐行查外设代码。2.2 老工程正常、新工程崩差异直指 CubeH7 版本我板子上原先跑的是一套基于老版本 HAL 的手写链接脚本工程能正常显示。唯一变化就是把 CubeMX 工程的固件包切到 CubeH7 1.13.0重新生成代码。两个工程代码逻辑几乎一样唯独链接脚本和 startup 文件是 CubeMX 重新生成的。H7 的 Cube 固件包升级时调整 linker template 是非常常见的事情。这次 1.13.0 把模板从“单 RAM region 放 .data/.bss”改成了“DTCM 和 AXI SRAM 分开放”。如果新模板和默认 startup 文件不匹配就会造成启动时部分数据段没有初始化。这里我需要说一句STM32CubeMX 生成的代码看起来是一套连贯的东西但实际上链接脚本、startup 汇编和 HAL 库是三个独立部分任何一个版本更新都可能破坏它们之间的同步。2.3 打开 map 文件一眼看出“劈成两半”在 CubeIDE 或任何 GCC 工具链下编译后都会生成.map文件。我习惯每次排查链接相关问题时先打开它搜索.data和.bss关键字。正常单 RAM 工程里你会看到类似.data 0x24000000 0x400 0x24000000 startup_stm32h743xx.o 0x24000010 main.o .bss 0x24000400 0x200 0x24000400 main.o但如果链接模板“分裂”了数据段map 里会出现两个输出段比如.data 0x20000000 0x200 0x20000000 main.o .data_axi 0x24000000 0x200 0x24000000 ltdc.o .bss 0x20000200 0x100 .bss_axi 0x24000200 0x100看到.data_axi、.bss_axi这样的段名基本就能确认链接脚本确实拆分了 RAM。接下来要做的是检查 startup 汇编里的初始化循环是不是只覆盖了.data和.bss。如果只覆盖了它们那.data_axi和.bss_axi就处于“没人管”的状态。3. Root Cause 拆解CubeH7 1.13.0 的 Linker Template 改了内存分布3.1 H7 的内存域和“RAM 不只是一个 RAM”在深入链接脚本之前先把 H7 的内存结构说清楚。STM32H7 的 RAM 不是一个连续大数组而是分散在多个物理域里各自有各自的特点内存区域起始地址典型大小主要特点能访问的主设备DTCM0x20000000128KB零等待、低延迟适合栈和热数据仅 CPU 核ITCM0x0000000064KB低延迟通常放关键代码或中断向量仅 CPU 核AXI SRAMD1 域0x24000000512KB大容量多主设备可访问CPU、DMA、LTDC、MDMA 等SRAM1/2/3D2 域0x30000000各 128KB外设常用DMA 友好但部分默认时钟关闭D2 域外设、CPUSRAM4D3 域0x3800000064KB低功耗唤醒保持数据CPU、少量外设了解这个表就能明白为什么链接脚本会“分裂”。DTCM 虽然快但只有 CPU 能访问而且容量小AXI SRAM 大、所有总线主控都能访问所以大数组、DMA buffer、帧缓冲都应该放 AXI SRAM。理论上来讲模板把.data/.bss分散到这两个区域是合理的但前提是 startup 必须为每个区域都生成对应的初始化代码。问题就出在这里。3.2 链接脚本里到底改了什么CubeH7 1.13.0 的模板我对比过几个 H743 工程的差异简化后大概是下面这样的逻辑MEMORY { FLASH (rx) : ORIGIN 0x08000000, LENGTH 2048K DTCMRAM (rw) : ORIGIN 0x20000000, LENGTH 128K RAM_D1 (rw) : ORIGIN 0x24000000, LENGTH 512K } SECTIONS { .data : { _sdata .; *(.data) *(.data*) _edata .; } DTCMRAM AT FLASH .data_axi : { _sdata_axi .; *(.data_axi*) _edata_axi .; } RAM_D1 AT FLASH .bss : { _sbss .; *(.bss) *(.bss*) _ebss .; } DTCMRAM .bss_axi : { _sbss_axi .; *(.bss_axi*) _ebss_axi .; } RAM_D1 }这个结构看起来没什么问题编译也能过。但关键点来了GCC 的 RAM AT FLASH只表示“运行时在 RAM加载时在 Flash”CPU 并不会自动把数据从 Flash 搬到 RAM。这个搬运工作必须由 startup 汇编代码显式完成。默认的startup_stm32h743xx.s只处理了.data和.bss也就是只搬运了 DTCM 那一份_sdata_axi、_sbss_axi这些符号根本没有对应的搬运循环。还有一个典型误解是“链接脚本里写了AT FLASH编程器烧录后变量就自动有初值了”。实际上编程器只是把数据烧到 Flash 里的加载地址CPU 上电后不会自动搬运必须靠启动代码。多 RAM region 的工程里每一个运行在 RAM 里的段都需要对应一段拷贝或清零代码缺一个就废一个。3.3 为什么黑屏而不是启动直接死循环严格来说startup 阶段可能并没有立即 HardFault真正崩的是 main 或外设初始化里第一次访问未初始化变量。比如一个全局标志g_lcd_enable放在.data_axiFlash 里的初值本该是 1但 AXI SRAM 对应地址上电后是随机值条件判断直接走错分支。一个回调函数指针放在.bss_axi本该被清 0实际却是一个随机非 0 值某个中断触发后调用这个指针直接跳到非法地址。一个 DMA buffer 地址变量未初始化外设读取后把数据写到错误的内存LTDC 的帧缓冲地址如果被污染屏幕就会出现黑屏、花屏然后触发 BusFault。所以现象上“黑屏 HardFault”是一前一后两个爆点黑屏可能先发生HardFault 紧随其后。如果你只盯着屏幕驱动很容易绕远路。这个案例再次说明嵌入式开发里“现象”和“根因”之间往往隔着一层链接脚本。4. 完整定位流程从 HardFault_Handler 一路查到 Map 文件4.1 用调试器把 Fault 寄存器全部挖出来遇到 HardFault我一般不会直接看 HardFault_Handler 这一个函数因为大多数 HardFault 都是由下级 Fault 强制升级的。第一步要打开调试器的寄存器窗口读取 Cortex-M7 内核这几个关键寄存器CFSR可配置故障状态寄存器里面细分了 MemManage Fault、BusFault、UsageFault。HFSRHardFault 状态寄存器看 FORCED 位确认是不是下级 Fault 升级。BFAR总线故障地址寄存器如果 BusFault 有效会记录触发故障的访问地址。MMFARMemManage 故障地址寄存器当非法访问内存区域时会记录目标地址。我当时在 HardFault_Handler 停下来先看 HFSR 的 FORCED置位说明确实是从 BusFault 或 UsageFault 升级上来的。再看 CFSRBusFault 那个字段是红的BFAR 指向 0x24000420 附近。看到这个地址我心里就基本有数了这个地址落在 AXI SRAM 区域大概率是某个未初始化的指针或变量被访问了。再回 map 文件一查0x24000420 恰好落在.data_axi或.bss_axi段的范围里。如果 BFAR 指向的是地址 0x20000000 或 0x24000000 附近可以根据地址判断问题出在哪个 RAM 域。这个排查手段比盲目在 main 里打断点高效得多。4.2 单步 Startup 汇编观察拷贝行为拿到 Fault 寄存器后我又在 Reset_Handler 入口打了一个断点从复位开始单步。这样做的目的是确认“变量到底有没有被初始化”。GCC 启动代码的正常流程是从__isr_vector取栈顶指针。调用SystemInit配置时钟和基础外设。执行.data拷贝循环从_sidata复制到_sdata直到_edata。执行.bss清零循环从_sbss到_ebss。调用main。单步到拷贝循环时我打开 Memory 窗口盯着 AXI SRAM 区域 0x24000000 附近看。数据一动不动仍然是 0xFFFFFFFF 或随机值。这里可以百分之百确认启动代码根本没有处理_data_axi这个段。因为拷贝循环的起始地址和结束地址是_sdata、_edata这两个符号只指向 DTCM 上的.dataAXI SRAM 那边没有任何代码去搬运、清零。如果你也看到这种“一个段有初始化、另一个段完全没人管”的情况基本可以直接锁定问题。4.3 对比旧模板和 .map为了进一步确认是 CubeH7 1.13.0 引入的回归我把旧版固件包生成的.ld文件和 1.13.0 生成的.ld文件做了一次 diff。差异非常明显旧链接脚本的.data通常整体放在RAM_D1新模板却引入了“DTCM 放一部分、AXI 放一部分”的拆分。再把旧模板编译出来的 map 文件打开AXI SRAM 段的数据初始化是正常的.data_axi这种额外段根本不存在。这个对比看起来不起眼但能把问题定性为“工具链模板变更导致的回归”而不是“你写的代码逻辑有问题”。以后遇到固件包升级后莫名其妙 HardFault先 diff 链接脚本是最高效的动作。5. 解决方案两个方向任选其一5.1 方案A把所有 .data/.bss 放回同一个 RAM region最省事对于大多数工程我最推荐的做法是改链接脚本把所有.data和.bss统一放到 AXI SRAM也就是RAM_D1。这样修改后startup 代码里现有的搬运循环就能覆盖全部变量不需要动汇编。具体修改很简单。把链接脚本里.data的 DTCMRAM改成 RAM_D1把.data_axi整体删掉.bss同样处理。核心代码如下.data : { . ALIGN(8); _sdata .; *(.data) *(.data*) . ALIGN(8); _edata .; } RAM_D1 AT FLASH .bss : { . ALIGN(8); _sbss .; *(.bss) *(.bss*) . ALIGN(8); _ebss .; } RAM_D1这里有一个细节要注意*(.data*)会匹配.data和.data.xxx这类带长短号的段名。如果你代码里有__attribute__((section(.data_axi)))这样的手动指定段那即使我删除了.data_axi段链接器也可能因为找不到输出段而报错或把变量扔到默认段里。最干净的办法是统一去掉这种section属性或者把.data_axi段重新映射到.data段里。如果你这个工程确实只需要在小 RAM 里跑也可以全部放 DTCM。但我不建议这么做因为 DTCM 只有 128KB而且 DMA 访问不了。一旦后续加音频、显示、网络这类需要 DMA 的功能你会再次被内存布局坑到。5.2 方案B保留多 RAM 布局补齐第二个 RAM 段的启动拷贝如果你的工程确实需要部分变量放在 DTCM、部分放在 AXI SRAM比如中断服务函数里高频访问的热数据放 DTCMDMA 缓冲区放 AXI SRAM那就需要保留多 RAM 布局并补齐第二个 RAM 段的启动初始化。在 GCC 的 startup 汇编文件里一般会有一段类似这样的数据拷贝逻辑CopyDataInit: ldr r3, _sidata ldr r3, [r3, r0] str r3, [r1, r0] adds r0, r0, #4 cmp r0, r2 bcc CopyDataInit你需要在原有.data拷贝循环之后追加一份针对.data_axi的拷贝循环同时针对 . 
长河君 · 2026/8/28 6:44:07 · 阅读 1.2k STM32H7启动HardFault排查：链接脚本RAM段初始化陷阱
1. 现象黑屏 启动 HardFault先别急着怀疑屏幕驱动最近在一个 STM32H743 项目上把 CubeMX 工程从旧版固件包升级到 CubeH7 1.13.0重新生成代码后一烧录屏幕直接黑。调试器全速跑程序永远停死在 HardFault_Handler。我一开始怀疑是 LTDC 配置、SDRAM 时序、DMA2D 中断哪里没配对毕竟 H7 显示链路坑多。但把所有外设初始化全部注释掉只留 SystemClock_Config 和 GPIO居然还是 HardFault。到这一步基本可以断定问题根本不在一堆驱动里而是发生在 startup 阶段还没跑到 main 就崩了。关键词就是 STM32H7 上的 startup HardFault以及 CubeH7 1.13.0 的 linker template。H7 的启动流程比 M4/M0 要敏感得多因为它的 RAM 不是一个块而是 DTCM、ITCM、AXI SRAM、D2 域 SRAM、D3 域 SRAM 各自独立链接脚本只要在内存布局上动一点手脚轻则变量初值不对重则直接触发 BusFault 升级成 HardFault。后来我打开生成的链接脚本对着启动汇编文件一看真相非常“基础”CubeH7 1.13.0 的模板把 .data/.bss 拆到了 DTCM 和 AXI SRAM 两个 RAM 区域但 startup 文件里的数据拷贝和清零循环只处理了其中一块。另一块 RAM 里的变量根本没从 Flash 复制初值也没被清 0等于让程序拿着随机值去跑不黑屏不 HardFault 才怪。这篇文章会把整个排查链路、Root Cause 和解决办法写清楚。如果你也遇到 H7 工程烧录后没反应、进 HardFault、屏幕黑的组合问题我建议你先别急着怀疑屏幕先查启动代码和链接脚本大概率能省下大半天。2. 第一轮排查外设全砍HardFault 依旧于是怀疑启动代码2.1 最小复现到“只剩 SystemClock_Config”我当时做了一个最小复现实验CubeMX 里把所有外设全部 disable只保留最基础的 RCC重新生成工程编译烧录。神奇的事情来了——如果所有外设都关掉工程不崩但只要我把 LTDC、DMA2D 这些比较大块的东西加回去或者手动声明一个几百 KB 的全局数组HardFault 就回来了。这个现象很典型本质上不是某个外设的驱动写得有问题而是“变量/数据总量一旦超过某个临界点链接脚本就会把一部分 .data/.bss 排到第二个 RAM 区域”从而触发启动阶段初始化缺失。最小工程可能所有代码和数据都塞在同一个 RAM region 里问题不暴露一旦数据量大、内存占用变复杂链接器的段布局发生切换坑就显现了。所以当你遇到“小工程正常、大工程必崩”的 HardFault最好先怀疑链接脚本而不是逐行查外设代码。2.2 老工程正常、新工程崩差异直指 CubeH7 版本我板子上原先跑的是一套基于老版本 HAL 的手写链接脚本工程能正常显示。唯一变化就是把 CubeMX 工程的固件包切到 CubeH7 1.13.0重新生成代码。两个工程代码逻辑几乎一样唯独链接脚本和 startup 文件是 CubeMX 重新生成的。H7 的 Cube 固件包升级时调整 linker template 是非常常见的事情。这次 1.13.0 把模板从“单 RAM region 放 .data/.bss”改成了“DTCM 和 AXI SRAM 分开放”。如果新模板和默认 startup 文件不匹配就会造成启动时部分数据段没有初始化。这里我需要说一句STM32CubeMX 生成的代码看起来是一套连贯的东西但实际上链接脚本、startup 汇编和 HAL 库是三个独立部分任何一个版本更新都可能破坏它们之间的同步。2.3 打开 map 文件一眼看出“劈成两半”在 CubeIDE 或任何 GCC 工具链下编译后都会生成.map文件。我习惯每次排查链接相关问题时先打开它搜索.data和.bss关键字。正常单 RAM 工程里你会看到类似.data 0x24000000 0x400 0x24000000 startup_stm32h743xx.o 0x24000010 main.o .bss 0x24000400 0x200 0x24000400 main.o但如果链接模板“分裂”了数据段map 里会出现两个输出段比如.data 0x20000000 0x200 0x20000000 main.o .data_axi 0x24000000 0x200 0x24000000 ltdc.o .bss 0x20000200 0x100 .bss_axi 0x24000200 0x100看到.data_axi、.bss_axi这样的段名基本就能确认链接脚本确实拆分了 RAM。接下来要做的是检查 startup 汇编里的初始化循环是不是只覆盖了.data和.bss。如果只覆盖了它们那.data_axi和.bss_axi就处于“没人管”的状态。3. Root Cause 拆解CubeH7 1.13.0 的 Linker Template 改了内存分布3.1 H7 的内存域和“RAM 不只是一个 RAM”在深入链接脚本之前先把 H7 的内存结构说清楚。STM32H7 的 RAM 不是一个连续大数组而是分散在多个物理域里各自有各自的特点内存区域起始地址典型大小主要特点能访问的主设备DTCM0x20000000128KB零等待、低延迟适合栈和热数据仅 CPU 核ITCM0x0000000064KB低延迟通常放关键代码或中断向量仅 CPU 核AXI SRAMD1 域0x24000000512KB大容量多主设备可访问CPU、DMA、LTDC、MDMA 等SRAM1/2/3D2 域0x30000000各 128KB外设常用DMA 友好但部分默认时钟关闭D2 域外设、CPUSRAM4D3 域0x3800000064KB低功耗唤醒保持数据CPU、少量外设了解这个表就能明白为什么链接脚本会“分裂”。DTCM 虽然快但只有 CPU 能访问而且容量小AXI SRAM 大、所有总线主控都能访问所以大数组、DMA buffer、帧缓冲都应该放 AXI SRAM。理论上来讲模板把.data/.bss分散到这两个区域是合理的但前提是 startup 必须为每个区域都生成对应的初始化代码。问题就出在这里。3.2 链接脚本里到底改了什么CubeH7 1.13.0 的模板我对比过几个 H743 工程的差异简化后大概是下面这样的逻辑MEMORY { FLASH (rx) : ORIGIN 0x08000000, LENGTH 2048K DTCMRAM (rw) : ORIGIN 0x20000000, LENGTH 128K RAM_D1 (rw) : ORIGIN 0x24000000, LENGTH 512K } SECTIONS { .data : { _sdata .; *(.data) *(.data*) _edata .; } DTCMRAM AT FLASH .data_axi : { _sdata_axi .; *(.data_axi*) _edata_axi .; } RAM_D1 AT FLASH .bss : { _sbss .; *(.bss) *(.bss*) _ebss .; } DTCMRAM .bss_axi : { _sbss_axi .; *(.bss_axi*) _ebss_axi .; } RAM_D1 }这个结构看起来没什么问题编译也能过。但关键点来了GCC 的 RAM AT FLASH只表示“运行时在 RAM加载时在 Flash”CPU 并不会自动把数据从 Flash 搬到 RAM。这个搬运工作必须由 startup 汇编代码显式完成。默认的startup_stm32h743xx.s只处理了.data和.bss也就是只搬运了 DTCM 那一份_sdata_axi、_sbss_axi这些符号根本没有对应的搬运循环。还有一个典型误解是“链接脚本里写了AT FLASH编程器烧录后变量就自动有初值了”。实际上编程器只是把数据烧到 Flash 里的加载地址CPU 上电后不会自动搬运必须靠启动代码。多 RAM region 的工程里每一个运行在 RAM 里的段都需要对应一段拷贝或清零代码缺一个就废一个。3.3 为什么黑屏而不是启动直接死循环严格来说startup 阶段可能并没有立即 HardFault真正崩的是 main 或外设初始化里第一次访问未初始化变量。比如一个全局标志g_lcd_enable放在.data_axiFlash 里的初值本该是 1但 AXI SRAM 对应地址上电后是随机值条件判断直接走错分支。一个回调函数指针放在.bss_axi本该被清 0实际却是一个随机非 0 值某个中断触发后调用这个指针直接跳到非法地址。一个 DMA buffer 地址变量未初始化外设读取后把数据写到错误的内存LTDC 的帧缓冲地址如果被污染屏幕就会出现黑屏、花屏然后触发 BusFault。所以现象上“黑屏 HardFault”是一前一后两个爆点黑屏可能先发生HardFault 紧随其后。如果你只盯着屏幕驱动很容易绕远路。这个案例再次说明嵌入式开发里“现象”和“根因”之间往往隔着一层链接脚本。4. 完整定位流程从 HardFault_Handler 一路查到 Map 文件4.1 用调试器把 Fault 寄存器全部挖出来遇到 HardFault我一般不会直接看 HardFault_Handler 这一个函数因为大多数 HardFault 都是由下级 Fault 强制升级的。第一步要打开调试器的寄存器窗口读取 Cortex-M7 内核这几个关键寄存器CFSR可配置故障状态寄存器里面细分了 MemManage Fault、BusFault、UsageFault。HFSRHardFault 状态寄存器看 FORCED 位确认是不是下级 Fault 升级。BFAR总线故障地址寄存器如果 BusFault 有效会记录触发故障的访问地址。MMFARMemManage 故障地址寄存器当非法访问内存区域时会记录目标地址。我当时在 HardFault_Handler 停下来先看 HFSR 的 FORCED置位说明确实是从 BusFault 或 UsageFault 升级上来的。再看 CFSRBusFault 那个字段是红的BFAR 指向 0x24000420 附近。看到这个地址我心里就基本有数了这个地址落在 AXI SRAM 区域大概率是某个未初始化的指针或变量被访问了。再回 map 文件一查0x24000420 恰好落在.data_axi或.bss_axi段的范围里。如果 BFAR 指向的是地址 0x20000000 或 0x24000000 附近可以根据地址判断问题出在哪个 RAM 域。这个排查手段比盲目在 main 里打断点高效得多。4.2 单步 Startup 汇编观察拷贝行为拿到 Fault 寄存器后我又在 Reset_Handler 入口打了一个断点从复位开始单步。这样做的目的是确认“变量到底有没有被初始化”。GCC 启动代码的正常流程是从__isr_vector取栈顶指针。调用SystemInit配置时钟和基础外设。执行.data拷贝循环从_sidata复制到_sdata直到_edata。执行.bss清零循环从_sbss到_ebss。调用main。单步到拷贝循环时我打开 Memory 窗口盯着 AXI SRAM 区域 0x24000000 附近看。数据一动不动仍然是 0xFFFFFFFF 或随机值。这里可以百分之百确认启动代码根本没有处理_data_axi这个段。因为拷贝循环的起始地址和结束地址是_sdata、_edata这两个符号只指向 DTCM 上的.dataAXI SRAM 那边没有任何代码去搬运、清零。如果你也看到这种“一个段有初始化、另一个段完全没人管”的情况基本可以直接锁定问题。4.3 对比旧模板和 .map为了进一步确认是 CubeH7 1.13.0 引入的回归我把旧版固件包生成的.ld文件和 1.13.0 生成的.ld文件做了一次 diff。差异非常明显旧链接脚本的.data通常整体放在RAM_D1新模板却引入了“DTCM 放一部分、AXI 放一部分”的拆分。再把旧模板编译出来的 map 文件打开AXI SRAM 段的数据初始化是正常的.data_axi这种额外段根本不存在。这个对比看起来不起眼但能把问题定性为“工具链模板变更导致的回归”而不是“你写的代码逻辑有问题”。以后遇到固件包升级后莫名其妙 HardFault先 diff 链接脚本是最高效的动作。5. 解决方案两个方向任选其一5.1 方案A把所有 .data/.bss 放回同一个 RAM region最省事对于大多数工程我最推荐的做法是改链接脚本把所有.data和.bss统一放到 AXI SRAM也就是RAM_D1。这样修改后startup 代码里现有的搬运循环就能覆盖全部变量不需要动汇编。具体修改很简单。把链接脚本里.data的 DTCMRAM改成 RAM_D1把.data_axi整体删掉.bss同样处理。核心代码如下.data : { . ALIGN(8); _sdata .; *(.data) *(.data*) . ALIGN(8); _edata .; } RAM_D1 AT FLASH .bss : { . ALIGN(8); _sbss .; *(.bss) *(.bss*) . ALIGN(8); _ebss .; } RAM_D1这里有一个细节要注意*(.data*)会匹配.data和.data.xxx这类带长短号的段名。如果你代码里有__attribute__((section(.data_axi)))这样的手动指定段那即使我删除了.data_axi段链接器也可能因为找不到输出段而报错或把变量扔到默认段里。最干净的办法是统一去掉这种section属性或者把.data_axi段重新映射到.data段里。如果你这个工程确实只需要在小 RAM 里跑也可以全部放 DTCM。但我不建议这么做因为 DTCM 只有 128KB而且 DMA 访问不了。一旦后续加音频、显示、网络这类需要 DMA 的功能你会再次被内存布局坑到。5.2 方案B保留多 RAM 布局补齐第二个 RAM 段的启动拷贝如果你的工程确实需要部分变量放在 DTCM、部分放在 AXI SRAM比如中断服务函数里高频访问的热数据放 DTCMDMA 缓冲区放 AXI SRAM那就需要保留多 RAM 布局并补齐第二个 RAM 段的启动初始化。在 GCC 的 startup 汇编文件里一般会有一段类似这样的数据拷贝逻辑CopyDataInit: ldr r3, _sidata ldr r3, [r3, r0] str r3, [r1, r0] adds r0, r0, #4 cmp r0, r2 bcc CopyDataInit你需要在原有.data拷贝循环之后追加一份针对.data_axi的拷贝循环同时针对 .