2. Bootloader基础回顾：Bootloader与App分区、跳转机制、Flash驱动原理
好，咱们正式开始第二讲。这一节我打算带大家回顾一下Bootloader最核心的几个基础概念。你可能会觉得这些内容太简单，但说实话，很多刷写翻车事故，根源都出在这些基础问题上。我自己就吃过不少亏，所以咱们还是踏踏实实把地基打牢。
2.1 Bootloader与App分区：为什么非要分开？
先问个问题：为什么ECU里要有Bootloader和App两个区域？
你想想看，如果整个Flash只放一个程序，那刷写的时候怎么办？程序正在运行，你突然要擦掉它、重写它——这不等于拆自己家的房吗？所以必须有个“安全区”。
Bootloader就是那个安全区。它负责启动、校验、刷写。App是真正的应用逻辑，比如发动机控制、BMS策略。两者物理上隔离，互不干扰。
分区方式，我见过两种主流做法：
- 固定分区：Bootloader和App的地址写死。比如0x08000000~0x0800FFFF是Bootloader，0x08010000以后是App。简单粗暴，适合小项目。
- 动态分区：通过向量表偏移来定位。Bootloader启动后，根据配置决定App的起始地址。灵活性高，但代码复杂度也上去了。
我个人习惯用固定分区，尤其是量产项目。原因很简单：出问题好排查。地址写死了，调试器一挂上去，一眼就能看出程序跑哪去了。
我在项目中遇到过一件事：某供应商用了动态分区，结果刷写时配置参数写错了，App地址偏移了4个字节。程序能跑，但中断全乱套。查了整整两天才找到原因。从那以后，我对动态分区就格外谨慎。
2.2 跳转机制：从Bootloader到App的“交接仪式”
Bootloader启动后，做完初始化、检查完刷写请求，最后一步就是跳转到App。这个跳转，不是简单的函数调用。它是一次彻底的“权力交接”。
跳转前必须做三件事：
- 关闭所有中断：包括外设中断和系统滴答定时器。否则跳过去后，中断向量表还没切换，一个中断进来就死机。
- 重置堆栈指针：App有自己的栈空间。必须从App向量表的起始地址读取栈顶指针，赋值给MSP。
- 跳转到复位向量：从向量表偏移4字节处读取复位地址，然后跳过去。
嗯，这里要注意：跳转前最好把外设也复位一遍。我见过有人只关了中断，没复位外设。结果App启动后，某个DMA还在跑，直接写飞了内存。
/* 典型的跳转代码（Cortex-M系列） */
typedef void (*pFunction)(void);
void JumpToApp(uint32_t app_addr)
{
uint32_t msp_value;
pFunction app_entry;
/* 1. 关闭全局中断 */
__disable_irq();
/* 2. 关闭所有外设中断（具体实现因芯片而异） */
for (int i = 0; i < 8; i++) {
NVIC->ICER[i] = 0xFFFFFFFF;
NVIC->ICPR[i] = 0xFFFFFFFF;
}
/* 3. 读取App向量表 */
msp_value = *(volatile uint32_t *)app_addr;
app_entry = (pFunction)(*(volatile uint32_t *)(app_addr + 4));
/* 4. 设置主栈指针 */
__set_MSP(msp_value);
/* 5. 跳转 */
app_entry();
/* 正常情况下不会执行到这里 */
while(1);
}
我曾经踩过一个坑：跳转前忘了关闭SysTick中断。App启动后，SysTick中断触发，但App的向量表还没初始化完。结果程序直接跑飞，连调试器都连不上。最后只能强制擦除Flash才救回来。
2.3 Flash驱动原理：擦、写、读，一个都不能少
Flash驱动是Bootloader的“手和脚”。没有它，你什么也干不了。但Flash操作有几个硬性约束，你必须记住：
- 擦除按扇区：不能只擦一个字节。最小单位是扇区，大小从1KB到256KB不等。
- 写入按字/页：通常一次写4字节或8字节。写之前必须确保目标区域已被擦除。
- 读取无限制：Flash可以像RAM一样直接读，但速度慢一些。
Flash驱动的基本流程：
| 操作 | 步骤 | 注意事项 |
|---|---|---|
| 擦除 | 解锁Flash控制器 → 设置擦除地址 → 启动擦除 → 等待完成 → 加锁 | 擦除期间不能响应中断，否则会卡死 |
| 写入 | 解锁 → 设置写入地址和数据 → 启动写入 → 等待完成 → 校验 → 加锁 | 写入前必须确认地址已擦除 |
| 读取 | 直接通过指针访问 | 注意对齐，部分MCU不支持非对齐访问 |
我建议：写Flash驱动时，一定要加超时机制。我遇到过Flash擦除卡死的情况——芯片体质问题，擦除命令发出去后，状态位永远不置1。没有超时，程序就死在那了。
说白了，Flash驱动就是个“状态机”。你发命令，它执行，你等结果。但这里有个细节：很多MCU的Flash控制器在执行操作时，不能从Flash取指令。所以驱动代码必须放在RAM里跑。这叫“RAM执行”或“Flash操作时驻留RAM”。
我记得第一次做Bootloader时，没注意这个细节。Flash擦除命令一发，程序直接跑飞。后来查手册才发现，擦除期间CPU不能访问Flash。把驱动搬到RAM里，问题就解决了。
2.4 小结：基础不牢，地动山摇
这一节的内容，说白了就是三个关键词：分区、跳转、Flash操作。每个点都不复杂，但组合在一起，就是Bootloader的骨架。
你想想看，如果分区搞错了，App可能覆盖Bootloader。跳转没处理好，程序可能跑飞。Flash驱动有bug，刷写可能半途而废。任何一个环节出问题，ECU就变砖了。
所以我的建议是：别急着写复杂的刷写逻辑。先把这三个基础模块调通、调稳。用单元测试验证每个函数，用边界条件测试每个分支。基础打牢了，后面的多节点同步方案才能站得住脚。
下一节，咱们聊聊刷写协议栈的设计。到时候我会分享一些实际项目中的踩坑经验，保证让你少走弯路。