Matter OTA 软件更新实战指南：NXP RT 系列示例应用（RW61x / RT1060 / RT1170）

Matter OTA 软件更新实战指南NXP RT 系列示例应用RW61x / RT1060 / RT1170【免费下载链接】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导读本文面向在 NXP RT 系列开发板上运行 Matter 示例应用的开发者系统讲解基于 MCUBoot 引导加载器与 OTA Provider 的端到端软件升级流程。你将掌握 NXP RT 平台的 Flash 分区布局、MCUBoot 的生成与烧录、签名应用镜像的制作、OTA 更新镜像的封装含加密选项以及如何借助 chip-tool 在真实设备上完成一次完整的 OTA 软件更新。全文以 all-clusters 示例应用为贯穿案例并补充 connectedhomeip 仓库中 OTA 实现源码层面的原理印证帮助你从按步骤能跑通进阶到理解底层机制。OTA 软件更新流程概览OTAOver-The-Air软件更新是 Matter 设备远程维护的核心能力。在 NXP RT 平台上OTA Requestor 特性使设备能够被告知、下载并应用来自 OTA Provider 的软件更新。整个更新过程按如下步骤进行查询与应答OTA Requestor 向 OTA Provider 查询更新镜像OTA Provider 根据镜像可用性做出响应分块下载与存储更新镜像以块block为单位被接收并写入设备的外部 Flash通知引导加载器并重启镜像完整下载后引导加载器Bootloader收到通知设备复位并以测试模式test-mode应用更新确认或回滚如果测试成功更新被永久应用否则引导加载器回退到主应用primary application防止任何降级风险。该流程的 OTA 实现细节可在 src/platform/nxp/common/ota/README.md 中查看NXP 平台将 OTA 处理委托给OTATlvProcessor派生类实例由OTAImageProcessorImpl统一管理。平台支持范围本文档对应的 NXP RT 平台与板级支持如下RW61x 指南对应rdrw612bga/frdmrw612开发板RT1060_EVK-C 指南对应evkcmimxrt1060开发板RT1170_EVK-B 指南对应evkbmimxrt1170开发板Flash 内存布局RT 系列设备的 Flash 被划分为不同区域Bootloader 区MCUBoot 位于 Flash 基址basePrimary application partition主应用分区引导加载器运行的活动应用所在分区默认预留4.4 MBSecondary application partition次应用分区通过 OTA 接收的候选更新镜像所在分区同样默认预留4.4 MB。几点需要注意对于 RW61xCPU1/CPU2 的固件被嵌入在 CPU3 的示例应用中主、次应用分区的大小只是示例值当前各预留 4.4 MB。如需调整可通过修改应用链接脚本linker script中的m_app_max_sectors值来改变分区大小。在 CMake 构建下MCUBoot 分区地址定义于third_party/nxp/nxp_matter_support/cmake/rt/rt_platform/bootloader.conf若手工生成 MCUBoot则需要同步修改 SDK 中的flash_partitioning.h。分区的详细说明可参考 MCUX SDK 中examples/ota_examples/mcuboot_opensource目录下的readme.txt。MCUBoot 引导加载器MCUBoot 是一个开源的安全引导加载器NXP RT 平台使用它来执行自升级self-upgrade。对于 RT 平台引导加载器默认配置为使用Flash 重映射机制flash remapping执行镜像升级即采用MCUBoot DIRECT-XIP升级模式。DIRECT-XIP 模式的核心价值在于更新后的镜像从次分区直接执行无需进行耗时且占用额外空间的镜像交换swap配合 Flash 重映射让主分区与次分区在地址上互换从而实现快速启动与可靠回滚。构建启用 OTA 的 RT 示例应用重要说明使用 CMake 构建系统构建 NXP Matter 示例时只要启用了 OTA SUSoftware Updatemcuboot二进制、签名应用镜像以及.ota文件都会自动生成。自动生成逻辑位于third_party/nxp/nxp_matter_support/cmake/build_helpers.cmake因此可以跳过下文手工生成镜像的章节。若要从零开始构建启用 OTA 的示例请参照平台专属文档的Building小节NXP FreeRTOS 示例平台指南。默认情况下软件版本software version为 1若要以软件版本 2 构建可使用带v2后缀的prj_custom.conf配置文件。各构建系统下产物的默认路径产物路径MCUBoot 二进制build_dir/modules/chip/mcuboot/.elf与.bin两种格式签名应用镜像build_dir/app_SIGNED.binOTA 更新镜像build_dir/app.ota生成与烧录 MCUBoot 引导加载器手工生成 MCUBoot注对于 CMake 生成的应用本节可跳过自动生成的 MCUBoot 二进制位于build_dir/modules/chip/mcuboot/。使用已安装的 NXP MCUX SDK 手工构建 MCUBoot 的步骤如下定位 MCUX SDK 目录userubuntu: cd ~/Desktop/connectedhomeip/third_party/nxp/nxp_matter_support/github_sdk/sdk_next/repo/mcuxsdk导出 ARM GCC 工具链ARMGCC_DIR需指向 SDK 推荐的编译器路径userubuntu: export ARMGCC_DIR # 填入 SDK 推荐的编译器路径在 MCUX SDK 根目录使用west build构建mcuboot示例userubuntu: west build -d mcuboot_build -b RT_board examples/ota_examples/mcuboot_opensource -DCONF_FILEabsolute_path/connectedhomeip/third_party/nxp/nxp_matter_support/cmake/rt/RT_platform/bootloader.conf注对于 RT1170 平台需要在上面的构建命令行中额外添加-Dcore_idcm7参数。其中RT_board按目标板替换为RW61x 平台rdrw612bga或frdmrw612取决于目标开发板RT1170-EVKBevkbmimxrt1170RT1060-EVKCevkcmimxrt1060。构建完成后MCUBoot 二进制位于 SDK 根目录下的mcuboot_build文件夹中。烧录 MCUBoot 引导加载器设备要执行软件更新必须先将 MCUBoot 引导加载器烧录到 Flash 基址。推荐步骤如下擦除外部 Flash可使用 Segger 的 JLink命令行启动JLink连接并选择目标器件后擦除 FlashJ-Link connect Device ? # 弹窗选择器件RW61x 选 RW612RT1060 选 MIMXRT1062XXX6BRT1170 选 MIMXRT1176xxxA_M7 Please specify target interface: J) JTAG (Default) S) SWD T) cJTAG TIF S Specify target interface speed [kHz]. Default: 4000 kHz Speed # enterJ-Link exec EnableEraseAllFlashBanks按平台擦除对应 Flash 地址区间RW61xJ-Link erase 0x8000000, 0x88a0000RT1060-EVK-CJ-Link erase 0x60000000, 0x61000000RT1170-EVK-BJ-Link erase 0x30000000, 0x34000000烧录生成的二进制J-Link loadfile path_to_mcuboot/mcuboot_opensource.elf验证启动若烧录成功终端将显示如下日志hello sbl. Disabling flash remapping function Bootloader Version 2.0.0 Image 0 Primary slot: Image not found Image 0 Secondary slot: Image not found No slot to load for image 0 Unable to find bootable image注默认情况下mcuboot 认为主、次分区均为 4.4 MB。若要更改分区大小CMake 构建下修改third_party/nxp/nxp_matter_support/cmake/rt/rt_platform/bootloader.conf手工生成时则同步修改flash_partitioning.h。关于 MCUBoot 的 Flash 分区更多信息可参考 MCUX SDK 中examples/ota_examples/mcuboot_opensource下的readme.txt。生成与烧录签名应用镜像签名算法兼容性从 MCUBoot v2.2 起默认签名算法为EC256。Matter 镜像现在默认使用ECDSA签名。为兼容更早版本2.2 之前默认使用 RSA的 MCUBoot仓库同时提供 RSA 签名镜像路径为build_dir/app_SIGNED_RSA.bin。烧录引导加载器后即可将应用烧录到开发板。应用镜像必须符合以下格式Header头部包含镜像的通用信息版本、大小、magic 等应用代码生成的二进制Trailer尾部包含引导加载器所需的元数据如镜像签名、升级类型upgrade type、交换状态swap status等。将 GN 构建产物转换为裸二进制对于 GN 构建系统生成的应用可执行文件位于out/release/chip-board-all-cluster-example其中board为RW61x 用rw61xRT1060-EVK-C 用rt1060RT1170-EVK-B 用rt1170需先转换为裸二进制格式arm-none-eabi-objcopy -R .flash_config -R .NVM -O binary chip-board-all-cluster-example chip-board-all-cluster-example.bin应用会被自动链接为从主镜像分区执行并考虑 mcuboot 强加的偏移offset。使用 imgtool 签名SDK 提供了imgtool工具位于matter_repo_root/third_party/nxp/nxp_matter_support/github_sdk/sdk_next/repo/mcuxsdk/middleware/mcuboot_opensource/scripts/首先切换到该脚本目录cd ~/Desktop/matter_repo_root/third_party/nxp/nxp_matter_support/github_sdk/sdk_next/repo/mcuxsdk/middleware/mcuboot_opensource/scripts/然后执行以下签名命令之一请将/path/to/file/binary替换为实际文件路径ECDSA 签名适用于 MCUBoot 版本 2.2python3 imgtool.py sign \ --key ~/Desktop/matter_repo_root/third_party/nxp/nxp_matter_support/github_sdk/sdk_next/repo/mcuxsdk/middleware/mcuboot_opensource/boot/nxp_mcux_sdk/keys/sign-ecdsa-p256-priv.pem \ --align 4 \ --header-size 0x1000 \ --pad-header \ --pad \ --confirm \ --slot-size 0x440000 \ --max-sectors 1088 \ --version 1.0 \ ~/Desktop/connectedhomeip/examples/all-clusters-app/nxp/rt/rt_board/out/debug/chip-rt_board-all-cluster-example.bin \ ~/Desktop/connectedhomeip/examples/all-clusters-app/nxp/rt/rt_board/out/debug/chip-rt_board-all-cluster-example_SIGNED.binRSA 签名适用于 MCUBoot 版本 2.2python3 imgtool.py sign \ --key ~/Desktop/matter_repo_root/third_party/nxp/nxp_matter_support/github_sdk/sdk_next/repo/mcuxsdk/middleware/mcuboot_opensource/boot/nxp_mcux_sdk/keys/sign-rsa2048-priv.pem \ --align 4 \ --header-size 0x1000 \ --pad-header \ --pad \ --confirm \ --slot-size 0x440000 \ --max-sectors 1088 \ --version 1.0 \ ~/Desktop/connectedhomeip/examples/all-clusters-app/nxp/rt/rt_board/out/debug/chip-rt_board-all-cluster-example.bin \ ~/Desktop/connectedhomeip/examples/all-clusters-app/nxp/rt/rt_board/out/debug/chip-rt_board-all-cluster-example_SIGNED.bin命令参数说明--slot-size与--max-sectors必须与主/次应用分区大小对齐默认每个应用按 4.4 MB 计算。若修改了分区大小这两个参数需同步调整示例使用 SDK 提供的示例私钥sign-ecdsa-p256-priv.pemMCUBoot 使用对应的公钥验证镜像完整性。生产环境建议生成新的密钥对且应在构建 mcuboot 应用之前完成。生成新密钥对的命令生成 ECDSA 私钥userubuntu: python3 imgtool.py keygen -k priv_key.pem -t ecdsa-p256提取公钥userubuntu: python3 imgtool.py getpub -k priv_key.pem将提取的公钥复制到sign-ecdsa-p256-pub.c中作为ecdsa_pub_key[]数组的值。注若要生成 RSA 密钥将类型ecdsa-p256替换为rsa-2048并将公钥写入sign-rsa2048-pub.c文件的rsa_pub_key[]数组。最终输出即为软件版本 1.0 的签名二进制。烧录签名应用镜像使用 JLink 将签名应用烧录到对应地址RW61xJ-Link loadbin application_SIGNED.bin 0x8020000RT1060-EVK-CJ-Link loadbin application_SIGNED.bin 0x60040000RT1170-EVK-BJ-Link loadbin application_SIGNED.bin 0x30040000烧录完成后引导加载器应能直接跳转到应用起始地址并运行应用。生成 OTA 更新镜像从签名二进制生成 .ota 文件生成 OTA 更新镜像时复用上一节的签名流程但需要注意两点变化将--version 1.0替换为--version 2.0即更新的版本号去掉--pad与--confirm参数。注构建更新镜像时可通过 GN 构建参数nxp_software_version2与nxp_software_version_string2.0指定升级版本CMake 构建则在命令行添加-DCONFIG_CHIP_DEVICE_SOFTWARE_VERSION2与-DCONFIG_CHIP_DEVICE_SOFTWARE_VERSION_STRING2.0或直接使用prj_*_v2.conf配置文件。关键约束要保证 OTA 流程正确OTA header 中的版本必须与二进制内嵌的软件版本一致。生成签名更新二进制后需将其转换为 OTA 格式。仓库提供了scripts/tools/nxp/ota/ota_image_tool.py它是标准工具 src/app/ota_image_tool.py 的 NXP 封装生成的 OTA 镜像格式如下| OTA image header | TLV1 | TLV2 | ... | TLVn |其中每个 TLV 的形式为|tag|length|value|。注意这里使用的是标准 TLV 格式Matter TLV 格式仅用于 factory data工厂数据的 TLV value。更多脚本说明与支持的参数请参考 OTA image tool 指南。生成.ota文件的示例命令userubuntu:~/connectedhomeip$ : ./scripts/tools/nxp/ota/ota_image_tool.py create -v 0xDEAD -p 0xBEEF -vn 2 -vs 2.0 -da sha256 --app-input-file chip-rt_board-all-cluster-example_SIGNED.bin chip-rw61x-all-cluster-example.ota该命令的参数含义-v 0xDEAD/-p 0xBEEF为 OTA header 中的厂商 IDVendor ID与产品 IDProduct ID-vn 2为镜像版本号-vs 2.0为版本字符串-da sha256指定摘要算法--app-input-file指定应用二进制输入。ota_image_tool.py还支持更丰富的自定义选项包括应用描述符--app-version、--app-version-str、--app-build-date、SSBL--bl-*、工厂数据--factory-data、--cert_declaration、--dac_cert、--dac_key、--pai_cert以及通过--json指定遵循ota_payload.schema的自定义 TLV 描述文件详情见 OTA image tool 指南。OTA 镜像加密如需对 OTA 更新镜像启用加密可在ota_image_tool.py命令中添加--enc_enable与--input_ota_key aes_128_key参数将aes_128_key替换为 AES-128 加密密钥从而生成加密的.ota文件。同时应用端也必须启用加密才能成功处理更新镜像GN 构建在gn gen参数中添加chip_with_ota_encryptiontrue和chip_with_ota_keyaes_128_keyCMake 构建在west build命令行添加 Kconfig 选项-DCONFIG_CHIP_OTA_ENCRYPTIONy和-DCONFIG_CHIP_OTA_ENCRYPTION_KEYaes_128_key。关键约束应用构建时使用的aes_128_key必须与生成.ota文件时使用的密钥完全一致。注对于 CMake 生成的应用若构建配置启用了CONFIG_CHIP_OTA_ENCRYPTIONyKconfig则自动生成的.ota文件会使用指定密钥加密。执行 OTA 软件更新环境搭建示例环境组成chip-tool 应用运行在树莓派RPi上OTA Provider 应用构建在同一台 RPi 上构建方法如下RT 开发板烧录了示例应用按上文步骤。构建并启动 OTA Provider在 RPi 上构建 Linux OTA Provider 应用若预装应用中不存在userubuntu:~/connectedhomeip$ : ./scripts/examples/gn_build_example.sh examples/ota-provider-app/linux out/ota-provider-app chip_config_network_layer_blefalse userubuntu:~/connectedhomeip$ : rm -rf /tmp/chip_*启动 OTA Provider 并指定更新镜像文件userubuntu:~/connectedhomeip$ : ./out/ota-provider-app/chip-ota-provider-app -f chip-rt_board-all-cluster-example.ota配网与 ACL 授权首先用 chip-tool 对 OTA Provider 进行配网分配节点 ID 1并授予 ACL 条目userubuntu:~/connectedhomeip$ : ./out/chip-tool-app/chip-tool pairing onnetwork 1 20202021 userubuntu:~/connectedhomeip$ : ./out/chip-tool-app/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第二步是对设备进行配网节点 ID 2使用 ble-wifi 或 ble-thread 方式例如userubuntu:~/connectedhomeip$ : ./out/chip-tool-app/chip-tool pairing ble-wifi 2 WIFI_SSID WIFI_PASSWORD 20202021 3840发起 OTA 流程配网完成后使用 chip-tool 的announce-otaprovider命令发起 OTA 流程。命令中的数字依次对应[ProviderNodeId][vendorid] [AnnouncementReason][endpoint] [node-id][endpoint-id]userubuntu:~/connectedhomeip$ : ./out/chip-tool-app/chip-tool otasoftwareupdaterequestor announce-otaprovider 1 0 0 0 2 0当完整更新镜像被下载并存储后引导加载器会收到通知设备将携带更新镜像重启。源码级原理解读多镜像 OTA 处理架构NXP RT 平台的 OTA 能力并不仅限于下载后整体刷写。从 src/platform/nxp/common/ota/ 目录的源码可以看到一套可扩展的多镜像 TLV 处理架构它也是理解上文.ota文件 TLV 格式在设备端如何被消费的关键。核心组件为OTAImageProcessorImpl它注册并管理若干OTATlvProcessor派生类实例负责在 BDX 传输的多个块之间选择正确的处理器直至完整 TLV 传输完毕。默认实现的处理器包括OTAFirmwareProcessor负责应用/SSBL二级引导加载器更新默认启用OTAFactoryDataProcessor负责工厂数据更新默认禁用需在构建参数中指定nxp_use_factory_datatrue与nxp_enable_ota_factory_data_processortrue才启用。OTATlvProcessor的抽象接口精简版如下class OTATlvProcessor { public: virtual CHIP_ERROR Init() 0; virtual CHIP_ERROR Clear() 0; virtual CHIP_ERROR ApplyAction() 0; virtual CHIP_ERROR AbortAction() 0; virtual CHIP_ERROR ExitAction(); CHIP_ERROR Process(ByteSpan block); void RegisterDescriptorCallback(ProcessDescriptor callback); protected: virtual CHIP_ERROR ProcessInternal(ByteSpan block) 0; };各接口的职责详见 src/platform/nxp/common/ota/README.mdInit处理器被选中时调用Clear发生中止或 apply 动作完成后调用ApplyAction在OTAImageProcessorImpl::HandleApply中调用发生在开发板复位之前AbortAction在OTAImageProcessorImpl::HandleAbort中调用处理器应在此重置状态ExitAction可选在数据全部传输完成后、HandleApply调用之前执行动作适用于单个 OTA 流程中传输多个 TLV 的场景ProcessOTAImageProcessorImpl内部处理数据的公开 API是对ProcessInternal的封装后者可返回CHIP_OTA_CHANGE_PROCESSOR通知选择新处理器处理剩余数据ProcessInternal的返回值语义CHIP_NO_ERROR表示块处理成功CHIP_ERROR_BUFFER_TOO_SMALL表示当前块未包含全部必要数据例如 TLV value 字段跨两个块CHIP_OTA_FETCH_ALREADY_SCHEDULED表示块处理成功且抓取已由处理器调度默认应用处理器即通过回调在外部 Flash 擦除完成后调度下一次数据抓取。此外OTADataAccumulator辅助类可用于将数据累积到指定阈值适合自定义负载中需要解析元数据的场景如自定义头部解码累积未达阈值时可返回CHIP_ERROR_BUFFER_TOO_SMALL请求更多数据。这一架构意味着应用可以定义自己的 TLV 处理器以扩展默认 OTA 功能也可以选择禁用默认处理器。若 OTA 镜像中包含多个 TLV每个 TLV 的动作按顺序执行任一动作失败则剩余动作不再执行并触发 OTA 中止。常见问题与注意事项版本一致性OTA header 版本必须与二进制内嵌软件版本一致否则 OTA 流程无法正确执行分区大小对齐修改m_app_max_sectors链接脚本或bootloader.conf/flash_partitioning.h中的分区大小后imgtool sign的--slot-size与--max-sectors必须同步调整加密密钥匹配启用 OTA 加密时应用构建chip_with_ota_key/CONFIG_CHIP_OTA_ENCRYPTION_KEY与.ota生成--input_ota_key必须使用同一个 AES-128 密钥MCUBoot 版本与签名算法MCUBoot v2.2 及以上默认使用 EC256/ECDSA更早版本默认使用 RSA。签名时请根据实际 MCUBoot 版本选择对应的imgtool签名参数与 SDK 密钥文件RT1170 特殊参数构建 MCUBoot 时需追加-Dcore_idcm7镜像回滚保障由于采用 DIRECT-XIP 模式与次分区暂存机制更新测试失败时引导加载器会自动回退到主应用从机制上杜绝降级风险。【免费下载链接】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），仅供参考