| 编辑推荐: |
本文主要介绍了BootLoader 核心功能与架构设计相关内容，希望对您的学习有所帮助。
本文来自于微信公众号一枚嵌入式码农，由火龙果软件Alice编辑、推荐。
|
|
引言：价值一亿的"补丁"
假设这么一个场景：你们公司卖出了 10 万台智能门锁，分布在全国各地的小区里。某天，测试同事脸色铁青地告诉你——代码里有个
Bug，会导致电池 3 天就耗尽。
没有 BootLoader 的世界：
派工程师全国出差，挨家挨户拆锁、接烧录器、刷固件。差旅费、人力成本、用户投诉、品牌信誉崩塌……保守估计损失过亿。
有 BootLoader 的世界：
后台推送一个 OTA 升级包，用户手机点一下"确认升级"，睡一觉起来问题就解决了。成本约等于零。
这就是 BootLoader 存在的意义。
它不是简单的"启动代码"，而是嵌入式系统的"守门员"和"搬运工"。
守门员负责检查"要不要升级"，搬运工负责把新固件安全地搬进 Flash。
今天这篇文章，我们就来扒一扒：BootLoader 到底是怎么在 App
运行之前接管系统，并安全完成这场"换脑手术"的。
一、宏观视野：Flash 里的"楚河汉界"
要理解 BootLoader，首先得搞清楚一件事：Flash 是怎么被切分的？
很多新手以为整个 Flash 就是一整块"硬盘"，代码往里一塞就完事了。实际上，一个带
BootLoader 的系统，Flash 至少要划分成三块"地盘"：
• BootLoader 区：从 0x0800 0000 开始，这是
STM32 的固定启动地址。芯片上电后，PC 指针第一个跑到这儿。这块区域一般烧录一次就不动了。
• Param 参数区：存一些关键标志位，比如 NEED_UPDATE（需要升级吗？）、APP_VERSION（当前版本号）等。BootLoader
靠读这些标志位来决定下一步动作。
• App 应用区：真正跑业务逻辑的地方。你写的那些控制电机、读传感器的代码，都住在这里。
启动流程对比
普通启动（没有 BootLoader）：
带 BootLoader 的启动：
复位
→ 运行 BootLoader → 检查标志位 → 需要升级？→ 是：下载固件、擦写 Flash、校验、复位
→ 否：跳转到 App |
复位 → 运行 BootLoader → 检查标志位 → 需要升级？→
是：下载固件、擦写 Flash、校验、复位 → 否：跳转到 App
看出区别了吗？BootLoader 像个"前台接待"，每次开机先问一句："今天有升级任务吗？"没有就放行，有就开始干活。
二、核心职能：BootLoader 的"三板斧"
说了这么多，BootLoader 具体干了什么？总结下来就是三件事：通信、擦写、校验。我称之为"三板斧"。
第一板斧：通信搬运
固件从哪儿来？BootLoader 得有本事把它"接"进来。
常见的通信方式包括：
| 方式 |
协议 |
典型场景 |
| UART |
Xmodem/Ymodem |
调试阶段，用串口线升级 |
| USB |
DFU 协议 |
消费电子，插线升级 |
| CAN |
UDS 协议 |
汽车电子，诊断仪升级 |
| 网络 |
MQTT/HTTP |
物联网 OTA 远程升级 |
这里有个细节：BootLoader 里的通信代码通常是"精简版"。比如做
OTA，你不需要塞一个完整的 lwIP 协议栈进去，一个极简的 TCP 收发就够了。体积小才是王道，BootLoader
一般控制在 16KB~32KB 以内。
第二板斧：Flash 擦写
固件接收完了，下一步就是往 Flash 里"搬家"。这个过程叫
IAP（In-Application Programming），翻译过来就是"应用内编程"。
为什么叫"应用内"？因为这时候芯片已经在跑 BootLoader
程序了，它一边运行，一边擦写 Flash 的另一块区域。这就好比你一边开车一边换轮胎——听起来很刺激，但
BootLoader 确实在干这事。
关键难点：别擦错地方！
Flash 擦除是按"扇区（Sector）"进行的，一擦就是一整块。如果地址算错了，把
BootLoader 自己给擦了，那就真成"自杀式升级"了。
所以代码里必须加地址保护：
// 地址合法性检查
if (addr
< APP_START_ADDR || addr > APP_END_ADDR)
{
return ERROR_INVALID_ADDR;
// 拒绝操作
} |
这几行代码看着简单，但救过无数人的命。
第三板斧：完整性校验
数据在传输过程中可能丢包、错位、被干扰。如果不检查就直接写进去，轻则功能异常，重则直接变砖。
常用校验手段：
• CRC32：标配，计算快，能抓住大部分传输错误
• MD5/SHA256：高配，用于安全性要求高的场景，还能防篡改
校验的逻辑很简单：固件包里带一个校验值，BootLoader 收完数据后自己算一遍，两边对上了才能往下走。对不上？老老实实报错，绝不能硬跳转。
三、灵魂一跃：如何从 Boot 跳转到 App？
这是整个 BootLoader 里最"玄学"的部分，也是很多新手卡住的地方。
BootLoader 干完活，怎么把控制权交给 App？总不能 while(1)
卡在那儿吧。
答案是：手动修改 CPU 的关键寄存器，让它"以为"自己刚刚复位，然后从
App 的入口开始跑。
跳转五步曲
void JumpToApp(uint32_t appAddr)
{
typedef void (*pFunction)(void);
pFunction
JumpToApplication;
// 1. 关中断：防止跳转过程中断来捣乱
__disable_irq();
// 2. 复位用过的外设（Timer、DMA等）
HAL_TIM_Base_DeInit(&htim2);
HAL_UART_DeInit(&huart1);
// 3. 设置栈指针（MSP）
//
App 固件的第一个字就是栈顶地址
__set_MSP(*(uint32_t*)appAddr);
// 4. 重定向向量表（VTOR）
//
告诉 CPU：以后中断去 App 那边找
SCB->VTOR
= appAddr;
// 5. 跳转！读取
Reset_Handler 地址并执行
JumpToApplication
= (pFunction)(*(uint32_t*)(appAddr
+ 4));
JumpToApplication();
} |
让我逐行解释一下：
第 1 步：关中断
跳转过程中，如果有中断触发，CPU 会去向量表里找中断处理函数。但这时候向量表还没切过去，找到的还是
BootLoader 的函数，直接就跑飞了。所以必须先关掉。
第 2 步：复位外设
BootLoader 可能用了串口、定时器等外设。如果不清理干净就跳转，App
初始化同一个外设时可能会出问题。给 App 一个"干净"的硬件环境很重要。
第 3 步：设置 MSP（主栈指针）
Cortex-M 架构规定：固件的前 4 个字节存的是栈顶地址。BootLoader
要把这个值读出来，塞进 MSP 寄存器，这样 App 跑起来才有栈可用。
第 4 步：重定向 VTOR
VTOR 是 Cortex-M3/M4 新增的寄存器，全称 Vector
Table Offset Register（向量表偏移寄存器）。改了它之后，CPU 就知道：以后发生中断，去
App 的地址找向量表，别来 BootLoader 这儿找了。
第 5 步：跳！
固件的第 5~8 个字节存的是 Reset_Handler 的地址。读出来，强转成函数指针，调用它——App
就跑起来了。
四、高阶架构：如何保证"永远不砖"？
前面讲的都是"正常流程"。但现实往往不那么美好：升级升到一半，突然断电了怎么办？
单分区的致命缺陷
最简单的方案是只划一个 App 区：旧固件擦掉，新固件写进去。
问题来了：擦除完成、写入一半的时候，电没了。
结果：旧的没了，新的也没写完。App 区一片狼藉，系统启动后要么跑飞，要么直接卡死。虽然
BootLoader 还活着，但设备已经废了——这就是"变砖"。
双分区（A/B System）的智慧
工业级、车规级产品怎么解决这个问题？双分区。
核心思路：
1. Flash 划出两块 App 区：A 和 B
2. 系统平时从 A 区运行
3. 新固件下载到 B 区，A 区纹丝不动
4. 下载完成、校验通过后，修改标志位，告诉 BootLoader：下次启动从
B 区跑
5. 重启，BootLoader 读标志位，跳转到 B 区
最大的好处是什么？
下载过程中断电——没关系，A 区是好的，下次开机还能正常工作，大不了重新下载。
新版本有 Bug——没关系，标志位一改，重启后切回 A 区，还是老版本。
这就是为什么 Android 手机、特斯拉汽车都用 A/B 分区方案。宁可多花一倍
Flash 空间，也要换一个"永远不砖"的保障。
五、总结与展望
写到这里，我们梳理一下 BootLoader 的核心知识点：
1. Flash 分区：Boot 区 + Param 区 + App
区，三块地盘各司其职
2. 三板斧：通信接收、Flash 擦写（IAP）、完整性校验
3. 跳转机制：关中断、复位外设、设 MSP、改 VTOR、跳 PC——五步缺一不可
4. 双分区架构：用空间换安全，A/B 分区保证永不变砖
随着物联网设备越来越多，安全问题也越来越重要。未来的 BootLoader
不仅要能升级，还得能安全启动（Secure Boot）——不光校验 CRC，还要验证数字签名，防止固件被篡改。这是另一个大话题，以后有机会再聊。
| 
订阅
