📚 课程目录第4章内存分区与布局

内存分区与布局：Flash分区策略、Bootloader与应用程序的地址映射、向量表重定向

各位同学，咱们今天聊点硬核的——内存分区。说实话，很多刚入行的工程师觉得这玩意儿就是改改链接脚本，没什么技术含量。但我告诉你，恰恰是这块没搞明白，导致我见过不下十次刷写变砖的案例。嗯，咱们今天就把这块彻底讲透。

为什么Flash分区这么重要？

你想想看，ECU里就一块Flash，既要放Bootloader，又要放应用程序，还得留个备份区防止刷写失败。这三者怎么共存？说白了，就是靠分区策略。

我个人的习惯是，在设计任何Bootloader之前，先画一张内存地图。这张图决定了后续所有的地址计算、跳转逻辑、刷写流程。地图画错了，后面全是坑。

核心原则：Flash分区必须满足三个条件——Bootloader不会被应用程序覆盖、应用程序有足够的运行空间、刷写失败时有回滚能力。

典型Flash分区策略

咱们以常见的256KB Flash为例，看看实际项目中怎么分。我参与过的项目里，最常用的就是下面这种四分区方案：

分区名称	起始地址	大小	内容
Bootloader区	0x08000000	32KB	Bootloader固件、启动配置
应用程序A区	0x08008000	96KB	主应用程序（当前运行）
应用程序B区	0x08020000	96KB	备份应用程序（待刷写）
参数存储区	0x08038000	32KB	校准参数、刷写标志、诊断信息

为什么Bootloader只给32KB？因为Bootloader的功能相对固定——初始化硬件、检查刷写请求、跳转到应用程序。代码量不会太大。我曾经见过有人给Bootloader分了128KB，结果应用程序空间不够用，最后不得不重新改分区，那叫一个折腾。

我的经验：Bootloader的大小建议控制在总Flash的10%~15%。如果超过20%，说明你可能把不该放的东西放进去了。Bootloader越精简，越不容易出问题。

Bootloader与应用程序的地址映射

分区定好了，接下来就是地址映射。这里有个关键点：Bootloader和应用程序是两套独立的固件，它们各自认为自己从0x08000000开始运行。但实际上，应用程序被挪到了0x08008000。

怎么让应用程序知道自己不在0x08000000？靠链接脚本。以STM32的GCC工具链为例，链接脚本里要这样改：

/* 应用程序链接脚本片段 */
MEMORY
{
    FLASH (rx)  : ORIGIN = 0x08008000, LENGTH = 96K
    RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 64K
}

/* 向量表基地址 */
__VECTOR_TABLE = 0x08008000;

看到没？ORIGIN改成了0x08008000。这意味着编译器生成的所有代码地址，都会以这个为基准。但问题来了——芯片上电后，硬件默认从0x08000000取向量表，也就是Bootloader的向量表。Bootloader怎么跳转到应用程序？

流程是这样的：

Bootloader完成初始化，检查是否需要刷写
如果不需要刷写，读取应用程序区的刷写有效性标志
有效则关闭全局中断，设置新的栈指针
跳转到应用程序的复位向量地址

代码实现大概是这样：

/* Bootloader跳转到应用程序 */
typedef void (*pFunction)(void);

void JumpToApplication(uint32_t appAddress)
{
    uint32_t stackPtr = *(volatile uint32_t*)appAddress;
    uint32_t resetAddr = *(volatile uint32_t*)(appAddress + 4);
    pFunction resetHandler = (pFunction)resetAddr;

    /* 关闭全局中断 */
    __disable_irq();

    /* 设置主栈指针 */
    __set_MSP(stackPtr);

    /* 跳转到应用程序复位向量 */
    resetHandler();
}

注意：跳转前一定要关闭所有外设中断，否则应用程序初始化时可能触发意外中断，导致死机。我曾经在这个坑里摔过一次，排查了两天才发现是定时器中断没关干净。

向量表重定向

应用程序跳过去了，但还有一个大问题——中断。芯片发生中断时，硬件会去0x08000000找向量表，也就是Bootloader的向量表。但应用程序的中断服务函数在0x08008000，这怎么办？

答案就是向量表重定向。现代ARM Cortex-M内核提供了一个寄存器——VTOR（Vector Table Offset Register），用来告诉硬件向量表搬到了哪里。

应用程序启动后，第一件事就是设置VTOR：

/* 应用程序启动代码中设置VTOR */
#define SCB_VTOR  ((volatile uint32_t*)0xE000ED08)

void SystemInit(void)
{
    /* 设置向量表偏移为应用程序起始地址 */
    *SCB_VTOR = 0x08008000;

    /* 其他初始化... */
}

设置完VTOR后，所有中断都会从0x08008000开始查找向量表。这样应用程序的中断就能正常工作了。

但这里有个细节——有些芯片（比如某些NXP的MPC系列）不支持VTOR，或者VTOR的地址对齐有要求。我建议你在选型阶段就确认清楚，否则后面改起来很痛苦。

SVG：Flash分区与地址映射关系图

下面这张图展示了咱们刚才讲的所有内容，从Flash分区到地址映射，再到跳转流程，一目了然：

避坑指南：我踩过的那些坑

讲完了理论，咱们聊聊实战中容易出问题的地方。我这些年做Bootloader开发，踩过的坑不少，挑几个典型的说说：

向量表对齐问题：有些芯片要求VTOR的值必须是512字节对齐的。如果你把应用程序放在0x08008000，没问题。但如果你放在0x08008100，那就等着死机吧。我建议你查芯片手册，确认对齐要求。
中断优先级分组：Bootloader和应用程序可能设置了不同的中断优先级分组。跳转前最好把优先级分组复位，否则应用程序里中断可能不按预期响应。
外设状态残留：Bootloader用过的外设，比如UART、DMA，跳转前一定要复位。否则应用程序初始化时可能读到奇怪的状态。
看门狗：如果Bootloader开了独立看门狗，跳转前别忘了喂狗或者关闭。我见过一个项目，跳转后看门狗超时复位，系统一直在重启循环里打转。

曾经有一次：我在一个项目里忘了关DMA，跳转到应用程序后DMA还在搬运数据，直接把应用程序的代码区给覆盖了。结果程序跑飞，查了三天才找到原因。从那以后，我写了一个DeinitAllPeripherals()函数，跳转前强制调用。

总结一下

内存分区与布局，说白了就是三件事：

把Flash切成合理的区域，Bootloader、应用程序、备份区各司其职
通过链接脚本和跳转代码，让Bootloader和应用程序在各自的地址空间里正常工作
用VTOR解决中断向量表的重定向问题

这三件事做好了，你的Bootloader就成功了一半。剩下的就是刷写协议和容错机制了。嗯，今天就到这儿，大家回去可以画一张自己项目的Flash分区图，看看有没有优化的空间。