在 Keil MDK 里写单片机程序大部分人都是从点亮一个 GPIO 开始的那时候根本不用关心变量放在哪、函数编成什么样。但只要你开始做 Bootloader、做外部 SDRAM、做固件升级或者调试遇到“变量莫名其妙被优化掉”“函数跑飞了”这类问题就会意识到一件事编译器给你安排的“落脚点”并不总是你想要的位置。这篇博文想认真聊一聊 Keil MDK 中的变量属性、函数属性以及如何通过指定变量地址和段地址把程序的内存布局牢牢掌控在自己手里。内容主要围绕 ARM 内核单片机以 STM32 为例会对比 Arm Compiler 5AC5和 Arm Compiler 6AC6也就是 armclang的差异也会讲清楚分散加载文件scatter file怎么和__attribute__配合。适合已经写了一阵子固件、想进一步理解链接过程或者正在被“地址不对”“段重叠”问题折磨的开发者。1. 先搞清楚编译器凭什么给变量分配地址1.1 默认的内存布局是怎么来的C 语言编译出来之后变量和函数不是凭空出现在内存里的而是被归类到不同的“段”section。比如RO只读常量、字符串字面量、const变量、函数代码text 段通常也属于 RO。RW可读可写初始化了非零值的全局变量和静态变量。ZI零初始化默认初始化为 0 的全局变量和静态变量以及未显式初始化的变量。链接器拿到这些段之后再按照你指定的链接脚本在 MDK 中就是分散加载文件.sct把它们放到对应的执行区域。默认情况下STM32 工程里的 RW 和 ZI 都会被放到片内 SRAM比如0x20000000开头的区域RO 放到片内 Flash比如0x08000000开头的区域。这个过程看着挺自动化的但问题在于它默认把一堆变量连续排列在一起具体哪个变量在哪个地址你并不知道。1.2 哪些场景必须手动干预我归纳了一下平时会用到“指定地址”或“指定段”的场景主要有这几类把大块缓冲区放到外部 SDRAM。比如 LCD 显存、摄像头帧缓冲动辄几百 KB片内 SRAM 放不下。把某些关键参数写到 Flash 固定地址。比如 bootloader 和 app 之间的标志位、设备序列号、校准参数。把中断向量表重映射到 RAM。某些低功耗模式或 IAP 升级时需要从 RAM 启动。把 Flash 擦写函数放到 RAM 运行。因为执行 Flash 编程操作时代码不能同时从同一块 Flash 取指否则会出问题。把某个变量固定放在某个外设总线地址上。这里更多是寄存器映射但有时也需要把一个普通变量放到共享内存地址比如双核通信的共享 RAM。调试问题需要确认某个全局变量是否被优化、是否被放在预期位置。这些场景里单纯靠编译器默认的内存布局很难满足所以必须要学会“点对点”地控制。MDK 提供的方式就两个方向一是用关键字和__attribute__给变量/函数打上属性二是用分散加载文件配合链接器做布局。两者组合使用才能灵活落地。2. 变量属性让每个变量待在它该待的地方2.1 最常用的变量属性和写法在 GCC 风格的编译器里__attribute__是控制变量和函数属性最重要的语法入口。Keil MDK 的 AC5 和 AC6 都支持只是某些细节有差异。先说变量属性里最常用的几个。__attribute__((at(address)))这是 AC5 下最“直觉”的写法直接把变量放在指定地址__attribute__((at(0x20001000))) uint32_t my_var;但这里有个坑at语法在 AC6armclang里不再被支持。AC6 是一个基于 Clang 的编译器它更推荐使用__attribute__((section(name)))配合分散加载文件来把变量放到指定段。如果硬要在 AC6 里用at通常是给变量指定一个自定义段然后在 scatter 文件里把它固定到某个地址。__attribute__((section(name)))这是最通用、最推荐的方式。它将变量放入自定义段之后由链接器决定段的最终地址。例如__attribute__((section(.sdram_data), zero_init)) uint8_t framebuffer[800 * 480 * 2];配合 scatter 文件我可以把.sdram_data段放到外部 SDRAM 的0xC0000000地址区域。这种做法好处是代码里不写死地址链接器可以检查冲突也方便在多个源文件里统一管理。__attribute__((aligned(n)))设置变量的对齐方式。比如 DMA 缓冲区通常要求 4 字节、8 字节甚至 32 字节对齐__attribute__((aligned(32))) uint8_t dma_buf[2048];万一缓冲区没对齐DMA 可能直接进 HardFault或者数据错位这类问题非常难查所以别小看这个属性。__attribute__((packed))主要用在结构体上取消编译器自动填充对齐字节typedef struct __attribute__((packed)) { uint8_t id; uint32_t len; uint8_t data[16]; } message_t;这在解析通信协议、存放二进制结构化数据时很常用。但要注意packed 结构体访问成员的代码效率会下降因为可能产生非对齐访问。对 ARM 来说非对齐访问有时候还要额外处理所以能不用就不用。__attribute__((zero_init))显式指定变量放在 ZI 段并且在启动时初始化为 0。一般用于放在 RAM 里但又不希望被 startup 文件反复清零的变量不对zero_init 恰恰是启动时清零。如果希望变量复位后不自动清零比如 bootloader 传给 app 的标志应该用__attribute__((no_init))或者__attribute__((section(.noinit)))。volatile虽然不算__attribute__但它和变量属性配合时也经常出现。比如一个变量既要在中断里修改又在主循环里读取你不加 volatile 就可能被编译器优化成直接从寄存器里读旧值。这个和地址控制是两码事但排错时经常一起碰到所以我把它们放在同一类里考虑。2.2 AC5 与 AC6 的差异与兼容写法实际工作中我见过很多老工程还在用 AC5新工程已经切到了 AC6。两种编译器对属性的支持有区别整理成表方便参考功能AC5armccAC6armclang__attribute__((at(addr)))支持直接放置绝对地址不支持需用section scatter__attribute__((section(name)))支持支持__attribute__((zero_init))支持支持__attribute__((no_init))支持建议用__attribute__((section(.noinit)))__attribute__((used))支持支持__attribute__((aligned(n)))支持支持__attribute__((packed))支持支持在 AC6 下如果一个团队还希望保留“把一个变量固定在绝对地址”的直观写法我自己习惯是写一个宏把两类编译器统一起来#if defined(__ARMCC_VERSION) (__ARMCC_VERSION 6010050) #define PLACE_AT(addr) __attribute__((section(.at_ #addr))) #else #define PLACE_AT(addr) __attribute__((at(addr))) #endif uint32_t shared_flag PLACE_AT(0x20000000);不过这里有个细节AC6 的section方式并不能保证段地址就是你想要的绝对地址你还需要在 scatter 文件里把这个段映射到固定地址。如果只是简单地在宏里写成section(.at_0x20000000)然后在 scatter 里手动加一个执行域也可以。代码里就能直观地区分哪个变量要放到哪个地址。2.3 变量属性实战把大数组放到外部 SDRAM假设我的 STM32H743 工程有一个 800x480 的 RGB LCD 显存需要800 * 480 * 2 768000字节片内 RAM 一般放不下外部 SDRAM 在0xC0000000起始。我这么做第一步在代码里定义__attribute__((section(.sdram_framebuffer), zero_init)) __attribute__((aligned(16))) uint16_t lcd_framebuffer[800 * 480];第二步在 scatter 文件里新增执行域LR_IROM1 0x08000000 0x00200000 { ER_IROM1 0x08000000 0x00200000 { *.o (RESET, First) *(InRoot$$Sections) .ANY (RO) } RW_IRAM1 0x20000000 0x00040000 { .ANY (RW ZI) } SDRAM_REGION 0xC0000000 0x00800000 { *.o (.sdram_framebuffer) } }第三步编译后查看 map 文件搜索lcd_framebuffer就能确认它被放到了0xC0000000附近的某个地址。这种做法比用at直接写在代码里更利于后期维护如果你换了一颗 SDRAM 起始地址不同的芯片只需要改 scatter 文件不用改 C 代码。注意zero_init属性会在启动代码里把这块区域清零。如果你的 SDRAM 初始化发生在外设初始化阶段也就是__main清 ZI 之后那么这块内存就不会被启动代码清零你需要自己在 SDRAM 初始化完成后手动 memset。实际项目里我踩过这个坑所以特意提醒一下。3. 函数属性控制编译器的“脾气”3.1section属性把函数放到指定段函数和变量一样也可以被打上section属性。最常见的场景就是把某个函数放到 RAM 里执行。比如做 Bootloader 时需要调用 Flash 擦写函数这段代码在被调用的时候Flash 控制器正在写 FlashCPU 如果还在同一块 Flash 里取指令可能会读到乱码。解决办法就是把这个函数编译到 RAM 段。写法如下__attribute__((section(.ram_code))) void flash_program(uint32_t addr, const uint8_t *data, uint32_t len) { // 实现 Flash 编程 }然后在 scatter 文件里增加 RAM 执行域RAM_EXEC 0x20002000 0x00010000 { *.o (.ram_code) }编译器会自动把这段代码拷贝到 RAM 里吗并不会。工程里的启动代码startup会负责把 RW 段拷贝到 RAM、把 ZI 段清零但你在 scatter 里新建一个执行域后需要在启动文件或初始化代码里主动拷贝这个段。一般情况下MDK 会在__main流程里调用__scatterload_copy自动把加载域里的数据复制到执行域。但如果你是在自定义的启动流程里绕过了__main就得自己写拷贝逻辑。另外放在 RAM 里的代码最好编译成位置无关码否则函数内部如果有跳转表、常量池加载地址和执行地址不一致容易出问题。在 AC6 里可以给函数加__attribute__((optnone))或用编译选项-fno-jump-tables在 AC5 里可以适当降低优化级别。3.2 其他高频使用的函数属性__attribute__((noreturn))告诉编译器这个函数不会返回可以避免编译器继续生成函数返回相关代码也可以消除一些“控制流到达结尾”的警告。常见于错误处理函数__attribute__((noreturn)) void panic_handler(void) { while (1) { // 执行错误处理 } }__attribute__((optimize(O0)))强制对某个函数禁用优化。有时候调试时某个函数的时序很微妙或者你想精确定位栈帧问题可以用这个属性单独降低优化。不过 AC6 对optimize属性的支持有限有些版本会警告最好实测确认。__attribute__((always_inline))强制函数内联。在中断处理中有时为了让代码在编译后保持一个整体便于计算开销可以用这属性。但滥用会增加代码尺寸。__attribute__((weak))弱符号。在库函数里把回调函数定义为 weak用户重新定义同名强符号后就会覆盖默认实现。比如__attribute__((weak)) void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { // 默认空实现 }__attribute__((alias(other_func)))给函数起别名。在某些硬件抽象层里可以用别名把新接口映射到旧接口实现。这个在 AC6 下也支持。3.3 函数属性实战把中断响应函数放到固定区域有段时间我在做 Bootloader 跳转到 App 的流程需要保证 App 的中断向量表起始地址固定在0x08008000。这个一般是靠链接脚本指定而不是给某个函数加属性。但如果你只是想确保某个关键中断函数不被编译器挪动可以在函数上加上section属性并在 scatter 里指定它的执行域。比如把看门狗中断喂狗函数单独放到一个段避免被其他代码干扰__attribute__((section(.isr_feeddog), used)) void feed_dog_isr(void) { IWDG-KR 0xAAAA; }这种方式的好处是在 map 文件里一眼就能看到这个函数的分布排查“是不是被优化掉了”时非常方便。4. 分散加载文件掌控全局内存地图4.1 看懂 scatter file 的结构前面反复提到 scatter 文件.sct它就是链接器的“命令行参数”告诉链接器整个系统的内存地图长什么样。一个典型工程打开Options for Target - Linker - Use Memory Layout from Target Dialog时MDK 会根据你用 Target 页面填的 ROM/RAM 地址自动生成 scatter 文件。一旦你把“Use Memory Layout from Target Dialog”去掉就会进入手动管理模式可以直接编辑.sct文件。scatter 文件核心概念分三层Load Region加载域描述程序烧录在哪个非易失性存储地址长度多少。Execution Region执行域描述程序运行时的地址空间。Input Section输入段描述哪些 obj 文件的哪些段放到哪个执行域。举个简单例子LR_IROM1 0x08000000 0x00200000 { ER_IROM1 0x08000000 0x00200000 { *.o (RESET, First) *(InRoot$$Sections) .ANY (RO) } RW_IRAM1 0x20000000 0x00040000 { .ANY (RW ZI) } }我拆开解释LR_IROM1加载域起始 0x08000000最大 2MB代表整个固件存到 Flash 的位置。ER_IROM1执行域代码在这个地址执行。这里 Flash 的加载地址和执行地址相同所以不需要额外拷贝。*(InRoot$$Sections)表示根运行时域启动代码相关的一些特殊段。.ANY通配符表示“其他任意输入段”。.ANY (RO)把所有只读段放到 Flash.ANY (RW ZI)把全局变量和零初始化变量放到 SRAM。4.2 用 scatter 文件精确控制段的落点想自定义一个段的地址就是在 scatter 文件里增加一行执行域然后用输入段描述符把对应的.o文件或某个.o文件里的某个段拉过来。例如我想把sdram_framebuffer放到 SDRAMSDRAM_REGION 0xC0000000 0x00800000 { main.o (.sdram_framebuffer) }这样写的含义是把main.o目标文件里的.sdram_framebuffer输入段放到0xC0000000起始的 SDRAM 区域。如果想匹配所有目标文件里的该段就写*(.sdram_framebuffer)如果想匹配任意名字以.sdram_开头的段*( .sdram_*)注意*的用法和通配符规则以及括号前是否有空格相关细节在 ARM 官方文档里写得很细。实际写的时候我建议多参照当前工程生成的 scatter 文件再小步修改避免大改导致启动不了。4.3 几个容易踩的 scatter 编写坑第一执行域一定要放在已有的内存范围内否则链接器会报错或把变量放到非法地址。比如 STM32F407 的 SDRAM 在0xD0000000和0xC0000000如果你在分散加载文件里写0xD0000000但芯片没有外部存储控制器映射到那里运行时访问直接 HardFault。第二不要把 ZI 段放在 Flash 执行域。ZI 段需要被启动代码清零运行时必然在 RAM 中。如果你把 ZI 段写到了 Flash 执行域轻则启动后变量不为 0重则程序直接跑飞。第三多个执行域的启动拷贝顺序会影响初始化时间。如果你的 RAM 执行域很多启动代码会逐一拷贝。如果某个函数或变量被放到了特定执行域但它的初始化代码依赖其他外设已经准备好比如 SDRAM 控制器没初始化你就得避开启动阶段的自动拷贝改用手动拷贝。比如刚才说的 SDRAM 显存zero_init清零发生在__main里而 SDRAM 控制器初始化通常也在__main前后的某个SystemInit或用户代码里先后顺序需要严格确认。5. 在 Keil MDK 里一步一步实操把变量固定到绝对地址5.1 第一步按编译器差异选择方案我们假设一个最简单的需求把变量magic_flag放到0x20000000地址用来让 Bootloader 和 App 传递状态。工程使用 Keil MDK 5.37 及以上编译器选的是 AC6。AC6 下不能直接写__attribute__((at(0x20000000)))所以使用section方式__attribute__((section(.shared_flag))) uint32_t magic_flag;接下来有两种做法做法 A手动修改 scatter 文件在 RW_IRAM1 执行域里增加*(.shared_flag)。但这样做并不能保证绝对地址为 0x20000000因为链接器只是从这个执行域里分配地址可能分配到 0x20000000 也可能是别的地址。做法 B给这个段单独设一个执行域并把起始地址写死LR_IROM1 0x08000000 0x00200000 { ER_IROM1 0x08000000 0x00200000 { *.o (RESET, First) *(InRoot$$Sections) .ANY (RO) } FIXED_FLAG 0x20000000 UNINIT 0x00000010 { *.o (.shared_flag) } }这里UNINIT是为了让链接器不为该区域生成清零代码因为这是一个在 Bootloader 和 App 之间传递的共享标志位复位后不应被清零。这个区域如果不在__main的 ZI 清零流程里它的初始值就保持上一次写入的值。但是这里有一个关键点如果FIXED_FLAG执行域包含了*.o (.shared_flag)而其他变量也被链接器分配到同一个执行域那么起始地址可能不是0x20000000而是偏移了。所以请在 scatter 文件里只把.shared_flag这一种输入段放进去并且执行域大小给得足够小只够容纳这一个变量。这样链接器通常会把变量放在起始地址。如果你希望绝对精确可以在FIXED_FLAG执行域里使用FIRSTFIXED_FLAG 0x20000000 UNINIT 0x00000010 { *.o (.shared_flag, First) }这会把.shared_flag放在区域最前面。不过即便如此我还是建议在代码里使用(uint32_t*)0x20000000访问或者直接定义指针变量不依赖链接器放置因为这样最直观、最不容易出错。5.2 第二步修改 scatter 文件并在 MDK 中指定在 MDK 中打开工程进入Options for Target - Linker取消勾选Use Memory Layout from Target Dialog然后点击旁边的 Edit 按钮MDK 会打开当前生成的.sct文件。你可以在里面直接修改。如果你已经有一个手写的 scatter 文件可以在这个页面手动选择文件路径。修改时务必看清当前芯片的 Flash 起始地址和 RAM 起始地址。如果使用 STM32H7内部 RAM 可能是0x20000000但还有 AXI SRAM 在0x24000000不同芯片差异较大不要照抄网上的地址。5.3 第三步编译并确认结果编译完后查看.map文件搜索变量名magic_flag 0x20000000 Data 4 main.o (.shared_flag)看到这个结果说明变量真的放在了0x20000000。再用调试器的 Watch 窗口添加变量地址读取内存确认初值是否满足预期。如果值不是你想要的考虑是不是UNINIT导致没被清理。另外可以打开调试器的 Memory 窗口直接查看0x20000000周边数据。这一步能排查“变量是放对了但是被别的初始化代码覆盖了”的情况。5.4 实操心得优先用 scatter section 而不是裸 at我个人的习惯是能不用at就不直接用at尽量写成“变量打自定义段 scatter 文件映射段地址”的组合。原因有三可读性好。at把地址散落在 C 代码里多人协作时容易漏掉。可移植性好。AC5 切 AC6 时至少不需要大改 C 文件。链接器能检查能不能放下、有没有和别段冲突。at如果放到了某个已经被占用的地址MDK 的 linker 报的错往往不够直观排查起来更费时间。但也不能走向另一个极端。有些变量地址是硬件决定的比如外设寄存器那你就不要用__attribute__((at))来定义应该使用 CMSIS 头文件里#define寄存器地址的方式或者用指针访问。它的本质是内存映射外设不是普通变量放置问题。6. 常见问题与排查技巧实录6.1 变量没有放到我指定的地址这个问题出现的频率最高。常见原因有几个用了 AC6但代码里写了__attribute__((at(addr)))编译时被忽略或报警。变量没有被用到被编译器优化掉了。可以给变量加上volatile和__attribute__((used))防止被优化。scatter 文件里没有匹配到那个输入段。比如代码里写的是.my_varscatter 里写的是*(.my_var*)但实际 C 文件里的段名可能是.bss.my_var或.data.my_var之类的变体。尤其 AC6 在默认情况下会把全局变量放到.bss或.data这种带前缀的段里。如果你想匹配某个变量所在的段建议在 C 里显式使用__attribute__((section(my_var)))这种不含点号前缀的自定义段名。scatter 文件里指定了执行域但链接器把段分配到了执行域内偏移量不为 0 的位置。这种情况用First或单独缩小执行域来规避。6.2 编译时出现 “Execution region ... has no space” 或 “Overlap” 错误这说明你定义的执行域放不下对应的段或者两个执行域地址范围有重叠。排查思路是打开 map 文件查看这个段实际大小然后看 scatter 文件里对应的执行域大小是否被写小了。特别容易犯的错误是把执行域大小写成 0然后还想往里面放东西。链接起不到任何保护作用的时候运行时错误会非常隐蔽。另外需要注意MDK 的编译器有时会把启动代码里的(InRoot$$Sections)和*.o (RESET, First)一起放到某个执行域如果你手动修改 scatter 文件不小心删掉这些行启动文件可能无法被链接程序连Reset_Handler都找不到。6.3 函数放到 RAM 之后一调用就 HardFault首先确认函数对应的段是否真的被加载和拷贝到了 RAM。如果没有__main参与的 scatterload 机制你需要手动在调用前把该段从加载域拷贝到执行域。代码可以通过链接器生成的Load$$region_name$$Base、Image$$region_name$$Base等符号获取地址比如extern unsigned long Image$$RAM_EXEC$$Base; extern unsigned long Image$$RAM_EXEC$$Length; extern unsigned long Load$$RAM_EXEC$$Base; void copy_ram_exec(void) { memcpy(Image$$RAM_EXEC$$Base, Load$$RAM_EXEC$$Base, (size_t)Image$$RAM_EXEC$$Length); }还有一种可能是函数里面访问了常量而常量还被放在 FlashFlash 又处于编程模式导致取数据失败。属于函数被放到 RAM 但常量没过去的情况。解决思路是把函数内用到的常量也放到同一 RAM 执行域或者把函数改成完全自包含的代码。6.4 用fromelf和 map 文件交叉验证排查链接阶段的奇奇怪怪问题我经常会用到fromelf --text -z或者查看生成的.axf文件。在 MDK 的调试器命令行里也能用fromelf。比如我想看某个段被安排在哪个地址可以执行fromelf --text -a project.axf输出里会列出每个段的地址范围比 map 文件更原始也更能看到编译器优化之后的新段名。实际项目里AC6 编译后变量可能被改名为??main_0之类的东西用 map 文件搜索时可能找不到原始变量名这时候用fromelf去看段分布更有效。6.5 注意 MDK 的调试器加载问题有时候你明明把变量放到了指定地址但下载程序后调试器里看不到或者看到的数值一直不变。这一般是下载算法Flash loader和 scatter 文件不匹配导致的。比如你把一个段放到了外部 SDRAM但调试器的初始化脚本没有初始化 SDRAM 控制器调试器下载后根本没法访问那个地址。解决办法是在 Debug 选项卡里配置初始化脚本或者调整 scatter 文件避免把需要 SDRAM 初始化的执行域放在启动阶段需要访问的路径上。7. 一段写在最后的实战建议写了这么多其实我想表达的核心就一句在 Keil MDK 里控制变量和函数属性本质上是在跟链接器打交道而不是纯粹写 C 语言。C 语言只负责提供__attribute__这个入口真正决定变量落在哪个地址、函数能不能在 RAM 里跑是分散加载文件、启动代码和链接符号这三者共同作用的结果。我最早尝试做 IAP 升级时因为不懂 scatter 文件用__attribute__((at))把所有关键结构体钉死在固定地址结果换一个编译器版本就崩了后来才彻底转向“自定义段 scatter 映射”的写法。如果你今天刚开始接触这个概念我建议先从一个小目标练起把一个大数组放到外部 SDRAM并在 map 文件里确认它的地址。这一步通了再把一个函数放进 RAM 里执行同时观察启动阶段的拷贝行为。这两个实验做完你对 MDK 的内存布局基本就有手感了。以后再遇到变量被优化、函数跑飞、Flash 擦写死机之类的疑难杂症排查路径会清晰很多。