4、Bootloader设计原理（上）：启动流程、双区备份与看门狗
Bootloader 这个词，说白了就是芯片上电后跑的第一段程序。很多人觉得它不就是跳转到主程序嘛，有什么好讲的？但我在实际项目中吃过不少亏——有一次产品量产了，发现升级过程中断电，设备直接变砖。嗯，从那以后我才真正重视 Bootloader 的设计。
今天咱们就聊聊 Bootloader 的启动流程、双区备份机制，还有看门狗和异常处理。这些都是嵌入式固件升级的基石。
4.1 Bootloader 的启动流程
芯片复位后，CPU 会从固定的地址取指令。这个地址通常就是 Flash 的起始地址，也就是 Bootloader 的入口。我习惯把启动流程分成三个阶段：
- 硬件初始化：关中断、设置时钟、初始化堆栈。这一步要快，别拖沓。
- 自检与状态判断：检查升级标志、校验应用程序完整性、决定是跳转还是进入升级模式。
- 跳转或升级：如果应用有效，直接跳转；否则等待固件下载。
你想想看，如果每次启动都去扫描整个 Flash，那启动时间就太长了。我一般只在检测到升级标志时才做完整校验，正常启动只检查几个关键字节。
核心原则：Bootloader 要尽量精简，功能单一。它只负责两件事——启动应用和升级固件。别把协议栈、文件系统塞进去，否则出 bug 的概率会翻倍。
下面这张图展示了典型的 Bootloader 启动决策流程：
4.2 双区备份机制（A/B 分区）
双区备份，也叫 A/B 分区。说白了就是 Flash 里存两份固件——一份运行，一份备份。升级时写备份区，写完了再切换。这样即使升级过程中断电，也还有一份能用的固件。
我记得第一次做 OTA 升级时，产品经理说「升级失败率要低于万分之一」。我当时心里就咯噔一下——单分区方案根本做不到。后来上了 A/B 分区，才把问题解决。
4.2.1 分区布局
典型的 A/B 分区布局如下：
| 分区 | 起始地址 | 大小 | 作用 |
|---|---|---|---|
| Bootloader | 0x08000000 | 64 KB | 启动管理、升级入口 |
| 分区 A（应用） | 0x08010000 | 512 KB | 当前运行的应用 |
| 分区 B（备份） | 0x08090000 | 512 KB | 新固件写入位置 |
| 配置区 | 0x08110000 | 16 KB | 存储升级标志、版本号 |
我的习惯：配置区用两个备份扇区，交替写入。防止写入配置时断电导致标志丢失。这个坑我踩过——有一次配置区写了一半断电，重启后两个分区都认为自己是「当前分区」，结果死循环了。
4.2.2 升级流程
A/B 分区的升级流程其实不复杂：
- 下载固件：新固件写入非活动分区（比如当前跑 A，就写 B）。
- 校验完整性：CRC 或哈希校验，确保数据没错。
- 切换标志：把配置区的「当前分区」指向 B。
- 复位重启：Bootloader 读取标志，从 B 启动。
- 回滚机制：如果 B 启动失败，自动切回 A。
你想想看，如果第 3 步断电了怎么办？嗯，这就是为什么配置区要用双备份——即使切换标志写到一半断电，重启后 Bootloader 还能识别出「上次切换未完成」，继续使用旧分区。
注意：双区备份需要 Flash 容量翻倍。如果芯片 Flash 只有 1 MB，应用占 600 KB，那就没法做 A/B 分区。这种情况下可以考虑压缩固件或使用外部 Flash。
4.3 看门狗与异常处理
看门狗这东西，说白了就是一个定时器。你得定期喂它，否则它就把芯片复位。在升级过程中，看门狗尤其重要——如果固件下载到一半卡住了，看门狗能帮你自动恢复。
我曾经遇到过一个案例：设备在升级时网络断连，下载线程卡在 recv() 上。因为没有开看门狗，设备就这么一直挂着，直到用户手动断电。后来我加了个看门狗，超时 30 秒自动复位，问题就解决了。
4.3.1 看门狗配置要点
| 参数 | 建议值 | 说明 |
|---|---|---|
| 超时时间 | 10~30 秒 | 要大于单次擦写 Flash 的最长时间 |
| 喂狗位置 | 主循环 + 耗时操作后 | 不要在中断里喂狗，容易掩盖问题 |
| 升级期间 | 适当延长超时 | 擦除 Flash 扇区可能耗时数秒 |
避坑指南：我曾经在 Flash 擦除循环里忘了喂狗，结果每次擦除大扇区时看门狗就复位。调试了两天才发现——擦除 128 KB 扇区需要 3 秒，而看门狗超时只有 2 秒。后来我把超时改成 5 秒，并在擦除前先喂一次狗。
4.3.2 异常处理策略
升级过程中可能出现的异常，我归纳为三类：
- 通信异常：超时、断连、数据错误。处理方式：重试 3 次，失败后回滚。
- 存储异常：Flash 写入失败、校验不通过。处理方式：标记坏块，重新下载。
- 电源异常：突然断电。处理方式：靠 A/B 分区和配置区双备份兜底。
这里有个细节——异常处理要分层。底层驱动只负责上报错误，不决策。决策逻辑放在 Bootloader 的主状态机里。我习惯用枚举定义状态：
typedef enum {
BOOT_IDLE,
BOOT_CHECKING,
BOOT_DOWNLOADING,
BOOT_VERIFYING,
BOOT_SWITCHING,
BOOT_ROLLBACK,
BOOT_ERROR
} BootState_t;每个状态都有对应的超时和重试逻辑。比如 BOOT_DOWNLOADING 状态，如果 60 秒内没有收到新数据包，就自动切到 BOOT_ROLLBACK。
我的建议：在 Bootloader 里保留一个「最后一次错误码」寄存器。这样设备变砖后，通过调试接口读出错误码，就能知道是哪个环节出了问题。这个习惯帮我省了不少返厂维修的麻烦。
4.4 小结
Bootloader 的设计，说白了就是「稳」字当头。启动流程要清晰，双区备份要可靠，看门狗要喂得及时。这些基础打好了，后面的固件升级才能跑得顺畅。
我个人觉得，Bootloader 是嵌入式开发中最容易被低估的部分。很多人觉得它简单，结果一上线就出问题。嗯，希望今天的分享能帮你少走一些弯路。