📚 课程目录第2章 Bootloader架构设计

2. Bootloader架构设计：分区策略、启动流程与跳转逻辑

Bootloader 架构设计，说白了就是回答三个问题：代码放哪？怎么启动？怎么跳转？这三个问题搞定了，整个刷写框架的骨架就立起来了。我这些年接手过的项目，但凡后期出问题的，十有八九都是这层没想清楚。

2.1 分区策略：App 和 Bootloader 怎么共存？

Flash 空间就那么大，Bootloader 和 App 必须分区域存放。分区策略直接决定了后续的升级灵活性。

核心原则：Bootloader 区域必须独立且受保护，App 区域可以被擦除和重写。

我习惯把 Flash 分成三个主要区域：

区域	起始地址（示例）	大小	内容
Bootloader 区	0x08000000	32 KB	启动代码、刷写驱动、UDS 服务
App 区	0x08008000	448 KB	应用程序固件
配置/备份区	0x0807C000	16 KB	校准参数、升级标志、备份信息

这里有个坑——分区大小必须对齐 Flash 的扇区边界。不同芯片的扇区大小不一样，有的 2 KB，有的 16 KB，有的甚至 128 KB。我曾经在一个项目里没注意这个，Bootloader 和 App 的分区边界刚好落在扇区中间，结果擦除操作把 Bootloader 的尾巴给抹了……嗯，从那以后我再也不敢忽略扇区对齐了。

警告：分区地址必须与 Flash 扇区边界对齐。否则擦除操作会误伤相邻区域的数据。

2.2 启动流程：从复位到 App 的完整路径

芯片上电后，CPU 会从复位向量表取第一条指令。这个向量表默认在 0x08000000，也就是 Bootloader 的起始位置。整个启动流程是这样的：

硬件初始化：关闭看门狗、配置时钟、初始化堆栈
检查升级标志：读取配置区的标志位，判断是否需要进入刷写模式
跳转决策：如果需要升级，留在 Bootloader；否则跳转到 App
执行 App：修改向量表偏移，跳转到 App 的复位向量

你想想看，这个流程里最关键的就是第二步——升级标志的判断。标志位怎么设？存在哪？

我个人习惯的做法是：在配置区预留一个 4 字节的变量，叫 boot_flag。正常运行时这个值是 0xFFFFFFFF（擦除后的默认值）。当需要进入刷写模式时，App 在复位前把这个值改成 0xA5A5A5A5。Bootloader 启动时读到这个值，就知道该干活了。

小技巧：升级标志建议使用两个互补的校验值（比如 0xA5A5A5A5 和 0x5A5A5A5A），防止单比特翻转导致误判。

2.3 跳转逻辑：从 Bootloader 到 App 的精确转移

跳转逻辑是 Bootloader 里最容易出 Bug 的地方。说白了就是一件事：把 CPU 的控制权从 Bootloader 代码交给 App 代码。但这里涉及几个关键步骤，少一步都不行。

标准的跳转代码长这样：

typedef void (*app_func_t)(void);

void jump_to_app(uint32_t app_addr)
{
    uint32_t msp_value;
    app_func_t app_entry;

    // 1. 关闭所有中断
    __disable_irq();

    // 2. 关闭外设时钟（重要！）
    RCC->AHBENR = 0;
    RCC->APB1ENR = 0;
    RCC->APB2ENR = 0;

    // 3. 从 App 向量表读取栈指针和复位向量
    msp_value = *(volatile uint32_t*)app_addr;
    app_entry = (app_func_t)(*(volatile uint32_t*)(app_addr + 4));

    // 4. 设置主栈指针
    __set_MSP(msp_value);

    // 5. 跳转
    app_entry();
}

这段代码看着简单，但有几个细节我吃过亏：

关闭外设时钟：App 启动时会重新初始化外设，如果不关闭时钟，可能会出现总线冲突。我记得有一次没关定时器时钟，跳转后 App 的定时器中断直接跑飞了。
关闭全局中断：跳转过程中不能有任何中断干扰。跳转完成后，App 会重新使能中断。
向量表重映射：App 启动后第一件事就是修改向量表偏移寄存器（SCB->VTOR），指向自己的向量表起始地址。

注意：跳转前必须确保所有 DMA 传输已经停止，否则 DMA 可能会在跳转后继续访问已经无效的内存地址。

2.4 Flash 驱动设计：擦、写、读的底层支撑

Flash 驱动是 Bootloader 的“手和脚”。没有它，你连一个字节都写不进去。Flash 操作有三个基本动作：擦除、写入、读取。读取最简单，直接指针访问就行。擦除和写入则需要操作 Flash 控制器寄存器。

以 STM32 为例，Flash 写入的典型流程：

解锁 Flash 控制器（写 KEY 寄存器）
检查目标地址是否已擦除（读出来是 0xFF）
设置编程大小（字节/半字/字）
写入数据
等待忙标志清除
校验写入结果
锁定 Flash 控制器

这里我特别想强调一点：擦除操作是按扇区进行的。你不能只擦除一个字节，最少也要擦除一个扇区。所以设计刷写策略时，要考虑扇区大小对升级包大小的影响。

经验之谈：Flash 写入速度通常不是瓶颈，瓶颈在 CAN 通信。但擦除操作很慢（一个扇区可能几十毫秒），所以尽量在接收数据的同时完成擦除，别让用户干等。

2.5 架构总览：一张图看懂全局

说了这么多，咱们用一张图把整个架构串起来。这张图展示了从复位到 App 运行，再到刷写触发的完整链路。

这张图把整个流程分成了两条路径：正常启动路径（右侧绿色）和刷写路径（左侧红色）。中间的分叉点就是升级标志的判断。我个人觉得，把这张图贴在工位上，比看十页文档都管用。

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

最后分享几个实战中容易忽略的问题：

中断向量表偏移：App 编译时必须指定偏移地址，否则中断会跳到 Bootloader 的向量表。我见过有人忘了改链接脚本，结果中断全跑飞了。
堆栈指针恢复：跳转前必须从 App 向量表读取栈指针并设置。如果沿用 Bootloader 的栈，App 的局部变量可能会出问题。
外设状态清理：跳转前最好把用过的外设恢复到复位状态。尤其是 CAN 控制器，不清干净的话 App 可能收不到报文。
看门狗处理：刷写过程中要定期喂狗，否则 Bootloader 会被复位。我习惯在 UDS 的 TesterPresent 服务里顺便喂狗。

我的习惯：每次写完跳转逻辑，我都会在 App 的第一条指令加个 GPIO 翻转。这样用示波器一看，就知道跳转成功了没有。调试效率翻倍。

好了，Bootloader 架构设计就聊到这儿。分区策略、启动流程、跳转逻辑、Flash 驱动，这四个东西是 Bootloader 的四大支柱。搞懂了它们，后面的刷写协议实现就是水到渠成的事。