2、基础知识：DFU（Device Firmware Update）概念、OTA（Over-The-Air）升级原理、BLE协议栈中的DFU角色
在嵌入式物联网产品开发中，固件升级能力已经从“可选功能”演变为“产品刚需”。无论是修复安全漏洞、优化功耗策略，还是为已出货设备增加新功能，DFU（Device Firmware Update，设备固件更新）都是产品全生命周期管理的关键环节。而OTA（Over-The-Air，空中升级）则让DFU摆脱了物理连接（如SWD调试器、USB线缆）的束缚，通过无线通信链路完成固件传输与更新。本章将系统梳理DFU的核心概念、OTA升级的完整链路，以及BLE协议栈中与DFU相关的角色分工，为后续实现nRF系列芯片的BLE OTA升级打下理论基础。
2.1 DFU 核心概念与设计动机
DFU（Device Firmware Update）是指在不更换硬件、不拆卸设备的前提下，通过特定通信接口对设备内部固件进行擦除、写入和校验的过程。在nRF系列芯片（如nRF52832、nRF52840）中，DFU通常由Bootloader（引导加载程序）和Application（应用固件）协同完成。Bootloader是芯片上电后最先执行的代码，它负责检查是否有新固件需要升级，若有则接收并写入固件，若无则跳转到应用代码执行。
DFU的设计动机主要来自三个维度：缺陷修复——产品发布后发现的软件Bug无法通过硬件改版解决，必须通过固件更新修复；功能迭代——通过OTA推送新算法、新协议或新UI，延长产品生命周期；安全合规——及时修补安全漏洞（如蓝牙协议栈漏洞），满足行业安全标准要求。对于nRF系列芯片，Nordic官方提供了完整的DFU解决方案，包括Secure DFU Bootloader、DFU Transport层（支持BLE、UART、USB等）以及nRF Connect SDK中的MCUboot引导程序。
2.2 OTA 升级原理与完整链路
OTA（Over-The-Air）升级是指通过无线通信技术（如BLE、Wi-Fi、蜂窝网络）完成固件传输和更新的过程。与有线DFU相比，OTA的核心优势在于无需物理接触设备，可以远程批量升级，特别适合已部署的物联网节点、可穿戴设备和智能家居产品。
一个完整的BLE OTA升级链路包含以下环节：
- 固件准备：将编译好的应用固件（.hex或.bin）打包为DFU升级包（通常为.zip格式），包含固件镜像、元数据（版本号、目标设备类型、硬件版本）和数字签名。
- 传输通道建立：设备通过BLE广播或已建立的GATT连接，与升级工具（手机App、网关或PC工具）建立通信。Nordic的DFU服务通常使用自定义GATT Service（如Nordic UART Service或DFU Service）。
- 分包传输：由于BLE单次通知（Notification）或写入（Write）的数据量受MTU限制（默认23字节，可协商至247字节），固件必须拆分为多个数据包依次发送。Nordic SDK中默认使用20字节的ATT payload，但通过Data Length Extension（DLE）和更大的MTU可以显著提升传输速率。
- 接收与校验：设备端每收到一个包，写入临时Flash区域（Bank 1），同时计算CRC32或SHA-256校验值。全部接收完成后，Bootloader对完整镜像进行签名验证和CRC校验。
- 激活与切换：校验通过后，Bootloader将新固件从Bank 1复制到Bank 0（或直接交换Flash映射），然后复位重启，执行新固件。若校验失败，则保留旧固件继续运行，实现自动回滚。
| 环节 | 关键参数/技术 | 典型值/方案 | 风险点 |
|---|---|---|---|
| 固件打包 | 压缩格式、签名算法 | ZIP + ECDSA P-256 | 签名密钥泄露 |
| BLE连接 | 连接间隔、从机延迟 | 7.5ms - 30ms | 连接中断导致传输失败 |
| 数据传输 | MTU大小、DLE | MTU 247 + DLE 251 | 吞吐量瓶颈 |
| Flash写入 | 页大小、擦写时间 | 4KB页，擦除约20ms | 写入中断导致Flash损坏 |
| 校验激活 | CRC32 / SHA-256 | 双Bank + 原子切换 | 校验失败需回滚 |
2.3 BLE 协议栈中的 DFU 角色
在BLE协议栈中，DFU功能涉及多个角色，理解这些角色有助于设计合理的升级架构。BLE协议栈自下而上分为物理层（PHY）、链路层（LL）、主机控制接口（HCI）、逻辑链路控制与适配协议（L2CAP）、属性协议（ATT）、通用属性规范（GATT）和通用访问规范（GAP）。DFU主要工作在GAP和GATT层。
GAP层角色：GAP定义了设备的四种角色——Broadcaster（仅广播）、Observer（仅扫描）、Central（中心设备，主动连接）、Peripheral（外围设备，被连接）。在DFU场景中，被升级设备通常作为Peripheral，升级工具（手机/网关）作为Central。但某些场景下（如nRF52840作为USB Dongle），设备也可以作为Central主动连接手机进行升级。
GATT层角色：GATT定义了Client（客户端，发起请求）和Server（服务端，响应请求）两种角色。在Nordic DFU实现中，被升级设备作为GATT Server，提供DFU Service（UUID: 0xFE59），包含多个Characteristic：
- DFU Control Point（写入）：接收升级命令（开始、暂停、取消、激活等）。
- DFU Packet（写入/通知）：传输固件数据包。
- DFU Version（读取）：获取当前DFU协议版本。
- DFU Status（通知）：上报升级状态（成功、错误码、进度）。
此外，BLE协议栈还涉及安全管理器（SM）角色，负责配对和密钥分发。在DFU过程中，建议启用加密连接（LESC配对）和绑定，防止恶意设备注入固件。Nordic的Secure DFU要求固件包必须使用私钥签名，设备端Bootloader内置公钥进行验证，任何未签名的固件都会被拒绝。
2.4 案例拆解：nRF52840 可穿戴设备的 BLE OTA 升级设计
下面通过一个实际案例来综合理解DFU概念、OTA链路和BLE角色。假设我们设计一款基于nRF52840的智能手环，需要支持通过手机App进行固件升级。
背景与约束：手环使用nRF52840芯片，Flash 1MB，RAM 256KB。当前应用固件大小为180KB，新版本固件为210KB。BLE连接参数为：连接间隔15ms，从机延迟0，MTU 247（通过DLE协商）。升级工具为iOS/Android手机App，使用Nordic DFU Library。
初始现象与目标：手环已出货5000台，需要修复一个蓝牙断连的Bug，并增加心率算法优化。目标是在不影响用户体验的前提下，在2分钟内完成升级，且升级失败率低于1%。
关键参数与设计决策：
| 设计项 | 参数/方案 | 说明 |
|---|---|---|
| Flash分区 | Bootloader 48KB + Bank0 400KB + Bank1 400KB + MBR 4KB | 双Bank方案，支持回滚 |
| MTU协商 | 请求MTU 247，实际协商为247 | 单包可传244字节数据 |
| 传输速率 | 理论吞吐量约 244B × 100包/s ≈ 24KB/s | 实际约18-20KB/s（含协议开销） |
| 固件签名 | ECDSA P-256，私钥保存在CI服务器 | 防止固件被篡改 |
| 升级包大小 | 210KB固件压缩后约150KB | ZIP压缩，含元数据 |
实际操作步骤：
- 在CI服务器上编译新固件，使用私钥签名并打包为
dfu_package.zip。 - 手机App扫描到手环，建立BLE连接并配对（LESC）。
- App写入DFU Control Point，发送“开始DFU”命令，携带固件大小和CRC种子。
- App将固件分包（每包244字节）写入DFU Packet Characteristic，手环每收到一包写入Bank 1 Flash。
- 全部发送完成后，App发送“校验”命令，手环计算SHA-256并与App端对比。
- 校验通过后，App发送“激活”命令，手环Bootloader将Bank 1内容复制到Bank 0，复位执行新固件。
- 手环重启后，App读取DFU Version确认升级成功。
结果与复盘：实测升级耗时约95秒（150KB / 18KB/s + 校验和重启时间），失败率0.6%。失败原因主要为：用户在升级过程中远离手机导致BLE断连（0.4%），以及Flash写入异常（0.2%）。通过增加断点续传（记录已接收包序号）和Flash写入重试机制，失败率降至0.2%。
2.5 常见误区与总结复盘
在DFU/OTA设计实践中，工程师常犯以下错误：
- 误区一：忽略MTU协商——默认MTU 23字节时，传输速率仅约1.2KB/s，升级210KB固件需要近3分钟，用户体验极差。应主动协商MTU至247并启用DLE。
- 误区二：不做固件签名——未签名的DFU包可被中间人攻击替换，导致设备被植入恶意代码。Nordic Secure DFU强制要求签名验证。
- 误区三：单Bank方案——直接在Bank 0上擦写，一旦写入失败，设备无法启动。必须使用双Bank方案或至少保留一个可引导的备份。
- 误区四：忽略Flash磨损——频繁DFU会消耗Flash擦写寿命（nRF52为10,000次）。对于高频升级场景，应使用磨损均衡算法或减少升级频率。
- 误区五：升级过程中不处理连接参数——DFU传输需要较高的吞吐量，应临时调整连接间隔和从机延迟，升级完成后恢复默认参数。
总结复盘：DFU/OTA设计是一个系统工程，涉及固件打包、传输协议、Flash管理、安全认证和异常恢复等多个层面。对于nRF系列芯片，Nordic提供了成熟的Secure DFU Bootloader和nRF Connect SDK中的MCUboot方案，开发者应优先复用官方方案，将精力集中在应用层升级策略（如升级时机、断点续传、用户提示）上。同时，务必在开发阶段就建立完整的升级测试矩阵，包括弱信号环境、低电量、频繁中断等极端场景，确保升级功能的可靠性。