1. 课程导入与工程目标
在嵌入式产品从“出厂即定型”走向“持续在线演进”的过程中，OTA（Over-The-Air，空中升级）已经从可选项变成基础能力。对 STM32 这类广泛用于工业控制、能源计量、医疗设备、智能家居和车载终端的 MCU 而言，OTA 不只是“把新固件通过网络写进 Flash”，而是一整套围绕可升级、可回滚、可验证、可追溯建立的工程体系。本课程的目标，是让学习者能够独立设计并实现一套可落地的 STM32 OTA 与版本治理方案，而不是停留在调用某个库或跑通一次串口升级。
一、为什么 STM32 OTA 比“下载并烧写”复杂得多
PC 或手机上的软件升级，通常由操作系统提供进程隔离、文件系统和回滚机制。STM32 上没有这些基础设施：程序直接在 Flash 上就地执行，升级过程本身也在同一颗芯片上运行。一旦升级中途断电、数据校验失败或新固件启动异常，设备可能彻底“变砖”。因此，STM32 OTA 的核心矛盾可以概括为三组：
- 空间矛盾：Flash 容量有限，既要放 Bootloader，又要放当前固件，还要为下载中的新固件预留空间，必要时还得保留旧固件用于回滚。
- 一致性矛盾：固件在传输中可能被截断、篡改或损坏，必须通过长度、CRC、哈希或数字签名确认“收到的就是完整的、正确的”。
- 可恢复矛盾：升级失败后设备必须能自动回到一个可运行状态，而不是等待人工拆机接 SWD 重烧。
这三组矛盾决定了 OTA 方案的基本结构：一个常驻的 Bootloader 负责判断“该启动谁”，一个可切换的固件分区负责承载新旧版本，一套元数据负责记录版本、状态和校验信息，一条可靠的传输通道负责把固件送到设备。版本治理则是在此之上回答“当前设备运行的是哪个版本、升级是否成功、是否需要回滚、如何批量管理”的问题。
二、典型应用场景决定了方案取舍
不同产品对 OTA 的要求差异很大，方案设计必须从场景出发。例如，智能电表通常通过 RS485 或 NB-IoT 升级，带宽低、升级耗时长，必须支持断点续传和分片校验，且升级期间不能影响计量功能；工业网关可能通过以太网或 4G 升级，固件体积较大，需要双分区和回滚能力；消费类智能家居则更关注升级成功率、用户无感和服务器侧灰度控制。再比如，医疗设备对固件签名和审计追溯有强制要求，升级包必须经过数字签名验证，且每次升级都要留下可追溯记录。
这些场景共同指向一个结论：OTA 方案不是“一套代码打天下”，而是要根据传输带宽、Flash 容量、是否允许停机、安全等级、运维规模这几个维度做权衡。课程后续会围绕这些维度展开，但本章先建立整体认知。
三、学习路线：从单机升级到版本治理
本课程按“先打通链路，再补齐治理”的顺序组织，共 30 章，大致分为四个阶段：
- 基础与启动阶段：理解 STM32 启动流程、Flash 分区、Bootloader 与应用程序的跳转关系，完成最小可用的串口升级。
- 可靠升级阶段：引入双分区、元数据、CRC/哈希校验、断点续传和失败回滚，使升级过程具备工程可靠性。
- 安全与传输阶段：加入固件签名、防回滚版本号、传输加密，并适配以太网、4G、CAN 等不同通道。
- 版本治理与量产阶段：建立版本号规范、发布流程、灰度策略、设备端版本上报和服务器侧状态追踪，形成可运维的闭环。
每个阶段都会给出可运行的代码结构、关键参数和验证方法。例如，在双分区设计中，我们会明确 Slot A 与 Slot B 的起始地址、大小、元数据字段，以及 Bootloader 如何根据元数据中的 active_slot 和 upgrade_state 决定跳转目标。这些内容不是抽象概念，而是可以直接映射到链接脚本和 Flash 操作代码的工程细节。
四、最终交付物：一套可复现的 OTA 工程
完成本课程后，学习者应当能够交付以下成果：
- 一个可在 STM32 上运行的 Bootloader，支持启动判断、固件校验、分区跳转和失败回滚；
- 一套双分区固件布局与元数据格式，包含版本号、固件长度、CRC/哈希、状态标志等字段；
- 一条完整的升级链路，覆盖固件打包、传输、接收、写入、校验和激活；
- 一套版本治理规则，包括版本号命名、发布流程、灰度策略、升级结果上报和异常处理；
- 一份可复现的测试方案，覆盖正常升级、断电中断、校验失败、回滚触发等关键场景。
接下来的章节将从 STM32 的启动流程和 Flash 组织方式讲起，逐步把上述交付物拆解为可实现的模块。学习过程中应始终带着一个问题：如果升级在任意一步失败，设备还能不能回到可运行状态？ 这个问题的答案，就是 OTA 工程是否合格的底线。