做多媒体类固件最头疼的就是内部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和ZIRW段是已初始化数据有初值需要从Flash搬运到RAMZI段是未初始化但需要清零的数据链接器不把它放进镜像却在启动时生成一段“清零记录”让__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区被配置为cacheableCPU写的数可能留在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照着上面的流程走一遍能少踩好几个坑。
