做多媒体类固件，最头疼的就是内部RAM不够用。视频帧缓冲、音频环形队列、GUI显存，哪个都是几十KB起步，Cortex-M核的片上SRAM通常只有几百KB。于是大家想到外部SDRAM：容量大、价格便宜，几乎是这类项目的标配。Keil MDK里想把变量放过去，干净的做法不是手动分配指针，而是用分散加载文件（.sct）把某个执行Region指到SDRAM物理地址，然后让大数组通过段属性定义进去。这个方案我反复用过多次，也总能在技术群里看到同一种疑问：明明按教程写了.sct，变量也确实出现在地址0xC0000000，可为什么上电后内容会变零？为什么换成某个属性又不零了？这篇文章就围绕“外部SDRAM变零定义”这件事，把分散加载文件里的ZI清零机制、UNINIT属性、启动顺序和排查方法一次讲清楚。适合正在调试外扩SDRAM的MCU固件开发者，也适合刚接触MDK分散加载、第一次想把大缓冲区搬到外部存储的人。
“外部SDRAM变零定义”拆开看其实是两件事：第一，把变量定义到SDRAM对应的执行区；第二，让这段内存按零初始化方式建立。这中间涉及链接脚本、启动时序、硬件初始化顺序，任何一个环节配合不好，都会出现你不想看到的“变量变零”。下面按我实际的调试顺序来聊。
1. 先弄清分散加载文件在MDK里到底管什么
很多人在写分散加载文件之前，连它为什么存在都没搞清楚，上来就照着网上的片段改，结果不是编译不过就是跑飞。这里我先把最基础的概念捋一遍。MDK工程的Linker页默认有一个“Use Memory Layout from Target Dialog”，这时链接器会根据你在Target页填的ROM/RAM范围自动生成一份.sct脚本。只要项目只用片内Flash和片内SRAM，这份自动生成的东西基本够用。一旦加了外部SDRAM，需要手动定制布局，就必须取消自动勾选，自己维护.sct。所以第一步不是抄脚本，而是看懂脚本在说什么。
1.1 加载域和执行域：一个像仓库、一个像柜台
分散加载文件里两个核心概念是Load Region（加载域）和Execution Region（执行域）。加载域描述程序烧录进Flash后的原始摆放位置，也就是编译器认为数据放在哪里；执行域描述运行时指令和数据出现在哪里。拿超市做类比：加载域是仓库货位，商品先整箱库存；执行域是店面柜台，开门营业时把商品搬上货架。搬货这件事就是C库启动代码__main里的__scatterload。代码段可以原地执行，也可以从Flash拷贝到RAM再执行；全局变量的RW数据同理。一般你只需要在.sct中调整Execution Region，外层用Load Region把各个执行区包起来就行。
有些刚接触的人会问：为什么要把代码或数据从Flash拷到RAM？因为Flash读速慢、且不能随机写，而RAM可以高速读写。RW段有初值，启动时必须把初值从Flash搬到RAM，程序才能正常工作。ZI段没有初值，启动时只需要在RAM里给它清零即可，所以它不占用Flash镜像空间。分散加载文件的价值，就是把每个段安排到它该去的物理位置，并且告诉链接器哪些内容需要搬运、哪些内容直接清零。
1.2 Region属性决定“清零”行为
Execution Region会声明自己接收哪些类型的段。最常见的是RW和ZI：RW段是已初始化数据，有初值，需要从Flash搬运到RAM；ZI段是未初始化但需要清零的数据，链接器不把它放进镜像，却在启动时生成一段“清零记录”，让__scatterload给那块内存写0。这就是“变零定义”的源头：你用section属性把大数组丢进某个Region，如果这个Region是普通ZI属性，运行前CPU会把整块区域都刷成0。还有一个相对陌生的UNINIT属性，它告诉链接器：这块区域不初始化、不清零，内容就是上电后的随机值。
| 属性 | 初值来源 | 启动时是否清零 | 是否占用镜像空间 | 典型用途 |
|---|---|---|---|---|
| RW | 从Flash拷贝初值 | 否（拷贝覆盖） | 是 | 普通已初始化全局变量 |
| ZI | 无初值，CPU写0 | 是 | 否 | 数组、缓冲、内存池 |
| UNINIT | 无初值，保持复位后内容 | 否 | 否 | 缓存、掉电保持区、与外部设备交接区 |
你可能会好奇：既然ZI不需要镜像空间，为什么运行时还要做一次写0？因为C语言对未初始化全局变量的默认语义就是初值为0，链接器负责兜底。外部SDRAM容量大，清零动作耗时也长；如果你不想每次启动都花几百毫秒去清8MB内存，就考虑用UNINIT。这属于后话，先在脑子里留下这个对应关系。
2. 把大数组“钉”进SDRAM：一份可以直接套用的.sct与变量写法
2.1 一份能跑起来的四行脚本
先给一份我在普通Cortex-M项目里常用的模板。假设芯片内部Flash从0x08000000开始、共1MB，内部SRAM从0x20000000开始、共128KB，外部SDRAM基址0xC0000000、容量8MB。注意，最后的地址是SDRAM控制器映射出来的物理地址，具体以你所用芯片的数据手册为准，别把别家板子的地址生搬硬套。
; 手动分散加载文件 .sct LR_IROM1 0x08000000 0x00100000 { ER_IROM1 0x08000000 0x00100000 { *(+RO) } RW_SDRAM 0xC0000000 0x00800000 { *(.SDRAM_BUF) } RW_IRAM1 0x20000000 0x00020000 { *(+RW +ZI) } }这里有个非常关键的书写顺序：RW_SDRAM必须写在RW_IRAM1的前面。ARM的链接器在选择段时按执行域出现的顺序匹配，先被匹配的Region优先拿走它想要的段。如果你把RW_IRAM1放前面，*(+RW +ZI)会顺手把.SDRAM_BUF也收进内部SRAM，你的SDRAM区就是空的，变量长得再大也进不了外部内存。这个坑我见过太多人踩，换一个顺序就解决。
另外，如果你代码里还有其他段名，可以用类似*(.SDRAM_BUF .SDRAM_BUF.*)的写法，让带前缀的段都归入这个Region。比如驱动里常见的__attribute__((section(".SDRAM_BUF.Buff")))这类子段，也能被统一收进来。
2.2 变量声明里的AC5/AC6差异
脚本挂好后，C文件里声明需要特殊段属性的变量。我用过不少工程，发现最容易被忽略的是ARMCC5和AC6的写法差异。ARMCC5里，想让变量进SDRAM并零初始化，可以加编译器扩展的zero_init属性；AC6的clang不认识这个属性，只写section就足够了。为了在两个工具链下都能编译，代码里可以套一个宏分支。
#if defined(__CC_ARM) /* ARMCC5 */ __attribute__((section("SDRAM_BUF"), zero_init)) #elif defined(__clang__) /* AC6 */ __attribute__((section("SDRAM_BUF"))) #endif __attribute__((aligned(32))) uint8_t video_buffer[FRAME_W * FRAME_H * 2];说句实在话，AC6已经是MDK默认编译器了，新工程直接按AC6写法来即可。但老项目从AC5迁移上来时，多半会残留zero_init字样的代码，编译会报错或警告。遇到这种情况，不如直接用上面的宏分支统一处理，避免维护两套源码。
还有一个常见错误：在分散加载文件已经手写的情况下，还在变量上同时使用__attribute__((at(0xC0000000)))做绝对定位。这两个机制会打架，轻则警告，重则变量地址和Region重叠，启动清零时把别的数据也清掉。定下来用.sct，就不要再混用at。
2.3 记得先初始化SDRAM控制器
脚本和变量声明做对了，还不能高兴太早。外部SDRAM不是上电就能访问的，它需要MCU内部的SDRAM控制器配置好时序、刷新率、行列地址宽度，映射才存在。如果清零发生在SDRAM控制器初始化之前，CPU一访问0xC0000000就会触发总线错误，典型现象是启动时直接HardFault。所以SDRAM控制器初始化必须放在分散加载清零动作之前。
放在哪里最合适？启动文件的Reset_Handler流程里，SystemInit是在__main之前被调用的，我习惯把SDRAM控制器初始化放到SystemInit末尾，或者直接在Reset_Handler里调用一个sdram_init()。这里先记结论，第三节我会专门讲为什么顺序差一步，结果就能从“正常变零”变成“复位后变量全乱”。
3. “变零”从哪来：ZI清零的时序与SDRAM初始化顺序
3.1 启动序列里的那几个隐藏步骤
很多工程师对程序入口的理解就是main()，其实在进入你的main之前，C库已经干了一堆事。简单梳理一下：Reset_Handler先调用SystemInit做系统时钟和底层初始化，然后进入__main。__main不是用户函数，而是C库的初始化引导函数；它内部执行__scatterload，把RO/RW数据搬到自己该去的地址，再对ZI区清零，最后才进入__rt_entry并调用用户main。SDRAM清零这个动作，就藏在__scatterload的__scatterload_zeroinit步骤里。
这个顺序意味着：所有需要在清零前完成的外设初始化，必须放在SystemInit或更早的启动代码中。如果你习惯把外设初始化都塞进用户main，那你的SDRAM大数组想被正常清零，就得看运气。
3.2 为什么你的变量一上电就“变成0”
清楚了时序就能解释现象。假设你没有在SystemInit里配SDRAM控制器，而是把sdram_init放在用户main开头执行，那么__scatterload清零SDRAM区时，SDRAM控制器还没初始化，读写全是无效总线访问。运气好一点的平台，这次清零静默失败，你main里再手动赋初值还能用；较真的平台直接HardFault，连main的门口都到不了。
另一类情况是控制器初始化了，清零本身也执行了，那变量在进入用户代码之前就是全零。这是预期的“变零定义”，不是bug。真正常见的误判是：看到调试器里变量显示0，就以为被某段代码误清零，其实它只是刚经历过ZI清零而已。要区分这两件事，最好的办法是在启动流程里下断点，观察第一次写入0的时刻。
3.3 在SystemInit里给SDRAM“通电”
所以想让SDRAM区以普通ZI方式使用，配置控制器的位置很关键。我的做法是写一个sdram_init()，放在SystemInit函数末尾调用。注意两点：一是SDRAM的GPIO复用、时钟使能也要一并提前，很多板子的芯片引脚默认不是复用为SDRAM信号，漏配任何一个位，地址线上拉不出波形；二是加一个“已经初始化”的标志位，避免在BootLoader跳转APP等场景下重复配置导致SDRAM自刷新失效。如果芯片自带SDRAMC且上电后默认关闭，也可以在Reset_Handler里调用，只要保证在__main之前即可。
验证方法也顺手分享：在__scatterload_zeroinit处下一个断点，单步进入后，观察清零的起始地址和长度是否包含了0xC0000000。我在某个实践中，第一次就是在这里发现清零范围被链接器算成了“SDRAM区加一点点尾巴”，原因是.map里某段名字打字打错了，多了个前缀点，导致大数组根本没进SDRAM区。
4. 不想每次清零？UNINIT区和三个最隐蔽的变零现场
4.1 UNINIT：一次配置，永不自动清零
如果你需要的不是一个强制初始化为0的数组，而是缓存、掉电保持数据、或者和DMA共享的搬运区，用普通ZI反而是一种负担。启动时清理几十MB的SDRAM，在慢速芯片上可能要烧掉大把启动时间。这时把Region改成UNINIT，链接器就不生成清零记录，也不往镜像里塞初值。脚本只需在Region名后、长度前加一个UNINIT关键字。
RW_SDRAM 0xC0000000 UNINIT 0x00800000 { *(.SDRAM_BUF) }注意，UNINIT不等于初值为0，它的内容是SDRAM上电后的随机状态，可能是上一次进程残留，也可能是完全乱码。产品里如果依赖这块区域放关键数据，就得自己设计初始化标志。我常用magic number方式：区域头部放一个魔数，每次上电检查，不是约定值就整体清零，否则认为数据有效直接使用。这样既回避了大体积清零的耗时，又保留了“冷启动清零一次”的能力。完全放飞的后果是，你永远不知道第一帧画面看到的是什么花屏。
| 使用场景 | 建议属性 |
|---|---|
| 视频帧缓冲，需要上电黑屏 | ZI（系统自动清零） |
| 音频环形队列，内容迟早被覆盖 | UNINIT |
| 低功耗唤醒后要保留的数据 | UNINIT + magic校验 |
| 掉电保存参数（SDRAM本身易失） | 不要用SDRAM，放非易失存储 |
4.2 低功耗和硬件自刷新：SDRAM“失忆”的另一条路
这里的“变零”和分散加载没有关系，但很多项目是排查到最后才发现问题出在硬件。SDRAM是动态RAM，需要持续刷新保持电荷。MCU进低功耗时，如果SDRAM控制器没有进入self-refresh模式，唤醒后内存内容可能已经丢了。表现就是：变量在主循环里看起来正常，进一次睡眠再醒来，数据就变成0或者随机数。这种问题靠软件清零逻辑是排查不出来的。
你可以做一个最简单的压测：往SDRAM区写满0xAA，进低功耗再唤醒，读回来比对。对不上就先查低功耗配置，而不是怀疑分散加载文件。有些平台的SDRAM控制器需要在进入低功耗前显式切到self-refresh，唤醒后再退出；这些代码必须放在低功耗流程里，不能指望它自动完成。
4.3 Cache、DMA和地址重叠：三个比清零更隐蔽的元凶
有时候变量地址确实在SDRAM区，但运行中被改成了0，那就得查三类因素。
第一，如果MCU带D-Cache且SDRAM区被配置为cacheable，CPU写的数可能留在cache里没写回，DMA外设读到的还是旧值；反过来DMA刚写入的数据，CPU又可能读到cache里的陈旧0。解决方案是用MPU把SDRAM区设为non-cacheable，或者对关键操作手动clean/invalidate。
第二，DMA描述符或缓冲区无意中指向SDRAM，当外设产生中断时把变量区当成了目标地址，一传输就覆盖为零。这种坑不好查，只能靠断点监视变量地址，或者用内存保护单元设成只读来拦住非法写。
第三，地址重叠：另一个Region的地址和SDRAM区重叠，或代码里某个裸指针把0xC0000000当成普通内存起始地址去操作，结果写坏了同区相邻变量。我用过一个小技巧：在.map文件里按地址排序，把所有执行Region的地址范围画出来看有没有重叠，一眼就能发现。
5. 用MAP和fromelf核对布局，顺手把启动时间省下来
5.1 怎么看.map文件确认变量到底放哪了
写了.sct之后，最担心的是变量没进SDRAM区却也没报错。这时别猜，直接打开Build Output里生成的.map文件。找Execution Region那一节，你会看到类似下面的记录。
Execution Region RW_SDRAM (Exec base: 0xc0000000, Load base: 0x00000000, Size: 0x01000000, Max: 0x00800000) ... video_buffer 0xc0000000 0x00400000 ...只要Exec base落在SDRAM基址，Size不超过Region容量，就说明段名匹配成功。假如Exec base变成0x20000000，多半是脚本里Region顺序写反，或者选择器没匹配到。再配合C代码里打印printf("0x%08X\n", (uint32_t)&video_buffer);，地址一跑就能验证。
如果SDRAM区Size显示为0x00000000，而你明明塞了大数组，先检查section名的大小写。ARM的段名选择在部分编译器下区分大小写，.SDRAM_BUF和.sdram_buf是两回事。还有一个容易被忽略的：变量如果加了static，编译器可能对它做优化，导致它根本没进SDRAM区，而是留在内部SRAM甚至寄存器里。要强制它进段，可以加__attribute__((used))，或者通过外部函数引用它。
5.2 fromelf的小命令：一眼看出加载域占用
除了.map文件，还有一条命令行工具我很常用。MDK安装目录下的fromelf可以导出镜像的布局信息，特别是分散加载的Region和大小。命令示例：
fromelf --text -z -o scatter_report.txt project.axf生成的文件里会列出每个Load Region和Execution Region的Size、ZI数据量。你重点看两个数字：SDRAM区的Size代表运行时占用，Load Size代表烧进Flash的占用。普通ZI或UNINIT区的Load Size通常为0，意思是程序烧录文件里没有这一大坨内容，全部靠启动时临时生成。这一点对镜像大小影响极大，32MB的帧缓冲如果错误地被当成RW初始数据，Flash里就要塞32MB初值，可能直接把合法镜像容量撑爆。
我在一个实际项目里就遇过这种问题：同事把SDRAM大数组用= {0}的方式初始化成了RW数据，结果是每帧画面需要的初值全部写进Flash，烧录文件直接多出几十MB。改成分散加载文件里的ZI段之后，镜像立刻恢复正常。所以写完.sct后，用fromelf查一次Load Size，是成本最低的验收手段。
5.3 顺手一提：启动时间怎么省下来
弄明白清零机制之后，启动时间优化的思路也就清晰了。SDRAM区用UNINIT，不清零，启动少一大截时间；代价是数据初值不可预期，适合缓存类。如果一定要清零但只想冷启动清一次，单纯靠ZI办不到，因为C库启动每次都会清零。工程上常见折中：Region设UNINIT，用户模块从SDRAM区前4字节读magic，不等于预定值就执行一次memset并把magic写入；等于就直接使用。热复位时SDRAM数据还在（前提是自刷新配置正确），看到了magic就跳过清零，启动速度能压进毫秒级。这个模式我在某个音频项目里用过，效果很直接。
另外，链接器会给每一个执行域生成Image$$RW_SDRAM$$Base和Image$$RW_SDRAM$$Limit这类符号，在C代码里也能拿到Region基址和长度，方便做内存池初始化。
最后说一个我调试这类问题时形成的肌肉记忆：改完.sct，不要急着下载跑业务，先看两个地方——map文件里SDRAM区有没有变量、SystemInit里SDRAM控制器是不是在__main之前配置完成。这两点确认过，再谈业务逻辑。外部SDRAM“变零”的大多数事故，根子都在启动时序而不是业务代码。如果你正准备把大缓冲区搬进外部SDRAM，照着上面的流程走一遍，能少踩好几个坑。
