Matter 设备固件升级实战：nRF Connect 示例的 OTA/DFU 完整操作指南

Matter 设备固件升级实战nRF Connect 示例的 OTA/DFU 完整操作指南【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip导读本指南围绕 Nordic Semiconductor 开发套件nRF52 系列与 nRF5340 DK上运行的 Matter原 Project CHIP示例完整讲解两类设备固件升级DFU方案基于 Matter 标准 OTA 协议的无线升级以及基于 Zephyr Simple Management ProtocolSMP的蓝牙低功耗BLE升级。读完本文你将掌握从构建 OTA Provider、配网、配置访问控制列表ACL到触发 OTA 查询的完整 Matter DFU 流程也能独立使用手机 App 或 PC 端 mcumgr 命令行工具完成 BLE 固件烧写、镜像槽位管理与设备复位并理解 MCUboot 双槽镜像机制背后的运行逻辑。一、两种 DFU 路径概览nRF Connect 平台上部分 Matter 示例支持通过以下两种协议之一完成空中固件升级Matter 合规 OTA 更新协议设备通过 Matter 运营网络查询并下载新固件镜像属于 Matter 规范定义的标准能力基于 BLE 的 Simple Management ProtocolSMP可选用智能手机 App 或 PC 命令行工具执行 DFU。需要说明的是该协议不属于 Matter 规范范畴是 Zephyr 生态的设备管理协议。两种方案互不冲突Matter OTA 面向标准 Matter 网络场景BLE SMP 则适合本地、近距离、不依赖 Thread/边界路由器的快速更新场景。二、基于 Matter 的固件升级DFU over Matter2.1 前置条件OpenThread Border RouterDFU over Matter 的完整流程要求设备通过 Thread 网络与 OTA Provider 通信因此必须先部署 OpenThread Border RouterOTBR可采用 Docker 容器或树莓派Raspberry Pi两种方式。搭建树莓派版 OTBR 的具体步骤参见 Setup OpenThread Border Router on Raspberry Pi。OTBR 同时承担 Thread 网络组建与 Active Operational Dataset 生成的任务是后续配网命令的参数来源。2.2 两种节点角色OTA Provider响应 OTA Requestor 的软件更新查询并向其提供更新包。本文流程中由一台 Linux 主机上的应用承担此角色OTA Requestor任何需要被更新、且能主动与 OTA Provider 通信以获取固件的节点。本文流程中由 Nordic 开发板上的示例充当此角色。2.3 构建 OTA Provider 与 chip-tool在 CHIP 根目录下依次执行以下命令# 构建 OTA Provider Linux 应用禁用 BLE 网络层 scripts/examples/gn_build_example.sh examples/ota-provider-app/linux out/provider chip_config_network_layer_blefalse # 构建 chip-tool 控制器 scripts/examples/gn_build_example.sh examples/chip-tool out/chiptool chip_mdnsplatform其中chip_config_network_layer_blefalse关闭 OTA Provider 的 BLE 网络层使其仅通过 IP 网络参与 Matter 通信chip_mdnsplatform让 chip-tool 使用平台 mDNS 实现服务发现这是 Linux 主机参与 Matter 网络时的常见配置。2.4 启动 OTA Provider 并提供固件OTA 固件镜像默认名称为matter.ota在示例构建目录中自动生成。用-f参数指定该文件路径启动 Providerout/provider/chip-ota-provider-app -f matter.ota启动后保持该终端运行其余操作在另一个终端中完成。2.5 配网将 Provider 与设备接入同一 Matter 网络步骤 1配网 OTA ProviderNode ID 1./out/chiptool/chip-tool pairing onnetwork 1 2020202120202021是默认配对码PASE verifier 对应的 setup passcode。Provider 通过 on-network 方式直接加入 Matter 网络。步骤 2组建 Thread 网络通过 OTBR 的 Web 界面使用默认网络参数组建一个新的 Thread 网络。步骤 3配网 Matter 设备Node ID 2./out/chiptool/chip-tool pairing ble-thread 2 hex:000300000f02081111111122222222051000112233445566778899aabbccddeeff01021234 20202021 3840hex:前缀后的参数是 Thread 网络的 Active Operational Dataset。若组建网络时修改过默认参数需从 OTBR 重新获取该数据集。3840是 Nordic 示例使用的 BLE 配网端点endpointID。2.6 写入默认 OTA Provider 配置通过 OTA Software Update Requestor 集群的DefaultOTAProvider属性告知设备应向哪个节点查询更新./out/chiptool/chip-tool otasoftwareupdaterequestor write default-otaproviders [{fabricIndex: 1, providerNodeID: 1, endpoint: 0}] 2 0该命令的最后两个参数分别是 Requestor 节点 ID2与 Requestor 端点 ID0。fabricIndex指明该配置所属的 FabricproviderNodeID指向 OTA Provider 节点endpoint指向 Provider 上提供 OTA 服务的端点。从实现看DefaultOTAProvider属性在 OTARequestorAttributes.cpp 中作为 OTA Software Update Requestor 集群的只写属性被持久化Requestor 在启动或收到查询触发时会读取该配置定位 Provider。2.7 为 OTA Provider 配置访问控制ACL为保证网络中的节点能向 OTA Provider 发送集群命令需要为 Provider 写入访问控制列表授予Operate权限./out/chiptool/chip-tool accesscontrol write acl [{fabricIndex: 1, privilege: 5, authMode: 2, subjects: [112233], targets: null}, {fabricIndex: 1, privilege: 3, authMode: 2, subjects: null, targets: null}] 1 0该 ACL 包含两条规则第一条将Operate权限privilege: 5授予指定主题节点 112233第二条将Manage权限privilege: 3授予 Fabric 内所有节点subjects: null。这样 OTA Requestor 才能合法地向 Provider 的 OTA Software Update Provider 集群发送命令。2.8 触发 DFU 的两种方式方式一设备 Shell 触发需在编译时启用 Matter Shell构建固件时加入-DCONFIG_CHIP_LIB_SHELLy选项即可启用 Matter shell 命令。随后在设备串口 shell 中执行matter ota query方式二chip-tool 发送 Announce OTA Provider 命令./out/chiptool/chip-tool otasoftwareupdaterequestor announce-otaprovider 1 0 0 0 2 0参数依次为Provider 节点 ID1、Provider 厂商 ID0、公告原因 Announcement Reason0、Provider 端点 ID0、Requestor 节点 ID2、Requestor 端点 ID0。设备一旦获知 OTA Provider 的存在便会自动向 Provider 发起固件镜像查询并下载。从源码层面看AnnounceOTAProvider命令在 OTARequestorCluster.cpp 中由OtaSoftwareUpdateRequestor::Commands::AnnounceOTAProvider::Id分支解包并交由HandleAnnounceOTAProvider处理它会校验请求者的操作权限将 Provider 信息写入 Requestor 驱动从而触发后续的 QueryImage、BDX 镜像下载与 ApplyUpdate 交互序列。当固件镜像下载完成后设备会自动重启以应用更新。整个升级状态机Query Image → Download → Apply → Confirm由src/app/clusters/ota-requestor/目录下的DefaultOTARequestor、DefaultOTARequestorDriver等类协同驱动可结合 DefaultOTARequestor.cpp 与 DefaultOTARequestorDriver.cpp 深入阅读。三、基于 BLE 的固件升级智能手机方式3.1 操作步骤在手机上安装 nRF Connect Device Manager 应用按下设备上对应的按键启用软件更新功能若默认未启用并开始广播 SMP 服务的 BLE 广告具体按键号见各示例文档的用户界面User Interface章节再次按下对应按键启动 BLE 广播参照 FOTA 更新页面将新镜像下载到 nRF52 系列设备或 nRF5340 DK。3.2 适用说明该方式适合快速的手工验证。其底层同样走 SMP 的镜像管理通道与下文 PC 命令行方式共享同一套镜像槽位机制只是将image upload等操作封装在手机图形界面中。四、基于 BLE 的固件升级mcumgr 命令行方式4.1 工具与平台限制mcumgr 是 Zephyr 官方提供的设备管理命令行工具支持通过 BLE 传输镜像。使用前需注意平台限制mcumgr 的 BLE 连接能力目前仅支持 Linux 与 macOSWindows 暂不支持 BLE DFU适配器问题在 Linux 上使用内置蓝牙适配器时可能无法连接 nRF 设备。此时可借助 Zephyr 的 Bluetooth HCI USB 示例将其烧写到 Nordic 开发板上充当外部 BLE 适配器。例如为 nRF52840 DK 构建该示例cd zephyr/samples/bluetooth/hci_usb west build -b nrf52840dk_nrf52840 -- -DCONFIG_BT_LL_SW_SPLITy4.2 统一命令约定后续所有命令中请将ble-hci-number替换为蓝牙 HCI 接口编号例如0将ble-device-name替换为设备通过 BLE 广播的 Matter 设备名例如MatterLock。4.3 安装与准备按照 mcumgr 命令行工具安装说明完成工具安装按下设备对应按键启用软件更新功能若默认未启用并开始广播 SMP 服务观察设备上的 LED 短闪表示 BLE 广播已启动LED 编号见示例文档的用户界面章节。4.4 上传应用固件镜像在示例目录下执行将application_name替换为应用名例如locksudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_nameble-device-name image upload build/application_name/zephyr/zephyr.signed.bin -n 0 -w 1-n 0指定写入 image 0应用镜像-w 1请求远端确认ack每个数据块保证传输可靠性zephyr.signed.bin是经 MCUboot 签名过的镜像位于示例的 Zephyr 构建产物目录。上传可能耗时数分钟请等待进度条达到 100%。4.5 查看设备镜像列表sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_nameble-device-name image list输出示例槽位状态分析Images: image0 slot0 version: 0.0.0 bootable: true flags: active confirmed hash: 7bb0e909a846e833465cbb44c581cf045413a5446c6953a30a3dcc2c3ad51764 image0 slot1 version: 0.0.0 bootable: true flags: hash: cbd58fc3821e749d3abfb00b3069f98c078824735f1b2a333e8a1579971e7de1 Split status: N/A (0)可见 slot 0 中为当前活跃且已确认active confirmed的旧镜像slot 1 中为新上传但尚未激活的镜像flags为空。这正是 MCUboot 双槽primary/secondary机制的直观体现。4.6 测试切换镜像sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_nameble-device-name image test image-hash将image-hash替换为 slot 1 镜像的哈希例如cbd58fc3821e749d3abfb00b3069f98c078824735f1b2a333e8a1579971e7de1。执行后再次查看列表slot 1 的flags变为pending表示该镜像将在下次启动时被尝试引导Images: image0 slot0 version: 0.0.0 bootable: true flags: active confirmed hash: 7bb0e909a846e833465cbb44c581cf045413a5446c6953a30a3dcc2c3ad51764 image0 slot1 version: 0.0.0 bootable: true flags: pending hash: cbd58fc3821e749d3abfb00b3069f98c078824735f1b2a333e8a1579971e7de1 Split status: N/A (0)4.7 nRF5340 DK 多镜像设备的特殊处理nRF5340 DK 支持多镜像 DFU应用核 网络核除应用镜像外还需单独更新网络核固件a. 上传网络核固件sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_nameble-device-name image upload build/signed_by_mcuboot_and_b0_network_image_name.bin -n 1 -w 1将network_image_name替换为网络镜像名例如ipc_radio-n 1指定写入 image 1网络核镜像。b. 查看镜像列表sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_nameble-device-name image list输出中应同时包含活跃的旧应用镜像image 0 slot 0、处于pending的新应用镜像image 0 slot 1以及尚未激活的新网络镜像image 1 slot 1flags为空Images: image0 slot0 version: 0.0.0 bootable: true flags: active confirmed hash: 7bb0e909a846e833465cbb44c581cf045413a5446c6953a30a3dcc2c3ad51764 image0 slot1 version: 0.0.0 bootable: true flags: pending hash: cbd58fc3821e749d3abfb00b3069f98c078824735f1b2a333e8a1579971e7de1 image1 slot1 version: 0.0.0 bootable: true flags: hash: d9e31e73cb7a959c26411250c2b3028f3510ae88a4549ae3f2f097c3e7530f48 Split status: N/A (0)c. 测试切换网络镜像sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_nameble-device-name image test image-hash将image-hash替换为网络镜像的哈希例如d9e31e73cb7a959c26411250c2b3028f3510ae88a4549ae3f2f097c3e7530f48随后 image 1 slot 1 的flags变为pending。4.8 复位设备以完成交换sudo mcumgr --conntype ble --hci ble-hci-number --connstring peer_nameble-device-name reset设备复位后控制台会输出 bootloader 日志典型内容如下*** Booting Zephyr OS build zephyr-v2.5.0-1101-ga9d3aef65424 *** I: Starting bootloader I: Primary image: magicgood, swap_type0x2, copy_done0x1, image_ok0x1 I: Secondary image: magicgood, swap_type0x2, copy_done0x3, image_ok0x3 I: Boot source: none I: Swap type: test其中Swap type: test表明 MCUboot 正在执行测试交换test swap即把 slot 1 的镜像交换到 slot 0 并尝试引导。交换过程可能持续一段时间完成后新固件即被启动。若需深入了解 mcumgr 支持的全部镜像管理命令可查阅 mcumgr 镜像管理文档对应章节。五、方案对比与选型建议维度DFU over MatterDFU over BLESMP协议归属Matter 规范标准 OTA 协议Zephyr SMP非 Matter 规范网络依赖需 Matter 运营网络本文为 Thread OTBR仅需 BLE 连接触发方式OTA Provider 发现 自动查询手机 App / mcumgr 手动操作使用场景标准 Matter 生态远程升级、大规模部署本地近距离快速调试与单台升级平台限制依赖 OTBR 环境mcumgr BLE 仅支持 Linux/macOS实际工程中两者可互补开发阶段用 BLE 方式快速迭代固件产品化阶段则通过 Matter OTA 实现符合规范的远程更新。两种路径的固件产物matter.ota与zephyr.signed.bin都由构建系统自动生成升级过程的镜像管理则统一交由 MCUboot 双槽机制保障具备断电恢复与回滚能力。六、延伸阅读本指南对应的原始文档位于 nrfconnect_examples_software_update.mdnRF 平台整体介绍见 nrfconnect_platform_overview.md想要深入 OTA 客户端实现可从 src/app/clusters/ota-requestor/ 目录入手重点阅读DefaultOTARequestor.cpp、DefaultOTARequestorDriver.cpp与OTARequestorCluster.cpp以及其测试用例 TestOTARequestorCluster.cppOTA Requestor 应用参考实现位于 examples/ota-requestor-appLinux 构建配置见 examples/ota-requestor-app/linux/BUILD.gn通用构建脚本 scripts/examples/gn_build_example.sh 与 docs/guides/BUILDING.md 提供了示例构建与环境的更多细节。【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考