2. 升级架构设计：Bootloader + App 双区架构、单区覆盖架构、A/B 系统架构

升级架构这东西，说白了就是决定「新固件往哪儿放、怎么替换老固件」。我见过不少团队一上来就写升级逻辑，结果做到一半发现 Flash 不够用，或者升级失败变砖了才回头改架构。嗯，咱们先把地基打牢。

目前主流的嵌入式升级架构就三种：Bootloader + App 双区、单区覆盖、A/B 系统。各有各的脾气，选错了后面全是坑。

  一句话总结： 双区架构最通用，单区覆盖最省空间，A/B 系统最安全但最贵。

这是我最常用的方案，也是绝大多数 MCU 项目的默认选择。芯片上电先跑 Bootloader，Bootloader 检查有没有新固件，有就更新，没有就直接跳转到 App 分区执行。

分区结构很简单：

我的习惯： Bootloader 里放一个「强制升级模式」。按住某个 GPIO 引脚再上电，不管有没有升级标志都进入等待下载状态。这招救过我很多次——有一次 OTA 下载到一半断网了，App 校验失败启动不了，客户按住按键就救回来了。

升级流程大致是这样：

这个架构的优点是实现简单、Flash 占用适中。缺点嘛——升级过程中如果掉电，App 分区可能只写了一半，下次启动 Bootloader 发现 App 校验失败，只能干等着你重新传固件。

注意： Bootloader 和 App 必须使用不同的中断向量表。App 启动后要立即把 VTOR 寄存器重映射到 App 的起始地址，否则中断全跑飞了。我曾经见过一个团队忘了做这件事，按一下按键就触发 HardFault，查了两天才找到原因。

说白了就是「原地换血」。整个 Flash 只有一个 App 分区，升级时直接擦掉老固件，写入新固件。没有 Bootloader，或者 Bootloader 小到可以忽略。

这种架构常见于 Flash 极其紧张的场景，比如 32KB 或 64KB 的芯片。你想想看，双区架构至少要多占一整个 App 的空间，A/B 系统更是翻倍，单区覆盖是唯一的选择。

但代价也很明显：

  适用场景： 传感器节点、一次性部署设备、Flash 小于 128KB 且升级频率极低的场合。

我曾经在一个智能灯的项目里被迫用了单区覆盖——芯片只有 32KB Flash，双区根本塞不下。我的做法是：先把新固件下载到外部 EEPROM，校验通过后再一次性写入内部 Flash。虽然慢了点，但至少降低了变砖概率。

如果你不得不用单区覆盖，记住几条保命原则：

这是最安全、但也最奢侈的方案。Flash 里放两个完整的 App 分区（Slot A 和 Slot B），外加一个 Bootloader。系统在 Slot A 上运行，升级时把新固件下载到 Slot B，下载完成后切换启动 Slot B。如果 Slot B 启动失败，自动回滚到 Slot A。

你想想看，这相当于给系统买了一份「保险」。汽车 ECU、医疗设备、工业控制器这些不能停机的场合，A/B 系统几乎是标配。

分区布局：

升级流程：

我建议： 在元数据区里加一个「尝试次数」字段。每次切换新 Slot 时先清零，启动成功后递增，超过最大尝试次数（比如 3 次）就自动回滚。这能防止「每次重启都尝试启动坏固件」的死循环。

A/B 系统的代价也很明显：Flash 容量翻倍。如果你的芯片只有 256KB，App 占了 120KB，那 A/B 系统直接吃掉 240KB，Bootloader 都没地方放了。所以选这个架构前，先确认 Flash 容量够不够。

注意： 两个 Slot 的中断向量表必须独立。Bootloader 跳转前要确保 VTOR 指向正确的 Slot 起始地址。另外，两个 Slot 的外设初始化逻辑要一致，否则切换后外设状态可能错乱。

我一般按这个思路来选：

最后说一句：架构选型没有银弹。我见过有人用 1MB Flash 的芯片还坚持用单区覆盖，也见过 64KB 的芯片硬上 A/B 系统结果塞不下。搞清楚你的约束条件，再动手画分区图。