3. Bootloader核心功能：固件升级、系统自检、应用程序加载、跳转机制
好，咱们直接进入正题。Bootloader 这东西，说白了就是 MCU 上电后第一个跑的程序。它的活儿很明确：检查系统是否健康、决定要不要升级固件、然后把控制权交给真正的应用程序。我做了这么多年嵌入式，见过太多因为 Bootloader 没写好导致产品变砖的案例。嗯，咱们今天就把这四大核心功能掰开揉碎了讲清楚。
3.1 固件升级——Bootloader 的“看家本领”
固件升级，这是 Bootloader 存在的最大意义。你想想看，产品都卖出去了，发现有个 bug 要修，或者想加个新功能，总不能把设备全拆回来吧？OTA（空中升级）或者本地升级就成了救命稻草。
我个人习惯把升级流程分成三步：
- 接收固件数据：通过 UART、SPI、I2C、USB 或者无线（Wi-Fi/BLE）把新的固件 bin 文件收进来。
- 校验完整性：用 CRC32 或者 MD5 校验，确保传输过程中没丢包、没篡改。
- 写入存储介质：通常是写入内部 Flash 或者外部 SPI Flash 的指定区域。
这里有个坑，我曾经踩过——写入过程中突然断电怎么办？ 所以一定要做“双备份”或者“标记位”机制。我习惯的做法是：先擦除备份区，写入新固件，校验通过后，再更新一个“启动标记”。下次上电时，Bootloader 看到这个标记，就知道该从新固件启动了。
核心原则：升级过程必须可回滚。哪怕升级到一半断电，设备也要能回到旧固件继续跑，而不是变砖。
代码示例（伪代码，展示升级流程）：
// 升级主流程
void firmware_upgrade(void) {
// 1. 擦除备份区
flash_erase(BACKUP_START_ADDR, FIRMWARE_SIZE);
// 2. 逐包接收并写入
while (receive_packet(&pkt)) {
flash_write(BACKUP_START_ADDR + pkt.offset, pkt.data, pkt.len);
}
// 3. 校验整个固件
if (crc32_verify(BACKUP_START_ADDR, FIRMWARE_SIZE, expected_crc)) {
// 4. 更新启动标记
update_boot_flag(BOOT_FROM_BACKUP);
system_reset();
} else {
// 校验失败，保持旧固件
error_handler("Firmware CRC mismatch!");
}
}3.2 系统自检——上电后的“体检报告”
系统自检，也叫 Power-On Self-Test (POST)。说白了就是 MCU 刚醒来时，先给自己做个全面体检。我建议至少检查以下几项：
- CPU 核心寄存器：读回写入的值，确认 CPU 没跑飞。
- RAM 完整性：用 March C 算法或者简单的写读校验，确保 RAM 没坏。
- Flash 校验：对 Bootloader 自身所在的 Flash 区域做 CRC 校验。
- 关键外设：比如时钟源是否稳定、看门狗是否正常工作。
你可能会问：“每次上电都做自检，会不会太慢？” 嗯，这里要权衡。对于电池供电的低功耗设备，自检时间最好控制在 10ms 以内。我一般把自检分成“快速自检”和“完整自检”两种模式。正常启动只做快速自检，只有在特定条件下（比如升级后第一次启动）才做完整自检。
我的经验：RAM 自检别用太复杂的算法。简单的“写 0x55、读 0x55，写 0xAA、读 0xAA”就能发现大部分问题。我在一个项目中就靠这个发现了某批次芯片的 RAM 地址线虚焊问题。
3.3 应用程序加载——把“接力棒”递出去
自检通过后，Bootloader 就要把应用程序从 Flash 加载到它该去的地方。这里有两种常见场景：
| 场景 | 说明 | 典型做法 |
|---|---|---|
| 原地执行（XIP） | 应用程序直接在 Flash 中运行，不搬移到 RAM | 设置中断向量表偏移，直接跳转 |
| 搬移到 RAM 执行 | 把固件从 Flash 复制到 RAM 中运行，速度更快 | 用 DMA 或者 CPU 逐字节复制，然后跳转 |
对于低功耗 MCU，我强烈推荐原地执行（XIP）。为什么呢？因为搬移到 RAM 需要额外的时间，而且 RAM 在运行期间不能进入低功耗的深度睡眠模式。你想想看，本来设备可以睡到微安级别，结果因为固件在 RAM 里，不得不保持 RAM 供电，功耗一下子就上去了。
加载过程中，别忘了做一件事：验证应用程序的完整性。我习惯在应用程序的头部预留一个 4 字节的 CRC 值。Bootloader 在跳转前，先算一遍整个应用程序区域的 CRC，跟头部存的值比对。对不上？那就别跳了，停在 Bootloader 里等待用户重新升级。
3.4 跳转机制——最危险的一步
跳转，是整个 Bootloader 里最刺激的部分。为什么？因为一旦跳转指令执行了，CPU 就完全交给应用程序了。如果跳转前没做好清理工作，应用程序跑起来就会出各种诡异的问题。
我总结了一个“跳转前必做清单”：
- 关闭所有中断：包括全局中断和各个外设的中断使能。
- 清理外设状态：把用过的 UART、SPI、定时器等外设复位到默认状态。
- 重置堆栈指针：从应用程序的中断向量表里取出栈顶地址，写入 MSP。
- 设置中断向量表偏移：对于 Cortex-M 系列，需要写 SCB->VTOR 寄存器。
- 跳转到应用程序的复位向量：通常是一个函数指针调用。
警告：跳转前一定要关闭看门狗！我曾经在一个项目中忘了关，结果跳转后应用程序还没来得及喂狗，系统就复位了。那叫一个惨，排查了整整两天才发现是这个问题。
代码示例（Cortex-M 系列跳转代码）：
typedef void (*app_entry_t)(void);
void jump_to_app(uint32_t app_addr) {
// 1. 关闭全局中断
__disable_irq();
// 2. 关闭所有外设中断（伪代码，需要根据具体 MCU 实现）
for (int i = 0; i < NUM_IRQS; i++) {
NVIC_DisableIRQ((IRQn_Type)i);
NVIC_ClearPendingIRQ((IRQn_Type)i);
}
// 3. 从应用程序向量表获取栈顶地址和入口地址
uint32_t msp = *(volatile uint32_t *)app_addr;
app_entry_t entry = (app_entry_t)(*(volatile uint32_t *)(app_addr + 4));
// 4. 设置主堆栈指针
__set_MSP(msp);
// 5. 设置中断向量表偏移
SCB->VTOR = app_addr;
// 6. 跳转
entry();
// 理论上不会执行到这里
while(1);
}这里有个细节：为什么先关中断再设置 VTOR？ 因为如果在设置 VTOR 的过程中来了个中断，CPU 会去旧的向量表找中断服务函数，但此时旧向量表可能已经被破坏了。所以顺序很重要——先关中断，再改 VTOR，最后开中断（或者干脆不开，让应用程序自己开）。
3.5 实战中的避坑指南
最后，分享几个我亲身踩过的坑：
- 坑一：跳转后外设没复位。 比如 Bootloader 里开了 UART，跳转后应用程序也开 UART，结果两个配置冲突，导致通信乱码。解决办法：跳转前把所有外设的时钟都关了，或者调用 MCU 的“外设复位”函数。
- 坑二：中断向量表对齐问题。 有些 MCU 要求 VTOR 必须按 256 字节或 512 字节对齐。如果应用程序地址没对齐，设置 VTOR 后中断全乱套。我建议在链接脚本里强制对齐。
- 坑三：堆栈指针没对准。 应用程序的向量表第一个字必须是有效的栈顶地址。如果 Flash 里那个位置是 0xFFFFFFFF（擦除后的默认值），跳转后直接就 HardFault 了。
我的小技巧：在跳转前，往一个特定的 RAM 地址写一个“魔法数”。应用程序启动后先检查这个魔法数，如果不对，说明 Bootloader 跳转过程有问题，应用程序可以主动复位或者进入安全模式。这个做法帮我抓到了好几次硬件异常。
好了，Bootloader 的四大核心功能就讲到这里。下一章咱们聊聊怎么把这些功能跟 MCU 的低功耗模式结合起来，让设备既能远程升级，又能把功耗压到极致。敬请期待。