4. Bootloader设计原理：启动流程、跳转逻辑、固件校验机制
各位同学，今天我们来聊聊Bootloader。说实话，Bootloader是嵌入式系统里最容易被低估的模块。很多人觉得它不就是个跳转程序吗？其实不然。我做过好几个药盒项目，每次Bootloader出问题，设备就变砖了。你想想看，药盒要是变砖了，患者怎么按时吃药？所以这块内容，咱们得认真对待。
4.1 启动流程：从复位到跳转
芯片上电后，第一件事是什么？是执行复位向量。这个向量通常指向Bootloader的入口地址。我习惯把Bootloader放在Flash的最开头，比如0x08000000。应用固件放在后面，比如0x08020000。
启动流程大致分三步：
- 硬件初始化：关中断、设置堆栈指针、配置时钟。这一步要快，我一般控制在100个时钟周期内。
- 自检与校验：检查自身完整性，确认Bootloader没被破坏。嗯，这里要注意，如果Bootloader自己坏了，那就真没救了。
- 固件决策：判断是否需要升级。如果需要，进入升级模式；否则，跳转到应用固件。
关键点：启动流程中，中断向量表的重映射是个坑。我见过有人忘了重新设置VTOR寄存器，结果中断全跑飞了。
4.2 跳转逻辑：干净利落地交接
跳转逻辑说白了，就是把CPU的控制权从Bootloader交给应用固件。这个过程看似简单，但细节很多。我曾经在一个项目里，因为跳转前没关中断，导致应用固件启动时被莫名其妙的中断打断，系统直接死机。
跳转的标准步骤：
- 关全局中断：调用__disable_irq()，确保跳转过程中不被干扰。
- 清理外设状态：把用过的外设都复位一遍。我习惯写一个DeInit函数，专门干这事。
- 设置主堆栈指针：从应用固件的起始地址读取MSP值，写入寄存器。
- 跳转到复位向量：取出应用固件的复位向量地址，用函数指针跳转。
/* 跳转到应用固件 */
typedef void (*pFunction)(void);
void jump_to_app(uint32_t app_addr)
{
uint32_t msp = *(volatile uint32_t*)app_addr;
uint32_t reset_vector = *(volatile uint32_t*)(app_addr + 4);
__disable_irq();
__set_MSP(msp);
pFunction jump = (pFunction)reset_vector;
jump();
}
我的经验：跳转前最好把SysTick也关了。不然应用固件启动时，SysTick中断突然触发，而它的中断服务程序还没准备好，系统就崩了。
4.3 固件校验机制：别让坏固件跑起来
固件校验是Bootloader的核心功能。说白了，就是确保你下载的固件是完整的、没被篡改的。我见过最惨的案例：有人没做校验，结果下载了一半断电，设备重启后执行了半截固件，药盒直接乱给药。
常用的校验方式有三种：
| 校验方式 | 原理 | 安全性 | 我推荐吗？ |
|---|---|---|---|
| CRC32 | 对整个固件计算循环冗余校验 | 中等 | 适合快速校验 |
| SHA256 | 哈希算法，不可逆 | 高 | 适合安全场景 |
| RSA签名 | 非对称加密，防篡改 | 极高 | 药盒产品必须用 |
我个人习惯用CRC32做快速校验，再用RSA签名做安全校验。为什么？因为CRC32算得快，可以在升级过程中实时校验。RSA签名虽然慢，但能防止固件被恶意替换。
避坑指南：我曾经在项目里只用了CRC32，结果有人通过逆向工程伪造了固件。从那以后，药盒类产品我强制要求RSA签名。记住，CRC32只能检测传输错误，不能防篡改。
4.4 校验流程实战
实际项目中，校验流程是这样的：
- 接收固件包：每收到一个数据包，就计算一次CRC32。这样能及时发现传输错误。
- 写入Flash：确认数据包无误后，写入Flash。我习惯用双缓冲，边收边写。
- 整体校验：固件接收完毕后，对整个Flash区域计算SHA256，与固件包里的哈希值对比。
- 签名验证：用公钥解密签名，确认固件来源可信。
- 标记有效：所有校验通过后，在Flash的特定位置写入"固件有效"标志。
你可能会问：为什么要分三步校验？其实很简单，每一步解决不同的问题。CRC32防传输错误，SHA256防数据损坏，RSA签名防恶意篡改。三层防护，才能确保药盒固件的安全性。
核心原则：固件校验不是可选项，是必选项。尤其是医疗设备，校验失败必须拒绝启动，宁可让设备停在Bootloader，也不能执行坏固件。
4.5 我的设计建议
最后，分享几个我在实际项目中总结的经验：
- Bootloader要足够小：我一般控制在16KB以内。太大了浪费Flash，也增加启动时间。
- 保留回滚能力：升级失败时，能回退到上一个可用版本。药盒不能因为升级失败就停摆。
- 加个看门狗：Bootloader执行期间，如果卡住了，看门狗能自动复位。这是最后的保命手段。
- 日志输出：通过串口打印启动过程。调试时能救命，量产时可以关掉。
嗯，Bootloader的设计就讲到这里。说白了，它就是个看门大爷，负责检查来的人（固件）是不是靠谱，靠谱了才放行。设计得好，设备稳如老狗；设计得不好，设备变砖是分分钟的事。下一章我们聊聊具体的OTA实现，到时候会用到今天讲的这些校验机制。