📚 课程目录第3章链接脚本与内存布局

3、链接脚本与内存布局：.ld 文件解析、Flash/RAM 分区与堆栈优化

链接脚本，说白了就是告诉编译器：「你的代码该放哪儿，数据该放哪儿」。很多新手觉得这玩意儿是编译器的黑魔法，其实没那么玄乎。我刚开始做 MCU 开发时，也跳过这步，结果程序跑飞了都不知道为什么。后来被坑了几次，才老老实实把 .ld 文件啃透。

今天我们就把它掰开揉碎，看看 Flash 和 RAM 到底怎么分，堆栈怎么设才不浪费。

3.1 链接脚本(.ld)文件解析

.ld 文件是链接器的「地图」。它告诉链接器：你的目标芯片有多少 Flash、多少 RAM，代码段放哪里，数据段放哪里。没有它，编译器就是一盘散沙。

一个典型的 .ld 文件结构如下：

/* 入口点 */
ENTRY(Reset_Handler)

/* 内存区域定义 */
MEMORY
{
    FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
    RAM   (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
}

/* 段定义 */
SECTIONS
{
    .text :
    {
        . = ALIGN(4);
        *(.isr_vector)    /* 中断向量表 */
        *(.text)          /* 代码 */
        *(.rodata)        /* 只读数据 */
        . = ALIGN(4);
        _etext = .;
    } > FLASH

    .data :
    {
        . = ALIGN(4);
        _sdata = .;
        *(.data)          /* 初始化数据 */
        . = ALIGN(4);
        _edata = .;
    } > RAM AT> FLASH

    .bss :
    {
        . = ALIGN(4);
        _sbss = .;
        *(.bss)           /* 未初始化数据 */
        *(COMMON)
        . = ALIGN(4);
        _ebss = .;
    } > RAM
}

这里有几个关键点：

MEMORY：定义物理存储区域。ORIGIN 是起始地址，LENGTH 是大小。
SECTIONS：定义各段如何映射到内存区域。
.text：代码段，放在 Flash 里。包括中断向量表和只读数据。
.data：初始化数据段。运行时在 RAM，但初始值存在 Flash 里（AT> FLASH）。
.bss：未初始化数据段，启动时清零。

我的习惯：每次新建工程，我都会先检查 .ld 文件里的 ORIGIN 和 LENGTH 是否跟芯片手册一致。有一次我手滑把 Flash 大小写成了 256K，结果编译通过，下载后程序跑一半就挂了。排查了半天才发现是链接脚本写错了。

3.2 Flash 与 RAM 分区策略

Flash 和 RAM 怎么分，直接决定了你的 Bootloader 能不能正常工作。我见过不少项目，Boot 和 App 的地址重叠，一升级就变砖。

一个典型的 Bootloader 分区方案如下：

区域	起始地址	大小	内容
Bootloader	0x08000000	32KB	启动代码、升级逻辑
App 分区	0x08008000	448KB	用户应用程序
参数存储区	0x0807E000	4KB	升级标志、配置参数
备份区	0x0807F000	4KB	固件备份（可选）

为什么要这么分？

Bootloader 放最前面：MCU 上电默认从 0x08000000 启动，Boot 必须在这里。
App 分区紧随其后：Boot 跳转到 App 时，需要知道 App 的起始地址。
参数区单独划出：升级标志、版本号这些数据，不能跟代码混在一起，否则擦除时会把代码也干掉。

我曾经踩过的坑：有一次我把参数区放在了 App 分区内部，结果升级时擦除了整个 App 分区，参数也跟着没了。从那以后，我坚持把参数区放在 Flash 末尾，单独一个扇区。

RAM 的分区同样重要。Boot 和 App 通常共用 RAM，但要注意不要冲突：

Boot 阶段：使用 RAM 前 4KB 做堆栈和临时变量。
跳转到 App 前：清理 Boot 使用的 RAM，避免残留数据干扰 App。
App 阶段：完全接管 RAM，Boot 不再占用。

3.3 堆栈设置与优化

堆栈设置，说白了就是给程序分配「临时工作台」。堆太小，malloc 会失败；栈太小，函数调用深一点就溢出。我见过最离谱的一次，栈溢出导致全局变量被莫名其妙地修改，查了三天才发现是栈设小了。

堆栈在 .ld 文件中通常这样定义：

/* 栈大小 */
_estack = ORIGIN(RAM) + LENGTH(RAM);  /* 栈顶在 RAM 末尾 */
_Min_Stack_Size = 0x400;              /* 1KB 栈 */
_Min_Heap_Size = 0x200;               /* 512B 堆 */

然后在启动文件里初始化栈指针：

Reset_Handler:
    ldr   sp, =_estack      /* 设置栈指针 */
    bl    main

堆栈大小怎么定？我一般遵循这几个原则：

栈大小：根据函数调用深度和局部变量大小估算。RTOS 任务栈每个至少 256 字节，裸机主栈至少 1KB。
堆大小：如果不用 malloc，直接设为 0。用了的话，根据动态分配的最大块估算。
栈顶位置：通常放在 RAM 末尾，这样栈向下增长时不会跟其他数据段冲突。

    优化技巧：
    把频繁调用的局部变量改为全局静态变量，减少栈使用。
中断服务函数里尽量少用局部数组，改用全局缓冲区。
用 --stack-analysis 编译选项让工具帮你算栈使用量。

嗯，这里要注意：栈溢出是 MCU 开发中最隐蔽的 bug 之一。它不会直接报错，而是悄悄修改栈附近的数据，导致程序行为诡异。我习惯在调试阶段把栈区填充为 0xDEADBEEF，程序跑一段时间后检查这个值有没有被覆盖，就能判断栈是否够用。

3.4 内存布局实战：一个 Bootloader 的 .ld 示例

下面是我实际项目中使用的一个 Bootloader 链接脚本片段，供你参考：

MEMORY
{
    BOOT_FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 32K
    APP_FLASH  (rx)  : ORIGIN = 0x08008000, LENGTH = 448K
    PARAM_FLASH (r)  : ORIGIN = 0x0807E000, LENGTH = 4K
    RAM        (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
    .boot_text :
    {
        *(.isr_vector)
        *(.text)
        *(.rodata)
    } > BOOT_FLASH

    .boot_data :
    {
        *(.data)
    } > RAM AT> BOOT_FLASH

    .boot_bss :
    {
        *(.bss)
    } > RAM
}

这个脚本把 Bootloader 的代码限制在 32KB 内，App 从 0x08008000 开始。参数区单独放在 0x0807E000，不会被意外擦除。

我的建议：写 .ld 文件时，一定要加上 . = ALIGN(4); 保证四字节对齐。ARM Cortex-M 要求中断向量表必须四字节对齐，否则会硬件错误。

3.5 内存布局知识体系

为了让你更直观地理解整个内存布局，我画了一张图：

这张图展示了 Flash 和 RAM 的典型分区，以及 .ld 文件如何控制各段的映射关系。你可以看到，.data 段虽然运行在 RAM，但初始值存储在 Flash 中，启动时由 Bootloader 拷贝过去。

特别注意：如果你的 Bootloader 和 App 使用不同的链接脚本，一定要确保两者的内存区域不重叠。我见过有人把 Boot 的 RAM 区域设得太大，结果 App 启动时栈指针指向了 Boot 的残留数据，直接 HardFault。

好了，关于链接脚本和内存布局，今天就聊到这里。记住一句话：链接脚本是 MCU 开发的基石，花时间把它搞懂，后面能省无数 debug 的时间。