2. Silicon Labs无线SoC与协议栈选型
OTA升级能否顺利落地，第一步并不在写升级代码，而在选型。Silicon Labs 的 EFR32 系列把无线收发器、Cortex-M 内核、Flash/RAM 与安全模块集成在同一颗 SoC 上，但不同子系列、不同协议栈对 OTA 的支持方式差别很大。选错芯片或协议栈，后期往往要面对“镜像放不下”“升级时断网”“Bootloader 空间不够”这类返工问题。本节从芯片能力、协议栈机制、存储与安全约束三个角度，给出可操作的选型依据。
一、EFR32 子系列与 OTA 相关的关键差异
EFR32 常见子系列包括 EFR32MG（多协议，主打 Zigbee/Thread）、EFR32BG（Bluetooth LE）、EFR32FG（专有 Sub-GHz/2.4G）、EFR32xG21/xG24/xG28 等代际。对 OTA 影响最大的不是主频，而是三件事：Flash 容量、是否支持双区（dual-image）升级、以及是否带 Secure Vault 安全子系统。
- Flash 容量：单区升级只需“应用区 + Bootloader + 新镜像暂存区”，双区升级则需要两份完整应用镜像。以 xG24 为例，512 KB Flash 做双区 Zigbee OTA 会非常紧张，1024 KB 才比较从容。
- Secure Vault：xG21 起引入，xG24 为 Secure Vault Mid/High。它提供密钥存储、安全启动与签名验证，是 OTA 镜像防篡改的基础。若产品需要“只接受签名固件”，必须选带 Secure Vault 的型号。
- Bootloader 支持：Silicon Labs 的 Gecko Bootloader 分“Standalone”和“Application”两类，前者不依赖应用即可接收升级，后者需应用配合。芯片需预留 Bootloader 区（通常 16–32 KB）。
二、三种协议栈的 OTA 机制对比
Zigbee、Thread、Bluetooth LE 的 OTA 不是同一套逻辑，差异集中在“谁来传镜像、镜像怎么分片、升级期间设备是否还在网”。
| 维度 | Zigbee OTA | Thread OTA | Bluetooth LE OTA |
|---|---|---|---|
| 标准 | ZCL OTA Cluster (0x0019) | Thread 本身不定义 OTA，靠应用层（如 Matter） | Silabs 私有 DFU / 标准 L2CAP CoC |
| 传输方式 | Mesh 内逐跳转发，可多设备分发 | 基于 IPv6/UDP，通常由边界路由器或 Matter 控制器推送 | 点对点，手机/网关直连设备 |
| 分片粒度 | 默认约 64–80 字节/片，可调 | 由应用层决定，常见 1 KB 左右块 | L2CAP CoC 可到数百字节/包 |
| 升级时联网 | 可保持入网，但吞吐下降 | 可保持，依赖边界路由器稳定 | 通常断开常规连接，专用 DFU 服务 |
| 典型耗时 | 较慢，受 Mesh 跳数与分片影响 | 中等，取决于边界路由器带宽 | 较快，点对点带宽高 |
需要强调：Thread 协议栈本身不提供 OTA 传输层，实际项目里要么用 Matter OTA（基于 BDX 协议），要么自定义 CoAP 传输。选型时若只写“支持 Thread”，并不等于“支持 OTA”，必须确认上层是否有 OTA 方案。
三、存储布局与镜像大小约束
OTA 能否成功，本质是存储预算问题。以 EFR32MG24（1024 KB Flash）做 Zigbee 双区升级为例，一个合理的分区示例如下：
0x00000000 - 0x00003FFF Bootloader (16 KB)
0x00004000 - 0x0000BFFF 存储/NVM 区 (32 KB)
0x0000C000 - 0x0007BFFF 应用 Slot 0 (448 KB)
0x0007C000 - 0x000F3FFF 应用 Slot 1 (448 KB)
0x000F4000 - 0x000FFFFF 元数据/保留 (48 KB)
若应用编译后为 420 KB，双区方案刚好放得下；若涨到 470 KB，就必须改用单区升级或换 1536 KB 型号。判断依据很简单：应用镜像大小 × 2 + Bootloader + NVM + 元数据 ≤ Flash 总容量。单区方案则只需一份镜像加暂存区，但升级期间设备无法运行应用，适合可短暂停机的场景。
四、安全与回滚要求对选型的影响
如果产品要求“固件必须签名、升级失败可回滚”，选型必须满足：芯片带 Secure Vault、Bootloader 支持签名验证、存储布局预留两个 Slot。Silicon Labs 的 Gecko Bootloader 支持 ECDSA-P256 签名校验，公钥烧录在芯片内，升级镜像需带对应签名。若芯片无 Secure Vault，只能做 CRC 校验，无法防篡改。
回滚能力取决于是否保留旧镜像。双区方案天然支持回滚：新镜像写入 Slot 1，校验通过后切换启动标志；若启动失败，Bootloader 可切回 Slot 0。单区方案若要回滚，需额外保留一份旧镜像，实际又接近双区开销，因此对可靠性要求高的产品建议直接选双区。
五、选型决策路径
把上述因素串起来，可以得到一条清晰的判断链：先看协议栈是否自带 OTA 传输层，再看 Flash 是否够双区，最后看安全与回滚是否必须。下图给出这一决策关系。
六、选型依据小结
综合来看，选型可以按以下顺序判断：
- 协议栈优先：Zigbee 有标准 OTA Cluster，可直接用；Thread 需确认上层是否有 Matter OTA 或自定义方案；Bluetooth LE 用 Silabs DFU 或 L2CAP CoC，点对点最快。
- Flash 定单双区：应用镜像 × 2 + Bootloader + NVM ≤ Flash 才可双区。xG24 的 1024 KB 适合双区 Zigbee/Thread，512 KB 建议单区或 BLE 点对点。
- 安全定型号：需签名验证与安全启动，选带 Secure Vault 的 xG21/xG24；仅 CRC 校验可选更早代际。
- 回滚定布局：要求升级失败可恢复，必须双区并保留旧镜像；可接受停机重刷，单区即可。