ARM Compiler 5.06内存布局实战：在Keil MDK中把每字节RAM都用得明明白白

你有没有遇到过这样的情况？
烧录进芯片的固件，调试时一切正常，一到量产环境就HardFault；
RTOS任务跑着跑着突然崩掉，查来查去发现栈指针早就不知道飞到哪片内存里了；
OTA升级后音频失真、CAN通信丢帧，而代码逻辑明明没动——最后揪出来是Flash擦除时误刷了正在被DMA读写的缓冲区。

这些问题， 90%以上不是代码bug，而是内存布局失控的后果 。
不是编译器不靠谱，也不是MCU太娇气，而是我们把最底层的物理地址关系，交给了默认链接脚本去“猜”。

ARM Compiler 5.06 + Keil MDK这套组合，至今仍是工业级嵌入式项目的主力工具链。它不炫技、不折腾，但要求你真正理解： 代码在哪存、在哪跑、变量在哪初始化、栈从哪开始长、谁有权访问哪块RAM 。而这一切的控制开关，就藏在一个纯文本文件里： .sct 。

---

先说清楚：为什么非得手写.sct？默认不行吗？

Keil MDK新建工程时会自动生成一个基础内存布局，比如：

ROM_REGION 0x08000000 0x00020000
RAM_REGION 0x20000000 0x00010000

这看起来很省事——但它本质是“通用模板”，对具体芯片、具体架构、具体安全需求完全无感。
举几个真实踩过的坑：

• 默认把整个 .data （RW段）和 .bss （ZI段）一股脑塞进主RAM，可你的MCU明明有DTCM（零等待高速RAM）、ITCM（指令缓存RAM）、SRAM1、SRAM2、甚至备份RAM……全混在一起，性能浪费不说，还可能因总线竞争导致时序抖动；
• 向量表默认放在Flash起始地址，但如果你要用TrustZone或Secure Monitor，就得把它挪到Secure RAM里，再通过VTOR重定向——默认配置连VTOR寄存器都不会碰；
• malloc 用的heap和主线程用的stack共享同一片RAM区域，一旦某个模块疯狂申请内存，栈就被悄无声息地顶穿，HardFault来得毫无征兆；
• OTA固件升级时，烧录工具按默认镜像擦除整块Flash扇区，结果把正在运行的音频缓冲区也给擦了——DMA还在读，地址却已失效。

所以， 不是.sct高级，而是它让你把“假设”变成“确定” ：

我明确告诉链接器：“向量表必须从0x08000000开始、32字节对齐”；
“所有全局变量初值（RW）必须从0x20000000加载，并复制到0x20010000执行”；
“未初始化变量（ZI）清零范围严格限定在0x20010000~0x20018000”；
“堆空间只准在0x20018000之后分配，大小不超过8KB”；
“音频DMA缓冲区必须落在0x80000000起始的SDRAM，且禁止任何其他段映射进来”。

这种确定性，是工业级系统启动时间<100ms、医疗设备通过IEC 62304认证、车载ECU满足ASIL-B功能安全要求的前提。

---

.sct不是配置文件，是内存宪法

很多人把 .sct 当成类似 config.h 的参数文件，其实它更接近一份 内存层面的宪法 ：定义主权（哪些区域归谁管）、划定边界（地址不能重叠）、授予权限（UNINIT表示这块RAM别清零）、设立特区（OVERLAY用于动态加载模块）。

来看一个真实项目中精简但完整的例子（适配STM32H743 + 双Bank Flash + DTCM RAM）：

; target_layout.sct —— 内存宪法正文
LR_ROM1 0x08000000 0x00080000  {    ; Load Region: Flash Bank1 (512KB)
  ER_ROM1 0x08000000 0x00080000  {  ; Exec Region: Code & RO Data in Flash
    *(+RO)                           ; 所有只读段（代码、常量字符串、const数组）
    *(InRoot$$Sections)              ; 关键启动段：__Vectors, Reset_Handler等
  }
  RW_RAM1 0x20000000 0x00020000  {   ; Exec Region: RW/ZI in DTCM RAM (128KB)
    *(+RW +ZI)                       ; 已初始化/未初始化数据全部落在此处
  }
}

LR_ROM2 0x08100000 0x00080000  {    ; Load Region: Flash Bank2 (512KB) - OTA专用
  ER_ROM2 0x08100000 0x00080000  {
    *(.ota_image)                    ; OTA固件专属段，链接器只认这个符号
  }
}

; 显式声明堆与栈 —— 这是防止“静默溢出”的关键
STACK_SIZE  0x00000400
HEAP_SIZE   0x00002000
ARM_LIB_STACK +0 SIZE = STACK_SIZE     ; 主栈（MSP），从高地址向下长
ARM_LIB_HEAP  +0 SIZE = HEAP_SIZE      ; 堆（heap），从低地址向上长

⚠️ 注意这几个决定系统生死的细节：

• *(InRoot$$Sections) 是ARM链接器内置的关键段集合，包含中断向量表、复位处理函数、系统初始化入口等。 漏掉它，芯片上电后根本不会跳到你的Reset_Handler，直接死在复位向量地址 ；
• ARM_LIB_STACK 和 ARM_LIB_HEAP 不是可选项，而是标准C库（ARM C Library）约定的符号名。如果你不显式定义，链接器就用默认值（通常是0x20000000），而这个地址很可能已被其他段占用，或者压根不在有效RAM范围内；
• LR_ROM1 和 ER_ROM1 起始地址相同，说明这是XIP（Execute-In-Place）模式：代码直接从Flash运行，不搬进RAM——这对Flash带宽有限的MCU至关重要；
• RW_RAM1 单独划出一块DTCM RAM存放RW/ZI段，意味着所有全局变量、静态变量、堆栈操作都在零等待周期RAM中完成，避免了访问普通SRAM带来的总线仲裁延迟。

再强调一遍： 这些不是“优化技巧”，而是让系统能稳定启动、可靠运行的底线配置 。

---

armlink不是黑盒，它是你内存策略的执行官

很多开发者只关心 armcc 编译快不快、 µVision 调试方不方便，却很少打开 .map 文件看看链接器到底干了什么。而恰恰是 armlink ，把你的.sct宪法翻译成机器可执行的绝对地址。

当你在Keil中设置：
- ✅ Linker → Use Memory Layout from Scatter File → 勾选并指定 target_layout.sct
- ✅ Linker → Misc Controls → 输入 --scatter "target_layout.sct" --entry Reset_Handler --no_autoat

你就已经把控制权交给了 armlink 。它会做三件关键的事：

1. 校验宪法合法性 ：检查所有Region地址是否越界、是否有重叠、是否满足对齐要求（比如向量表必须32字节对齐）。一旦发现 Error: L6242E: Alignment of section __Vectors is not compatible with its memory region ，别急着改代码——先去看.sct里 ER_ROM1 的起始地址是不是 0x08000000 （32字节对齐），而不是 0x08000001 。

2. 分配段落归属 ：把每个 .o 文件里的 +RO 段放进 ER_ROM1 ， +RW/+ZI 段放进 RW_RAM1 。如果某个模块用了 __attribute__((section(".audio.buffer"))) 定义缓冲区，但.sct里没写 *(.audio.buffer) ，链接器就会报错： Error: L6218E: Undefined symbol ——这不是报错，是提醒你：“你声明了一块特殊内存，但宪法里没给它划地盘”。

3. 注入启动逻辑 ：自动在 __main 函数开头插入对 __scatterload 的调用。这个函数由ARM库提供，负责：
   - 把Flash里的RO段原样搬到Execution Address（如果是XIP则跳过）；
   - 把Flash里的RW初值复制到RAM中对应位置；
   - 把ZI段所在的RAM区域清零；
   - 设置好 __initial_sp （即MSP初始值）；
   - 最后才跳转到你的 main() 。

也就是说： 你写的C代码，从来不是第一条执行的指令；真正掌控开机第一秒的，是armlink根据.sct生成的这段搬运逻辑 。

---

启动代码不是模板，是你和硬件握手的誓词

startup_stm32h743xx.s 这类文件，很多人双击打开看一眼就关掉，觉得“Keil自动生成的，应该没问题”。但真相是： 它只是个空壳，真正的灵魂在.sct里 。

看这段关键汇编：

Stack_Size      EQU     0x00000400
Stack_Mem       SPACE   Stack_Size
__initial_sp    EQU     Stack_Mem + Stack_Size

这里定义了 __initial_sp ——也就是复位后CPU立即加载到MSP寄存器的那个值。
但注意：这个 Stack_Size 必须和.sct中 ARM_LIB_STACK +0 SIZE = STACK_SIZE 的值 完全一致 ，而且 __initial_sp 计算出的地址，必须落在 sct 定义的 ARM_LIB_STACK 区域内。

否则会发生什么？
复位后，CPU从0x08000000取向量表，第二项是MSP初始值——如果这个值是0x20000000，而你的.sct把 ARM_LIB_STACK 定义在0x20010000开始，那MSP就指向了一片未初始化、甚至可能被其他段占用的RAM。只要一执行push指令，立刻触发HardFault。

更隐蔽的问题是双栈支持。如果你用FreeRTOS，它默认用PSP（Process Stack Pointer）跑任务，而MSP只用于中断上下文。这时候，你不仅要定义 ARM_LIB_STACK （给MSP），还得加一行：

ARM_LIB_STACK_PSP +0 SIZE = 0x00001000  ; 给每个RTOS任务预留4KB栈空间

否则FreeRTOS创建第一个任务时， pxPortInitialiseStack() 会尝试往一个不存在的PSP区域写数据，崩溃就在毫秒之间。

所以， 启动代码不是拿来抄的，是用来对照验证的 ：
- .sct 里写的地址，和 .s 里算出来的 __initial_sp ，必须对得上；
- .sct 里声明的 ARM_LIB_STACK 大小，必须大于等于 .s 里 Stack_Size ；
- 如果用了PSP， .sct 里就必须有对应声明，且RTOS配置要匹配。

---

真实战场：车载音频DSP系统的内存拆解

我们以NXP i.MX RT1064为例（Cortex-M7 + 512KB OCRAM + 外置SDRAM），看看.sct如何成为系统稳定性的基石：

; i.MX_RT1064_audio.sct
LR_FLASH 0x60000000 0x00800000  {    ; 主Flash（8MB）
  ER_BOOTLOADER 0x60000000 0x00020000  {  ; Bootloader（128KB）
    boot_loader.o (+RO)
  }
  ER_SECUREMON 0x60020000 0x00010000  {   ; Secure Monitor（64KB）
    secure_mon.o (+RO +RW)
  }
  ER_AUDIO_APP 0x60030000 0x00100000  {    ; 音频App（1MB）
    *(+RO)
    *(InRoot$$Sections)
  }
}

LR_OCRAM 0x20200000 0x00080000  {     ; 高速OCRAM（512KB）
  RW_OCRAM 0x20200000 0x00080000  {
    *(+RW +ZI)
    *(.audio.fft_workspace)          ; FFT算法工作区，必须在零等待RAM
  }
}

LR_SDRAM 0x80000000 0x02000000  {     ; 外置SDRAM（32MB）
  SDRAM_BUFFERS 0x80000000 0x00400000  {  ; 音频流缓冲区（4MB）
    *(.audio.input_buffer)
    *(.audio.output_buffer)
  }
}

; 强制隔离：确保音频缓冲区永不被擦除
ARM_LIB_STACK +0 SIZE = 0x00001000
ARM_LIB_HEAP  +0 SIZE = 0x00004000

这个布局解决了三个硬性约束：

• ✅ 启动确定性 ：Bootloader固定在0x60000000，向量表位置锁定，上电即执行；
• ✅ 实时性保障 ：FFT运算所需的大块临时内存（ .audio.fft_workspace ）强制落在OCRAM，避免SDRAM访问延迟影响音频处理周期；
• ✅ OTA安全 ：音频App升级时，烧录工具只擦除 ER_AUDIO_APP 区域（0x60030000~0x60130000），而 SDRAM_BUFFERS 完全不受影响，DMA持续工作不中断。

没有这个.sct，你写的每一个 memcpy 、每一次 malloc 、每一行 HAL_UART_Transmit ，都运行在不可控的内存沙地上。

---

调试不是玄学，是用.map和Memory Browser说话

写完.sct，别急着烧录。打开生成的 .map 文件，找到这几处关键信息：

Load Region LR_FLASH (Base: 0x60000000, Size: 0x00800000, Max: 0x00800000)

Execution Region ER_AUDIO_APP (Base: 0x60030000, Size: 0x00100000, Max: 0x00100000)
    ER_AUDIO_APP +0x00000000    Data        0x00000000  startup_imxrt1064.o
    ER_AUDIO_APP +0x000000c0    Data        0x00000000  system_imxrt1064.o
    ...
    ER_AUDIO_APP +0x00000100    Code        0x00000000  main.o

Execution Region RW_OCRAM (Base: 0x20200000, Size: 0x00080000, Max: 0x00080000)
    RW_OCRAM +0x00000000    Zero          0x00001000  main.o
    RW_OCRAM +0x00001000    Data          0x00000010  audio_codec.o
    ...

Stack Heap Summary:
  Heap base = 0x20201000, Heap limit = 0x20205000
  Stack base = 0x20205000, Stack limit = 0x20206000

再打开µVision的 View → Memory Windows → Memory Browser ，手动跳到 0x20200000 ，观察RW/ZI段是否真的按预期填充；跳到 0x60000000 ，确认向量表头4个字（SP初始值、Reset_Handler地址、NMI_Handler地址、HardFault_Handler地址）是否正确。

这才是真正的“所见即所得”调试——不是靠猜，而是靠地址、靠字节、靠链接器给出的铁证。

---

最后一句实在话

掌握ARM Compiler 5.06的内存布局，不是为了显得技术多深，而是为了让你写的每一行代码，都清楚自己站在哪块物理RAM上，知道自己会被谁读、被谁写、会不会被擦除、能不能被中断打断。

它不教你新算法，但能让你的FFT不出错；
它不帮你写驱动，但能让UART收发不丢帧；
它不替代RTOS，但能让FreeRTOS的任务栈永远不越界。

下次当你面对一个莫名其妙的HardFault，别急着翻手册查寄存器，先打开 .map ，看看 __initial_sp 指向哪，再打开 .sct ，确认 ARM_LIB_STACK 是不是真在那里。

因为在这个世界里， 最可靠的抽象，永远建立在最扎实的地址之上 。

如果你正在为某个具体芯片（比如STM32U5、RA6M5、LPC55S69）写.sct却卡在向量表对齐或堆栈冲突上，欢迎把你的片段贴出来——我们可以一起逐行推演，直到那个地址对上为止。