Keil MDK手动配置.sct：STM32堆栈与RAM分区完全指南

上个月调一个跑 FreeRTOS 的 STM32 项目任务栈明明已经开得很大结果运行十几分钟就莫名其妙 HardFault。折腾一整天后我把目光从业务代码移到了.sct文件上——检查完 Keil MDK 里分散加载文件的布局才发现问题根本不在一行业务代码上而在于 RAM 的“区域山头”没有划清楚。这篇就从那次经历说起把 Keil MDK 中.sct文件手动配置 STM32 堆栈内存区域这件事从原理讲到你也能照着做的程度。如果你现在遇到三类问题——RAM 明明够用却总栈溢出、想把某个缓冲区放到指定地址、做 IAP 或 Bootloader 时 App 启动会冲掉 Boot 的数据——那这篇内容就是为你准备的。1. 为什么需要手动改.sct默认配置满足不了的三类场景1.1 你其实一直在用自动生成的.sct很多 Keil 用户从建工程到产品落地都没有主动看过.sct文件。这不是你的问题因为 Keil 默认帮我们做了所有事在 Options for Target 的 Target 页面选好芯片型号后链接器会根据 Device 里的 Flash 和 RAM 参数自动生成一份分散加载描述文件。它在工程里不一定显式显示但在链接阶段真实参与了内存布局的最终决策。说得直白一点.sct文件就是一张“内存施工图”哪块 Flash 放代码哪段 RAM 放变量栈和堆落在哪里、能给多大空间最终都由它说了算。启动文件里Stack_Size EQU 0x400之类的内容只是一个“需求申请”到底批不批、批多大还要看.sct给这个区域留了多少“地皮”。我见过太多人只改启动文件里的Stack_Size改完发现栈还是溢出原因就在这里——上游的.sct没动你申请了再大的栈链接器也只能把它塞进有限的可写执行域里塞不下就直接报错或者彼此挤压。1.2 非改不可的三类典型场景那到底什么时候需要手动接管.sct我个人归纳下来绝大多数是这三类情况。第一类默认栈和堆确实不够用。Keil 新建工程默认给栈 0x400 即 1KB堆 0x200 即 512B。跑个裸机点灯绰绰有余但一旦引入 RTOS、LwIP、emWin 这类“内存大户”1KB 的栈在中断嵌套深一点、调用链长一点的时候必爆。512B 的堆如果你再调用malloc或浮点格式化打印很快也会告急。此时你要么加大栈要么把堆独立出来这就必须落到.sct上。第二类需要把指定数据放到指定 RAM 地址。比如 DMA 缓冲区希望固定在某一段 SRAM采集数据段希望按地址对齐方便调试这类要求单纯靠编译器__attribute__((section()))还不够执行域不给你划分好你指定到哪都会和别的变量抢地盘。第三类IAP / Bootloader 场景中的 RAM 避让。Boot 程序运行时会在 RAM 里保留通信帧、升级标志、跳转参数等数据App 启动后如果直接把自己的 RW 区从0x20000000开始清零这些数据就被一把梭了。正确的做法是在 App 的.sct里把 RAM 起始地址往后挪一段给 Boot 的数据区留出生存空间。如果你只是纯裸机、代码量小、中断也不深那我建议别折腾.sct默认配置够用且稳定。但前面说的三类场景只要你沾上一条手动配置就是刚需。1.3 什么时候不需要动它还有一类情况我建议你不要动就是当你的 Flash 和 RAM 都很宽裕整个工程只有一个 main 循环你不需要精确掌控任何内存边界时手动改.sct只会引入额外的维护成本。毕竟.sct不像 C 代码那样有编译期检查地址重叠、方向写反这类问题往往要跑到运行时才暴露。所以正确的心态是.sct是一个留给需要精确内存布局的人的“高级接口”而不是一个“默认就要改”的常规配置项。2. 分散加载文件的关键语法看懂一段.sct等于看懂一半2.1 加载域和执行域一张 RAM/Flash 的“施工图”要理解.sct先要分清两个容易混淆的概念加载域Load Region和执行域Execution Region。加载域描述的是程序烧录后在 Flash 里的存放状态也就是“镜像在非运行状态下长什么样”。执行域描述的是程序运行时代码和数据在内存中实际对应的地址空间。比如常量字符串一开始放在 Flash 里运行时如果被放在只读区域就直接从 Flash 执行变量则必须放在 RAM 里启动时由 scatterload 过程把初始值从 Flash 拷贝到 RAM这中间 Flash 是加载域RAM 是执行域。通常一个.sct最外层有一个或几个加载域里面包含若干执行域。对 STM32 这种内部 Flash 跑代码、内部 RAM 放数据的经典架构来说最常见的就是一个 Flash 加载域 一个 RAM 执行域。当你把内存区域细分时实际上是在加载域内部增加更多的执行域。2.2 默认sct逐行拆解拿 STM32F407ZET6 举例Keil 自动生成的.sct大致长这样LR_IROM1 0x08000000 0x00100000 { ER_IROM1 0x08000000 0x00100000 { *(RESET, First) *(InRoot$$Sections) .ANY (RO) .ANY (XO) } RW_IRAM1 0x20000000 0x00020000 { .ANY (RW ZI) } }LR_IROM1 0x08000000 0x00100000定义了一个名为LR_IROM1的加载域起始地址0x08000000最大长度0x00100000即 1MB对应片上 Flash 的大小。ER_IROM1 0x08000000 0x00100000是第一个执行域同样从 Flash 起始地址开始。这个大括号里的*(RESET, First)强制把中断向量表放在这个执行域的最前面*(InRoot$$Sections)把启动代码需要的根段放进来.ANY (RO)和.ANY (XO)就是把所有只读段和只读可执行段“随便”放进这个区域。这里的.ANY你可以理解为“只要这个执行域还装得下就往里塞”链接器会自行做分配。RW_IRAM1 0x20000000 0x00020000是第二个执行域起始0x20000000长度0x00020000即 128KB对应片上 RAM。RW表示可读写数据段ZI表示零初始化数据段启动文件里的STACK和HEAP段因为没有初始值本质上也属于 ZI 类会被打包到这里面来。这段内容就是“所有变量、启动栈、堆都在一个 128KB 的大框里自由分配”的约束。自由意味着不可控这正是问题所在。2.3 ARM_LIB_STACK和ARM_LIB_HEAP的写法手动配置堆栈的核心是在执行域后面显式增加ARM_LIB_STACK和ARM_LIB_HEAP区域。它们不是随便起的名字而是 ARM C 库约定好的两个特殊执行域标准 C 库在初始化时会去识别这两个区域并把堆和栈的地址范围定位到这里。语法是这样的ARM_LIB_HEAP 0x2001D000 EMPTY 0x00001000 {} ARM_LIB_STACK 0x2001E000 EMPTY 0x00002000 {}第一次看到EMPTY后面跟数字的时候我愣了一下后来才明白EMPTY表示这块区域不加载任何初始数据它的地址空间是“保留”出来的。后面的长度如果是正数表示从起始地址向高地址方向扩展如果是负数表示从起始地址向低地址方向扩展。对于栈来说因为 Cortex-M 的栈是向下增长的你希望栈顶落在高地址栈向低地址延伸所以通常写成EMPTY -0x00002000这种负数形式才符合“栈顶在高位、栈向下生长”的自然语义。如果写成正数表面上看区域大小没变但实际方向的差别会在运行时产生各种奇怪问题这一点我在后面的踩坑部分再展开。3. 实战把栈和堆钉在RAM指定位置3.1 先做内存账本动手改之前我强烈建议你拿纸笔先算一笔内存账。以 STM32F407ZET6 为例RAM 共 128KB地址范围从0x20000000到0x2001FFFF。规划如下普通变量、全局数组、RTOS 静态任务栈统一放在 RW 数据区规划为 112KB地址0x20000000到0x2001BFFF。保留 4KB 作为堆栈之间的“安全隔离带”地址0x2001C000到0x2001CFFF。标准 C 库堆规划 4KB地址0x2001D000到0x2001DFFF。标准 C 库栈规划 8KB地址0x2001E000到0x2001FFFF。合起来正好 128KB。这里留隔离带不是因为堆栈一定会碰到而是嵌入式开发里最怕“偶发越界”。堆向上长栈向下长中间没有隔离的话两者在某一个极端情况下相遇几乎无感知直到系统崩了才去查那时已经晚了。后端0x0001BFFF上界的算法是0x20000000 112 * 1024 - 1。如果你不太习惯十六进制直接按字节算更清晰112KB 等于0x1C000字节所以 RW 区结束地址是0x20000000 0x1C000 - 1 0x2001BFFF。3.2 接管分散加载工程设置关键开关下面进入实际操作。在 Keil 中打开 Options for Target切到 Linker 页面你会看到一个关键的勾选项Use Memory Layout from Target Dialog。这个名字翻译过来就是“使用 Target 对话框里的内存布局”。默认情况下它是勾选的此时.sct文件由编译器根据 Target 页面的参数自动生成你写的任何.sct都不会生效。要手动接管就必须取消这个勾选。取消后下面的Scatter File输入框变为可编辑状态你可以点击旁边的 Edit 按钮直接创建或打开刚才规划好的.sct文件。我建议这个文件放在工程目录下一个固定的子目录里不要放在系统临时目录这样项目换电脑编译时不会丢失。这里有一个很多人踩过的坑取消勾选并把.sct文件写好后又回到 Target 页面改了 RAM 大小或起始地址改完发现链接结果没变化。这是正常的因为此时 Target 页面的参数只影响调试器的内存映射和下载算法不再参与链接器布局。换句话说链接器只认你手写的.sctTarget 页面已经“退居二线”了。3.3 手写.sct文件基于上面的规划完整的.sct文件我给出一个当前项目里验证过的版本LR_IROM1 0x08000000 0x00100000 { ER_IROM1 0x08000000 0x00100000 { *(RESET, First) *(InRoot$$Sections) .ANY (RO) .ANY (XO) } RW_IRAM1 0x20000000 0x0001C000 { .ANY (RW ZI) } ARM_LIB_HEAP 0x2001D000 EMPTY 0x00001000 { } ARM_LIB_STACK 0x20020000 EMPTY -0x00002000 { } }逐块解释一下。RW_IRAM1 0x20000000 0x0001C000覆盖了0x20000000到0x2001C000的 112KB 区间。启动文件里的临时栈段、全局变量、static变量、RTOS 控制块等都会在这一段里分配。之所以仍然叫RW_IRAM1是为了和默认文件保持命名一致减少陌生感你可以改名但要注意 MAP 文件里的名字也会跟着变。ARM_LIB_HEAP 0x2001D000 EMPTY 0x00001000这一行表示堆的起始地址是0x2001D000向上扩展 4KB到0x2001E000结束。这里长度用了正数因为堆是向上增长的从低地址向高地址用正数正好对应这个方向。ARM_LIB_STACK 0x20020000 EMPTY -0x00002000表示栈顶是 RAM 的最高地址0x20020000向下扩展 8KB到0x2001E000结束。这样堆的末尾和栈的底端在0x2001E000处接壤中间没有空隙等于把 RAM 的每一字节都利用上了。当时我为了验证地址算得对不对专门把起始地址、长度都写成了宏一样清晰的格式并对着 Datasheet 的内存映射看了三遍。这里真心建议你不要凭感觉估地址用计算器算好再填。3.4 配合启动文件和标准C库.sct文件写好后还要注意启动文件和 C 库设置的配合。在 Keil 中新建的 STM32 工程启动文件里通常有类似这样的内容Stack_Size EQU 0x00000400 AREA STACK, NOINIT, READWRITE, ALIGN3 Stack_Mem SPACE Stack_Size __initial_sp Heap_Size EQU 0x00000200 AREA HEAP, NOINIT, READWRITE, ALIGN3 __heap_base Heap_Mem SPACE Heap_Size __heap_limit这段代码定义了一个 1KB 的启动栈和一个 512B 的启动堆。很多人的理解是“栈大小就是在这里改的”这句话放在默认.sct下没毛病因为你改了Stack_Size启动文件的栈段作为一个 ZI 段会被链接器放进RW_IRAM1里最终栈的大小由这个值决定。但当你手动接管.sct并使用了ARM_LIB_STACK和ARM_LIB_HEAP之后事情就微妙起来。标准 C 库在__main初始化流程里会调用__user_initial_stackheap之类的库函数并根据ARM_LIB_STACK/ARM_LIB_HEAP这两个区域来确定运行时的栈和堆。启动文件里的STACK段更多承担的是“复位后、C 库接管前”这一段极短时间的临时栈职责。所以我的建议是启动文件里的临时栈不要删把Stack_Size调小一点比如保持 1KB 足够真正的大栈交给ARM_LIB_STACK去分配堆也可以类似处理如果工程使用了标准 C 库的malloc、printf浮点等能力运行时的堆会落在ARM_LIB_HEAP区域里。这种“小临时栈 大运行栈”的分工模式我在多个跑 LwIP 和 emWin 的工程里验证过稳定性和可维护性都不错。还要提醒一点如果你在 C/C 选项里勾选了Use MicroLIB标准 C 库那套ARM_LIB_HEAP/ARM_LIB_STACK的机制基本不参与工作此时堆和栈的大小就主要由启动文件里的Stack_Size和Heap_Size控制。换句话说MicroLIB 和.sct里的这两个特殊区域是两套体系别混着用。我一般在不勾选 MicroLIB 的工程里才手动写这两个区域。3.5 进阶给Bootloader让出一段RAM同类思路可以延伸到 Bootloader 和 App 的内存避让。假设 Boot 程序运行时需要占用 RAM 低地址的 8KBApp 的.sct就可以这样写RW_IRAM1 0x20002000 0x0001A000 { .ANY (RW ZI) }这里把 App 的 RW 区起始地址从0x20000000挪到了0x20002000也就是把低地址 8KB 完整地让给了 Boot。App 启动时 scatterload 过程只会清零自己执行域范围内的区域不会再破坏 Boot 写在低地址的数据。有同学会问那 Boot 和 App 之间怎么传数据很简单双方约定好一个固定的地址区间Boot 往里面写App 用指针读取。关键前提就是App 的.sct必须保证自己的 RW 区和 ZI 区不会去覆盖那个约定区间。这是 OTA 工程中非常典型的应用也是我在做过一次远程升级后对.sct彻底改观的原因——它不只是排错工具更是架构工具。4. 验证与调试确认配置真正生效4.1 从MAP文件看三种区域改完.sct后先别急着点下载。我习惯先编译然后打开工程目录下 Listings 文件夹里的.map文件做一次“体检”。用文本编辑器打开.map文件后搜索Execution Region重点看三个关键区域Execution Region RW_IRAM1 (Exec base: 0x20000000, Size: 0x00001234, Max: 0x0001C000) Execution Region ARM_LIB_HEAP (Base: 0x2001D000, Size: 0x00001000, Max: 0x00001000) Execution Region ARM_LIB_STACK (Base: 0x2001E000, Size: 0x00002000, Max: 0x00002000)Max字段尤其重要它表示这个执行域允许的最大容量。如果RW_IRAM1的Size已经非常接近Max说明 112KB 的数据区快满了后面再新增全局变量就会链接报错或需要重新规划。ARM_LIB_STACK的Size必须是0x2000ARM_LIB_HEAP的Size必须是0x1000这是验证.sct有没有按你的预期生效的最直接证据。如果这两个区域在.map文件里根本搜不到或者Size是 0那就要回头检查你是否启用了 MicroLIB或者.sct是否真的被链接器读取了。另外一个值得搜的符号是__initial_sp它是启动文件里定义的栈顶标签。你可以确认它的值是否和预期一致。__initial_sp 0x20020000如果__initial_sp仍然是启动文件里的默认栈顶位置也不奇怪因为运行时的主栈在标准 C 库接管后会切换到ARM_LIB_STACK区域这里只要确保它存在且指向一个有效 RAM 地址就可以了。4.2 调试器里的SP和内存侦查编译通过不代表运行正确。下载后把断点停在main函数入口这个时候 C 库已经完成初始化看寄存器窗口里的 SP 值应该是落在0x2001E000到0x20020000这个区间内。如果你发现 SP 还在0x20000000附近说明标准 C 库并没有使用ARM_LIB_STACK区域此时要么是 MicroLIB 被勾选了要么是启动代码在进入main前又重新设置了栈指针。进一步内存侦查的方法是打开 Debug 里的 Memory 窗口输入0x2001E000观察从栈底到栈顶这段区域的数据。如果栈上已经跑了一些函数调用高地址部分应该能看到函数返回地址、局部变量等有意义的数据而低地址部分通常还是初始化的填充值比如0xCC或0x00。当你有意识地在一段程序运行前后对比这段内存的变化就能直观感受到栈的增长和回缩。4.3 用栈水位检测代替猜最后分享一个我常用的土办法栈水位检测。在工程里加一个简单的检查函数周期读取当前栈指针计算它到栈底的距离记录历史最大使用量。uint32_t g_stack_max_used 0; const uint32_t g_stack_top 0x20020000u; const uint32_t g_stack_bottom 0x2001E000u; void check_stack_watermark(void) { uint32_t sp __get_MSP(); if (sp g_stack_bottom sp g_stack_top) { uint32_t used g_stack_top - sp; if (used g_stack_max_used) { g_stack_max_used used; } } }把这个函数放在 main 的 while(1) 循环里周期调用或者放在 RTOS 的空闲任务中运行一段时间后看g_stack_max_used的值你就能知道 8KB 的栈到底用了多少。如果峰值已经接近 8KB说明栈还得加大如果长期只有几百字节说明栈规划有余量可以适当缩小给数据区腾空间。这种“不靠猜、靠数据”的做法让我避开了很多次栈爆带来的谜之 HardFault。它虽然土但在没有专业性能分析工具的场合确实最有效。5. 踩坑日志五个最容易翻车的细节与完整排查思路5.1 坑1改了sct链接器却“不鸟我”现象很典型写好了.sct编译链接后打开.map文件一看内存布局还是老样子和没改一样。第一次遇到这个问题我排查了很久最后发现是Use Memory Layout from Target Dialog没有取消勾选。这个问题说起来简单但非常容易忽略尤其是工程被同事从旧版本迁移过来时Linker 页面的配置可能被重置过。排查链路很简单先确认 Linker 页面里有没有勾选“自动生成”再确认 Scatter File 路径指向的文件确实是你在编辑的那个文件。还有一种情况是工程里有多个.sct文件你改的是 A 文件Linker 里指定的是 B 文件这种低级错误我也犯过。建议在 Scatter File 输入框里把路径写全不要在多个同名文件之间全靠“猜”。5.2 坑2EMPTY长度写反RAM布局整体错位这是最凶险的一个坑因为表面看地址和大小都合理但实际保留的区域方向错了。我调试过的一个工程错误写法是这样的ARM_LIB_STACK 0x20020000 EMPTY 0x00002000 {}长度写成了正数。它的本意是让栈从0x20020000向上扩展 8KB但0x20020000已经是物理 RAM 的末尾了再向上扩展就越界了。链接器不一定在链接阶段就报错程序可能能编译通过并烧录但运行时一旦栈增长就会访问到不存在的地址空间产生 HardFault。如果你确实想把栈顶放在 RAM 最高地址负数的写法才是正确的ARM_LIB_STACK 0x20020000 EMPTY -0x00002000 {}排查这种问题时建议先打开 Memory 窗口把地址定位到0x20020000 - 0x2000也就是0x2001E000看这个地址是否在你预想的栈区域内。如果在调试器里发现程序一运行 SP 就在 RAM 地址范围之外或者执行几步就跳进 HardFault_Handler优先回头检查 EMPTY 的正负号和起始地址。5.3 坑3删除启动文件STACK段的连锁反应网上有些教程会告诉你既然在.sct里显式定义了ARM_LIB_STACK启动文件里的 STACK 段就可以删掉了省一点 RAM。我试过结果摔得很惨。删掉STACK段后启动文件里就没有__initial_sp了链接器直接报Undefined symbol __initial_sp。如果你强行在其他地方补一个符号又可能出现复位向量表第一项指向的地址不在 RAM 里的问题程序上电即跑飞。后来我查了 ARM 的启动流程才明白__initial_sp是复位后硬件从向量表第一项自动加载到 SP 的值在标准 C 库接管之前处理器必须要有一个可用的栈。你可以把它理解成一个“临时脚手架”——虽然最终干活的是ARM_LIB_STACK但从上电到__main完成初始化之间总得有个地方放第一次函数调用的返回地址。所以我的经验是启动文件的 STACK 段保留大小可以调小但绝对不能删。同理HEAP 段我一般也保留因为就算标准 C 库的堆在ARM_LIB_HEAP区域工作也不能保证所有场景下都不需要启动阶段的最小堆。5.4 坑4DMA缓冲区与栈区重叠另一个隐蔽问题是当你在.sct里调整了 RAM 分配但 DMA 缓冲区是通过普通 C 数组声明时它的地址是由链接器在RW_IRAM1执行域里随便分配的。如果这个数组比较大链接器可能会把它放在紧挨着栈靠近堆的位置某些时候 DMA 写满缓冲区就会和栈增长区域发生碰撞。表现形式是程序大部分时间正常但一旦 DMA 收到一帧特定长度的数据系统就会死机或者数据被莫名其妙改写。排查思路是先打开.map文件找到那个 DMA 缓冲数组的地址判断它落在哪个执行域、离ARM_LIB_STACK或ARM_LIB_HEAP有多远。如果确实挨得太近解决方法是把 DMA 缓冲区单独放到一个固定地址的执行域里或者至少用__attribute__((section(.dma_buf)))把它放进一个独立段然后在.sct里给这个执行域单独划分空间。我在做串口 DMA 接收时就是这么处理的稳定之后几乎没有再遇到 DMA 和栈打架的问题。5.5 坑5只改了Target页RAM地址却不生效最后一个坑来自对 Keil 操作界面的误解。有人以为在 Target 页面把 RAM 地址改成0x20002000、大小改成0x1E000就能让 App 避开 Boot 的 RAM 区域。实际上在手动接管.sct之前Target 页面的这些修改只是“建议”自动生成的.sct可能会把你的修改作为输入但一旦你取消勾选自动生成Target 页面的 RAM 参数就被架空了。正确的姿势是直接改.sct里的RW_IRAM1起始地址和最大长度然后重新编译。如果你想调试时内存窗口也按新的 RAM 地址映射再去 Target 页面同步一下调试器的 RAM 参数。这二者是两套配置不要混为一谈。排查这类问题最快的方法还是回到.map文件看RW_IRAM1的Exec base和Max这两个字段直接反映链接器实际采用的地址范围比任何界面上的配置都真实。5.6 把这些坑串起来的排查心法总结一下碰到.sct相关问题我现在的排查顺序已经固定了先看.map文件确认链接器实际认了哪些执行域再看__initial_sp、ARM_LIB_STACK、ARM_LIB_HEAP三个关键符号的地址接着在调试器里确认 SP 是否落在预期栈区最后用栈水位检测程序跑一段时间拿到真实用量数据。这个顺序能覆盖我踩过的绝大多数坑也让我从“凭感觉猜内存布局”变成了“按数据排查内存布局”。如果你也经常被 KM 内存问题折磨我建议你把这一套流程沉淀成自己的排查清单。