3、Bootloader核心原理：地址映射、中断向量表重定向与启动模式选择

好，咱们今天聊点硬核的。Bootloader 说白了，就是芯片上电后跑的第一段程序。它的任务很单纯——把真正的应用程序给拽起来。但这里头有几个关键机制，搞不懂的话，你写出来的 Bootloader 大概率会翻车。

我个人习惯把 Bootloader 比作「看门大爷」。它先检查一下有没有新固件要升级，没有的话，就开门让应用程序进去跑。但问题是，这俩程序都住在同一个芯片里，怎么保证它们不打架？这就涉及到地址映射、中断向量表重定向，还有启动模式的选择。

3.1 地址映射：谁该住在哪里

芯片的 Flash 空间是有限的。你得提前规划好，Bootloader 占哪块，应用程序占哪块。我见过不少新手，直接把两个程序编译到同一个地址，结果一运行就死机。

举个例子，假设芯片 Flash 从 0x08000000 开始：

// 典型的地址划分（以 STM32 为例）
#define BOOTLOADER_START_ADDR    0x08000000  // Bootloader 起始地址
#define BOOTLOADER_SIZE          0x00010000  // 64KB

#define APP_START_ADDR           0x08010000  // 应用程序起始地址
#define APP_MAX_SIZE             0x00070000  // 448KB

这里要注意，Bootloader 和应用程序的链接脚本（Linker Script）必须分开配置。你不能让应用程序也以为自己从 0x08000000 开始跑。

我在项目中遇到过一件事：有个同事把两个程序的链接脚本搞混了，结果 Bootloader 跳转到应用程序时，直接跑飞。查了两天才发现，应用程序的向量表地址没改过来。嗯，这就是典型的地址映射错误。

3.2 中断向量表重定向：别让中断跑错地方

芯片上电后，默认的中断向量表在 Flash 起始地址（0x08000000）。Bootloader 自己用着没问题。但当你跳转到应用程序时，问题就来了——应用程序的中断向量表在 0x08010000 啊！

如果不做重定向，一旦发生中断，CPU 还是会跑到 0x08000000 去找中断服务函数。那里是 Bootloader 的地盘，它哪知道应用程序的中断该怎么处理？结果就是死机。

解决办法很简单：修改向量表偏移寄存器（VTOR）。

// 以 ARM Cortex-M 系列为例
#define SCB_VTOR   (*(volatile uint32_t *)0xE000ED08)

void jump_to_app(uint32_t app_addr)
{
    // 1. 关闭全局中断
    __disable_irq();
    
    // 2. 设置中断向量表偏移
    SCB_VTOR = app_addr;
    
    // 3. 从应用程序的向量表中取出栈顶指针和复位地址
    uint32_t stack_ptr = *(volatile uint32_t *)app_addr;
    uint32_t reset_addr = *(volatile uint32_t *)(app_addr + 4);
    
    // 4. 设置主栈指针
    __set_MSP(stack_ptr);
    
    // 5. 跳转到应用程序的复位函数
    void (*app_reset)(void) = (void (*)(void))reset_addr;
    app_reset();
}

你想想看，这个重定向操作必须在跳转之前完成。而且跳转后，应用程序自己也可以再次修改 VTOR，但一般没必要。只要 Bootloader 设置对了，应用程序就能正常响应中断。

3.3 启动模式选择：串行还是并行？

启动模式，说白了就是 Bootloader 怎么决定下一步干啥。是老老实实跳转到应用程序，还是先检查一下有没有升级请求？

常见的启动模式有两种：

模式	触发方式	适用场景
串行模式	通过 UART、SPI、I2C 等串行接口接收升级数据	产品出厂后，通过外部工具升级
并行模式	通过 GPIO 电平、Flash 标志位等判断	现场快速切换，无需外部工具

我个人习惯把这两种模式结合起来用。举个例子：

void bootloader_main(void)
{
    // 1. 检查是否有升级请求（并行模式）
    if (check_update_flag() == TRUE)
    {
        // 进入串行升级模式
        enter_serial_update();
    }
    else
    {
        // 2. 检查应用程序是否有效
        if (is_app_valid(APP_START_ADDR))
        {
            // 跳转到应用程序
            jump_to_app(APP_START_ADDR);
        }
        else
        {
            // 应用程序无效，强制进入升级模式
            enter_serial_update();
        }
    }
}

这里有个小技巧：我通常会在 Flash 的某个固定地址存一个「升级标志位」。当应用程序需要升级时，它会在重启前把这个标志位写成一个特定值。Bootloader 启动时一读，就知道该进升级模式了。

至于串行模式的具体实现，我一般用 Ymodem 协议。它简单可靠，支持分包传输和 CRC 校验。你想想看，内窥镜这种设备，升级数据量不大，Ymodem 完全够用。

3.4 实战中的几个坑

说了这么多，我总结几个实际项目中容易踩的坑：

1. 地址对齐问题：应用程序的起始地址必须是扇区对齐的。比如 STM32F103 的扇区大小是 1KB，那 APP_START_ADDR 必须是 1KB 的整数倍。否则擦除操作会出问题。
2. 中断优先级分组：Bootloader 和应用程序的中断优先级分组必须一致。我见过有人 Bootloader 里用 4 位抢占优先级，应用程序里用 3 位，结果中断嵌套全乱套了。
3. 外设状态清理：跳转前，最好把用过的外设（UART、定时器等）都复位一下。否则应用程序启动时，外设可能还处于 Bootloader 配置的状态，导致异常。

嗯，这些坑我基本都踩过一遍。写出来就是希望大家别走弯路。Bootloader 这东西，看着简单，但细节决定成败。地址映射、中断向量表重定向、启动模式选择，这三板斧抡好了，你的固件升级方案就稳了一大半。