📚 课程目录第3章 Bootloader核心设计

3、Bootloader核心设计：启动流程、向量表重映射、跳转逻辑

Bootloader 这东西，说白了就是芯片上电后跑的第一段程序。很多人觉得它就是个跳板，跳过去就完事了。但实际做项目时你会发现——跳不好，整个系统就瘫了。

我个人习惯把 Bootloader 比作「机场的塔台」。飞机（应用程序）能不能起飞、降落在哪个跑道、遇到故障怎么复飞，全由塔台说了算。今天我们就来拆解这个塔台的核心机制。

3.1 启动流程：从复位到跳转的完整链路

芯片上电后，硬件会自动做三件事：

从固定地址加载栈指针（通常是 0x00000000 或 0x08000000）
从固定地址+4 加载复位向量，也就是 PC 指针的初始值
开始执行复位向量指向的代码

嗯，这里要注意——这个「固定地址」就是你的 Bootloader 入口。我在项目中遇到过有人把应用程序直接烧在 0x08000000，结果 Bootloader 根本没机会跑。为什么？因为芯片一上电就直接进应用了，你连升级的机会都没有。

正确的做法是：Bootloader 放在起始地址，应用程序放在后面偏移的位置。比如 STM32 的 Flash 从 0x08000000 开始，Bootloader 占 32KB（0x08000000 ~ 0x08007FFF），应用程序从 0x08008000 开始。

启动流程核心步骤：

上电 → 硬件加载 MSP 和 PC
执行 Bootloader 入口（汇编 Startup 文件）
初始化时钟、外设、内存
检查升级标志 / 校验应用程序有效性
决定：原地等待升级 OR 跳转到应用程序

你想想看，如果每次上电都先跑 Bootloader，那应用程序的启动速度会不会变慢？会，但这是必要的代价。我一般控制在 200ms 以内完成 Bootloader 的检查和跳转，用户基本感知不到。

3.2 向量表重映射：让中断找到新家

这是 Bootloader 里最容易翻车的地方。应用程序跑在偏移后的地址上，但中断来了，CPU 还是去原来的向量表找入口——那肯定找不到。

向量表重映射，就是告诉 CPU：「嘿，中断向量表搬家了，新地址在 0x08008000。」

具体怎么做？以 Cortex-M 系列为例，有两个关键点：

方法	原理	适用场景
SCB->VTOR 寄存器	直接修改向量表偏移地址	绝大多数 Cortex-M3/M4/M7
内存映射重映射	通过 SYSCFG 或 MPU 重映射地址	部分 Cortex-M0+ 或特殊型号

我最常用的是 VTOR 方式。在跳转之前，应用程序的第一件事就是设置 VTOR：

// 应用程序入口处（Reset_Handler）
#define APP_BASE_ADDR  0x08008000

void Reset_Handler(void)
{
    // 重映射向量表到应用程序区
    SCB->VTOR = APP_BASE_ADDR;
    
    // 然后才是正常的系统初始化
    SystemInit();
    // ...
}

我曾经踩过的坑： 在 Bootloader 里也调用了外设中断，跳转前没有关闭这些中断。结果应用程序一启动，中断来了，但向量表还没重映射——直接 HardFault。正确的做法是：跳转前关闭所有外设中断，关全局中断，清挂起标志。

3.3 跳转逻辑：优雅地交出控制权

跳转不是简单的 goto。你要确保 Bootloader 把「舞台」收拾干净，应用程序才能顺利开演。

我总结了一个跳转检查清单：

校验应用程序完整性——CRC 或 SHA256，确保代码没被破坏
关闭所有外设时钟——尤其是 DMA、定时器、USB 这些可能还在跑的外设
禁用所有中断——包括 SysTick，防止跳转瞬间被打断
恢复默认中断优先级——把 NVIC 的优先级分组复位
清理全局变量——BSS 段清零，避免残留数据影响应用
设置主栈指针——从应用程序向量表头部加载 MSP
跳转到复位向量——用函数指针执行

代码实现大概是这样的：

typedef void (*JumpFunc_t)(void);

void JumpToApp(uint32_t app_addr)
{
    uint32_t msp_value;
    JumpFunc_t reset_handler;
    
    // 1. 关闭全局中断
    __disable_irq();
    
    // 2. 关闭所有外设时钟（以 STM32F4 为例）
    RCC->AHB1ENR = 0;
    RCC->AHB2ENR = 0;
    RCC->APB1ENR = 0;
    RCC->APB2ENR = 0;
    
    // 3. 清除所有中断挂起
    for (int i = 0; i < 8; i++) {
        NVIC->ICER[i] = 0xFFFFFFFF;
        NVIC->ICPTR[i] = 0xFFFFFFFF;
    }
    
    // 4. 从应用程序向量表读取 MSP 和 Reset_Handler
    msp_value = *(volatile uint32_t *)app_addr;
    reset_handler = (JumpFunc_t)(*(volatile uint32_t *)(app_addr + 4));
    
    // 5. 设置主栈指针
    __set_MSP(msp_value);
    
    // 6. 跳转
    reset_handler();
    
    // 理论上不会执行到这里
    while(1);
}

小技巧： 我习惯在跳转前把 Bootloader 用到的堆栈区域全部填成 0xDEADBEEF。这样如果应用程序意外访问了 Bootloader 的栈空间，调试时一眼就能看出来。

3.4 双区备份与故障回滚的启动决策

既然我们做的是双协议升级，那 Bootloader 的启动决策就得支持双区备份。简单说就是：Flash 里有两个应用程序区，一个跑，一个备。

启动时的决策逻辑：

检查 A 区：如果有效且无升级标志 → 跳转 A 区
检查 B 区：如果 A 区无效但 B 区有效 → 跳转 B 区（回滚）
两个都无效：进入 DFU 模式，等待 CAN 或 USB 升级
有强制升级标志：不跳转，直接进 DFU

这个决策树我建议画成状态机，清晰且不容易漏分支。下面这张图就是我在项目中实际使用的启动决策流程：

这个流程我用了很多年，逻辑上覆盖了所有正常和异常情况。唯一要注意的是——检查应用程序有效性的算法要足够快。我一般用 CRC32 校验前 256 字节的关键数据区，而不是全片校验，这样能把检查时间控制在 10ms 以内。

核心要点总结：

启动流程：复位 → Bootloader → 决策 → 跳转
向量表重映射：SCB->VTOR 是首选，必须在应用入口第一时间执行
跳转逻辑：关中断、关外设、清标志、设 MSP、跳转——顺序不能乱
双区决策：A 区优先 → B 区回滚 → DFU 兜底

嗯，Bootloader 的核心设计就这些。说白了就是三件事：从哪开始、中断怎么找、怎么跳过去。把这三件事想清楚，你的 Bootloader 就稳了八成。剩下的两成，是各种边界情况和异常处理——那些我们后面章节再细聊。