1. OTA升级工程全景

在无线物联网产品中，设备一旦部署到现场，固件缺陷修复、功能迭代、安全补丁和参数调整往往无法依赖人工返厂或现场串口烧录。OTA（Over-The-Air，空中升级）因此成为产品生命周期管理的基础能力。Silicon Labs 的 OTA 方案并不是单一协议，而是一套围绕 Gecko Bootloader、应用镜像、存储分区和无线传输协议协同工作的工程体系。理解它的定位，关键在于把“升级”看成一次受控的固件替换过程：新镜像必须被可靠地传输、校验、暂存、激活，并在失败时具备回退或重试能力。

从技术定位看，Silicon Labs OTA 主要服务于 EFR32 系列无线 SoC 和模块，覆盖 Zigbee、Thread、Bluetooth LE、Sub-GHz 等协议场景。它通常由三部分构成：运行在设备上的 Gecko Bootloader、负责存储升级镜像的 Flash 分区，以及由主机或网关发起的传输通道。Bootloader 是升级能否成功的关键，它决定设备是否支持 Standalone、Local、Application 等不同升级模式，也决定镜像校验、Slot 管理和启动切换方式。应用固件本身并不直接“覆盖自己”，而是把新镜像写入指定存储区域，再由 Bootloader 在复位后完成搬运或激活。

典型应用场景可以按部署形态区分。第一类是智能家居中的 Zigbee 或 Thread 设备，例如灯控、传感器、门锁，通常通过网关或边界路由器下发镜像，设备数量多、单节点资源有限，升级过程需要分片、重传和低功耗配合。第二类是 Bluetooth LE 设备，例如手环、医疗贴片、资产标签，常由手机 App 作为 OTA 客户端，升级过程受连接间隔、MTU 和手机侧并发能力影响。第三类是 Sub-GHz 或私有协议设备，例如表计、安防探头，链路速率低但覆盖远，镜像分片和超时策略需要更保守。第四类是已部署的网关或集中器，它们可能同时承担“被升级对象”和“升级分发者”两种角色。

端到端升级流程可以抽象为六个阶段：镜像准备、传输协商、分片下发、设备暂存、校验激活、结果确认。镜像准备阶段，开发者需要生成带正确版本号和签名的 GBL 文件，并确认其大小不超过目标 Slot 容量。传输协商阶段，客户端与设备交换版本、能力、分片大小和超时参数。分片下发阶段，镜像被切分为若干块，通过 Zigbee OTA Cluster、BLE GATT 或自定义协议逐块发送。设备暂存阶段，Bootloader 或应用将数据写入下载 Slot，并维护写入偏移和 CRC。校验激活阶段，设备对完整镜像做签名或 CRC 校验，通过后设置启动标志并复位。结果确认阶段，客户端读取设备版本或升级状态，判断是否成功，失败则进入重试或回退。

把上述流程落到工程实现，需要关注几个容易出问题的环节。第一是镜像大小与 Slot 容量的匹配。假设目标设备 Flash 为 1 MB，Bootloader 占用约 32 KB，Application 运行区约 400 KB，Download Slot 约 256 KB，那么新镜像必须小于 256 KB，否则传输到一半就会因空间不足失败。第二是分片与超时。以 BLE OTA 为例，若 MTU 协商为 247 字节，实际每包有效载荷约 244 字节，1 KB 分片约需 5 包；若连接间隔为 30 ms，单分片理论耗时约 150 ms，但实际受重传和手机调度影响，可能达到 300～500 ms。第三是校验与回退。Bootloader 在激活前必须确认镜像完整，若校验失败，应保留原运行区并上报错误码，而不是直接跳转到损坏镜像。

本课程后续将围绕这些环节展开，实战目标可以归纳为四条主线。第一条主线是“能生成”：掌握 GBL 文件生成、签名配置和版本号管理，能够为 EFR32 目标板产出可升级镜像。第二条主线是“能传输”：理解 Zigbee OTA Cluster、BLE GATT 和自定义协议下的分片、重传与流控机制，能够根据链路特性调整分片大小和超时参数。第三条主线是“能验证”：掌握 Bootloader 的 Slot 管理、CRC 与签名校验、启动标志设置，能够通过日志和版本号判断升级是否成功。第四条主线是“能排障”：面对升级失败、卡死、回退等现场问题，能够从镜像、传输、存储、Bootloader 四个层面定位原因并给出修复方案。