第三章 Bootloader基础原理：启动流程、向量表重映射、跳转逻辑

好，咱们进入正题。这一章讲的是Bootloader最核心的底层机制——启动流程、向量表重映射、还有跳转逻辑。说实话，这部分内容我当年刚接触时也绕了好一阵子。你想想看，一个芯片上电后，它怎么知道该跑哪段代码？怎么从Bootloader切到应用程序？这里面的门道，我今天一次性给你讲透。

3.1 芯片上电后的启动流程

芯片上电后，第一件事是什么？不是跑你的代码，而是先看复位向量。以ARM Cortex-M系列为例，芯片从Flash的0x00000000地址开始，读取两个字：

  • 第一个字（0x00000000）：栈顶指针（MSP），给主堆栈用
  • 第二个字（0x00000004）：复位向量，也就是复位后第一条指令的地址

说白了，芯片就是个“死脑筋”。它不看文件名，不看函数名，就看这两个固定地址。我在项目中遇到过有人把向量表放错了位置，结果芯片一上电就跑飞了，查了两天才发现是链接脚本里地址没对齐。

核心要点：芯片启动时，硬件自动从0x00000000加载MSP，从0x00000004加载PC指针。这是硬编码行为，无法改变。

那么问题来了：如果Bootloader和应用程序都在Flash里，芯片怎么区分？答案是——通过分区。通常我们把Flash分成两个区域：

区域 起始地址 大小 内容
Bootloader区 0x08000000 32KB Bootloader代码 + 向量表
应用程序区 0x08008000 480KB App代码 + 向量表
参数区 0x0807E000 8KB 升级标志、校验值等

嗯，这里要注意：Bootloader的向量表必须放在Flash起始地址。应用程序的向量表则放在它自己的起始地址。那Bootloader怎么知道该不该跳转到App？我习惯用一个升级标志位——比如在参数区写一个特定的魔数（Magic Number）。

3.2 向量表重映射

向量表重映射，听起来很高大上，其实就一句话：告诉CPU，你的中断向量表搬家了，别老盯着0x00000000看。

在Cortex-M上，有个专门的寄存器叫SCB->VTOR（Vector Table Offset Register）。你往里面写一个地址，CPU就会从那个地址找中断向量。比如你的App放在0x08008000，那你就写：

SCB->VTOR = 0x08008000;

就这么简单？对，就这么简单。但我曾经踩过一个坑——写完VTOR之后，必须立即执行一个DSB指令（数据同步屏障），否则CPU可能还在用旧的向量表。代码应该是这样：

SCB->VTOR = APP_ADDRESS;
__DSB();  // 数据同步屏障，确保VTOR生效
__ISB();  // 指令同步屏障，刷新流水线

警告：不要省略DSB和ISB！我见过有人跳转后中断不响应，就是因为没加这两个屏障。CPU的流水线里还残留着旧向量表的指令，你不清掉它，它就会乱跑。

另外，向量表重映射后，你的中断服务函数（ISR）地址也要跟着变。比如原来的UART中断在0x0800004C，现在变成了0x0800804C。只要你的App代码里正确声明了中断函数，链接器会自动算好偏移，不用你手动改。

3.3 跳转逻辑

跳转逻辑，说白了就是从Bootloader跳到App的入口点。这里有个关键点：不能直接调用一个函数，因为App的代码是独立编译的，它的链接地址和Bootloader不同。你得用函数指针跳转。

标准的跳转流程分三步：

  1. 关闭全局中断——跳转过程中不能被打断
  2. 设置向量表偏移——告诉CPU新的中断向量在哪
  3. 获取App的复位向量地址——从App向量表的第二个字取出PC值
  4. 跳转——用函数指针执行

代码实现如下：

typedef void (*pFunction)(void);

void JumpToApp(uint32_t app_addr)
{
    uint32_t msp_value;
    uint32_t reset_vector;
    pFunction app_entry;

    // 1. 关闭全局中断
    __disable_irq();

    // 2. 关闭所有外设中断（根据具体芯片实现）
    // 比如：NVIC->ICER[0] = 0xFFFFFFFF;

    // 3. 从App向量表读取栈顶指针
    msp_value = *(volatile uint32_t*)app_addr;

    // 4. 从App向量表读取复位向量
    reset_vector = *(volatile uint32_t*)(app_addr + 4);

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

    // 6. 设置向量表偏移
    SCB->VTOR = app_addr;
    __DSB();
    __ISB();

    // 7. 构造函数指针并跳转
    app_entry = (pFunction)reset_vector;
    app_entry();
}

个人经验：我习惯在跳转前把SysTick定时器也关掉，因为SysTick中断可能会在跳转瞬间触发，而App还没初始化好。另外，跳转前最好把RCC时钟配置也重置一下，避免App里用不同的时钟配置导致冲突。

你可能会问：为什么跳转前要关中断？原因很简单——跳转过程中，CPU正在切换上下文。如果此时来了一个中断，CPU会去查向量表。但向量表还没设置好，它可能查到旧地址，或者查到无效地址，结果就是HardFault。我曾经在调试时遇到过这个问题，中断一响，程序就飞了，查了半天才发现是中断没关干净。

3.4 避坑指南

这部分我踩过的坑比较多，给你列几个最常见的：

  • 栈指针没对齐——Cortex-M要求栈指针必须8字节对齐，否则某些指令会异常。我建议在跳转前检查一下：if (msp_value & 0x07) { /* 报错 */ }
  • 外设状态没清理——比如UART还在发送数据，你跳转了，DMA可能还在跑。我习惯在跳转前把所有外设复位到默认状态。
  • 中断优先级分组不一致——Bootloader和App可能用了不同的优先级分组（比如3位抢占+1位子优先级 vs 4位抢占）。跳转后如果不重新设置，中断行为会乱套。
  • 链接脚本地址不匹配——App的链接脚本里，Flash起始地址必须和跳转地址一致。否则你跳过去了，但代码跑的位置不对，必死无疑。

嗯，说到链接脚本，我再多提一句。我见过有人把App的起始地址设成0x08008000，但跳转时传了0x08000000。结果呢？App的向量表被当成Bootloader的向量表来解析，栈指针和复位向量全错了。这种错误很难查，因为代码看起来没问题，但就是跑不起来。我的建议是：在跳转函数里加一个地址合法性检查，比如判断app_addr是否在App分区范围内。

3.5 小结

这一章的内容，说白了就是三件事：

  1. 芯片上电后从0地址启动，Bootloader负责判断是进升级模式还是跳App
  2. 向量表重映射通过SCB->VTOR实现，别忘了加DSB和ISB
  3. 跳转时要关中断、设栈指针、清流水线，一步都不能少

我个人觉得，Bootloader的跳转逻辑是整个远程升级方案中最容易出问题的地方。你想想看，如果跳转本身就不稳定，那后面的校验、加密、断点续传全都没意义。所以这一章的内容，建议你多花点时间理解透彻。下一章我们会讲Flash分区管理与擦写策略，到时候你会看到，跳转逻辑和分区设计是紧密耦合的。

← 上一章 📖 返回目录 下一章 →