[参考译文] CC2340R5：CC2340R5：使用 MCUBoot 和 AMP 的 UART FOTA；OAD 片外示例代码组合。

admin

Other Parts Discussed in Thread: CC2340R5, SYSCONFIG, UNIFLASH

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1631195/cc2340r5-cc2340r5-uart-fota-using-mcuboot-oad-off-chip-example-code-combination

器件型号： CC2340R5
Thread 中讨论的其他器件： SYSCONFIG、 UNIFLASH

TI 团队大家好、

我使用的是 BLE CC340R5 模块。

我正在使用 SDK simplelink_lowpower_f3_SDK_8_40_02_01。

我想使用通过外部器件传输的 UART 文件来执行 BLE FOTA。

我查阅了 TI 文档和 OAD 示例代码、但我不确定是否可以使用 MCUBoot 示例代码和 BLE OAD 非芯片示例代码的组合进行此操作。

您能否确认是否可以执行此操作（如果是）1.需要注意哪些事项？

文件传输完成后如何触发 MCUBoot？

如何保存旧 bin 以及旧 bin 的位置、如果在 NVM 中 MCUboot 如何读取地址？

如何向 MCUBoot 通知 NVM 及其地址中新的 bin 可用性？

是否可以在外设+中央模式下使用 OAD 片外示例代码？

如何在 BLE 代码中停止中断和任务？

此致、

Rushikesh。

4 个月前

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Rushikesh：

感谢您联系我们！

1.需要注意哪些事项？

是的、它们在 F3 SDK 中构建为集成系统。 LP_EM_CC2340R5 的 basic_ble_oad_offchip 示例已配置为依赖 MCUBoot。

对于 UART 文件传输：basic_ble_oad_offchip 示例使用 BLE 作为传输工具将图像块写入外部闪存。如果您要使用 UART、则需要实现一个自定义 UART 接收器、将已签名的映像写入正确地址的外部闪存辅助时隙。 MCUBoot 引导加载程序逻辑（引导决策，复制，验证）保持不变。

2.如何在文件传输完成后触发 MCUBoot？

调用 HapiSbSetId (3)、然后调用 SystemReset ()、这将导致拍摄新映像。

#ifdef SECURE_BOOT
HapiSbSetId(3); // Signals secure boot: new image is ready in secondary slot
#endif
SystemReset(); // Triggers warm reset; MCUBoot runs on next boot
HapiSbSetId() writes a persistent flag in the 3V3 domain that survives the reset. On the next startup, the ROM checks this flag, hands control to MCUBoot, which then validates and boots the new image.

3.如何保存旧 bin 以及旧 bin 的位置、如果在 NVM 中、MCUboot 如何读取地址？

旧二进制文件会保持在内部闪存中、直到器件复位且 MCUBoot 使用新下载的映像将其覆盖。地址是 mcuboot config files.l 中配置的编译时地址

4.如何通知 MCUBoot NVM 中的新 bin 可用性及其地址？

地址通过 SysConfig 静态设置。无需动态地址检测。

5.我们是否可以在外设+中央模式下使用 OAD Offchip 示例代码？

是的、OAD 支持多角色、没有问题。

6.如何在 BLE 代码中停止中断和任务？

我不建议在 BLE 中禁用中断以用于 OAD。如果您通过 BLE 接收 OAD 映像、则让 OAD 任务处理所有内容是理想路径。如果您想使用 UART 路径、我建议尽可能重复使用 OAD 状态图。

也就是说、如果您计划通过 UART 执行 OAD、我认为更好的解决方案是使用串行引导加载程序。这样、您只需将器件置于引导加载程序模式、并通过 UART 发送映像以自动刷写到器件上。我建议参考 TRM 的引导加载程序部分、看看此解决方案是否适合您的用例。

此致、

1 月

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好 Jan、

感谢您的宝贵意见！

我想更新一下、我使用的是定制电路板、其上安装了 CC2340R5 芯片、并通过 UART 外设与微控制器连接。

目前我们没有可用的外部闪存、因此我必须切换到片上或双映像示例代码。

那么、在这种情况下、我想最重要的是所有内容都是相同的、是吗？

我还有几个问题：

在上面的第二个查询中、HapiSbSetId (3)；我想该 API 向 MCUBoot 告知辅助插槽中的固件可用性。

如果内部闪存中提供了固件、此调用是否保持不变？

如您所说、旧 bin 保存在内部闪存中、这是否也适用于片上/双映像示例代码？

使用自定义串行引导加载程序是有意义的。但是、如果使用片上/双映像逻辑、则直接刷写 bin 文件有一个主要缺点。

5.您能帮助我了解如何将器件置于引导加载程序模式吗？

此外、若要开发自定义引导加载程序、有必要说明哪些内容？

6.我是否可以使用 MCUBoot 示例代码来开发此串行引导加载程序？将使用自定义 UART FTP 替换文件传输机制。

此致、

Rushikesh。

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Rushikesh：

[引述 userid=“581985“ url=“~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1631195/cc2340r5-cc2340r5-uart-fota-using-mcuboot-oad-off-chip-example-code-combination/6290329

在上面的第二个查询中、HapiSbSetId (3)；我想该 API 向 MCUBoot 告知辅助插槽中的固件可用性。

如果内部闪存中提供了固件、此调用是否保持不变？

[/报价]

没错。会进行相同的过程和 API 调用、以指示新映像在辅助槽位中准备就绪。

2.如您所说、旧 bin 保持在内部闪存中、这是否也适用于片上/双映像示例代码？ [/报价]
要进行澄清、旧映像将保留在主槽位中、直到重置。重置后、新映像会覆盖旧映像、而旧映像会替换为新映像。如果您想保留旧映像、则需要开发一个在 mcuboot 之上构建的映像备份系统。
[引述 userid=“581985“ url=“~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1631195/cc2340r5-cc2340r5-uart-fota-using-mcuboot-oad-off-chip-example-code-combination/6290329
使用自定义串行引导加载程序是有意义的。但是、如果使用片上/双映像逻辑、则直接刷写 bin 文件有一个主要缺点。

5.您能帮助我了解如何将器件置于引导加载程序模式吗？

此外、若要开发自定义引导加载程序、有必要说明哪些内容？

6.我是否可以使用 MCUBoot 示例代码来开发此串行引导加载程序？将使用自定义 UART FTP 替换文件传输机制。
[/报价]
我强烈建议使用器件中内置的串行引导程序、而不是自行开发。您可以通过 syscfg 启用串行引导加载程序、空白器件默认启用串行引导加载程序。您可以将器件配置为通过特定 IO 的状态进入串行引导加载程序。在 SBL 中、您随后可以通过 UART 刷写映像、还可以通过 UART 执行简单的闪存操作。我建议参考 TRM 的 ROM 引导加载程序部分。如果确实需要自定义引导加载程序、则可以在 mcuboot 基础上构建并将其用作自定义引导加载程序。

此致、

1 月

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好 Jan、

我浏览了 CC23xx 的 TRM、我们知道我们还可以使用串行引导加载程序并通过 UART/SPI 使用外部接口刷写映像。

我有以下疑问：

如果在文件传输断电期间、器件会卡入 ROM 引导加载程序、还是已经定义了任何 FSM？

2.在 TRM 的第 8.5.4 节中、我们提到必须在图像传输完成后发送 CCFG 内容。

如何精确保存和共享该 CCFG 内容？文件类型？

3.需要将哪种类型的映像发送到 ROM 引导加载程序、.bin 或.hex？

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

你（们）好

1.如果在文件传输断电期间、器件会卡入 ROM 引导加载程序中还是已经定义了任何 FSM？

ROM 引导加载程序不会在断电过程中保持任何传输状态、因此换言之、下次上电时、您没有存储器或记录上一次运行中发生的情况。下次上电时、如果您的触发引脚仍处于有效状态（或闪存没有有效的应用）、则器件将重新进入引导加载程序。然后、主机只会从头开始重新启动：发出 BLDR_CMD_CHIP_ERASE、然后重新启动下载序列。

一个重要注意事项：如果使用 BLDR_CMD_DOWNLOAD_CRC（建议使用，根据 TRM§8.5.3.8）、则会在接收到所有字节后执行 CRC 校验。如果传输中断且 CRC 从未完成、则在下一次芯片擦除运行时、部分写入的内容将自动擦除。因此、不存在部分写入导致器件崩溃的风险—只需从步骤 1（芯片擦除+下载）重试即可。

2.在 TRM 的第 8.5.4 节中、我们提到必须在图像传输完成后发送 CCFG 内容。

如何精确保存和共享该 CCFG 内容？文件类型？

[/报价]

CCFG 是一个 2048 字节的二进制区域、地址为 0x4E020000。它由 SysConfig 生成并编译到应用程序的.out 文件中（作为.cfg 链接器段）。

要将其提取为独立二进制文件、请在编译后处理步骤中使用 objcopy：

arm-none-eabi-objcopy -O binary --only-section=.ccfg myapp.out ccfg.bin

然后、通过标准 SBL 数据包协议发送此 ccfg.bin (TRM§8.5.4 中的步骤 6–7)：

BLDR_CMD_DOWNLOAD_CRC、具有 startAddress=0x4E020000、length=2048 和 CCFG 字节的 CRC
后跟 BLDR_CMD_SEND_DATA 块（每个块最多 252 字节）

格式为原始二进制格式、因此只发送原始十六进制文件就会传输映像。该协议在 download 命令中单独传送地址信息、而不是嵌入在数据中。

[quote userid=“581985“ url=“~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1631195/cc2340r5-cc2340r5-uart-fota-using-mcuboot-oad-off-chip-example-code-combination/6292370 需要将哪种类型的映像发送到 ROM 引导加载程序、.bin 或.hex？

二进制文件将是正确的二进制文件 (.bin)。

此致、

1 月

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好 Jan、

感谢您的支持。

让我检查一下并回复您以上几点。

此致、

Rushikesh。

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Rushikesh：

没问题！很高兴为您提供帮助！

此致、

1 月

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好 Jan、

我有一个跟进问题给您：

据称、我们可以通过将后门引脚置为有效来进入 ROM 引导加载程序。

我认为我们应该将该引脚拉至低电平并切换 RESET 引脚。

但是、这需要由 BLE 应用本身触发？还是需要借助外部接口来处理？

我们可以将任何 GPIO 配置为后门引脚/触发器引脚以进入引导加载程序模式吗？还是固定的 GPIO？

实际上、到控制器上、我们连接了 DIO11、我只能使用/访问该 GPIO 作为触发引脚。

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、

据称、我们可以通过将后门引脚置为有效来进入 ROM 引导加载程序。

我认为我们应该将该引脚拉至低电平并切换 RESET 引脚。

但是、这需要由 BLE 应用本身触发？还是需要借助外部接口来处理？

[/报价]

可通过 syscfg 配置引导加载程序引脚（既要使用哪个引脚，也要使其在高电平或低电平时触发）。需要通过 MCU 外部的器件将 IO 设置为触发值、并且 MCU 必须复位。复位时、MCU 将查看引导加载程序引脚并读取其值、如果它处于触发值、则引导加载程序将加载。除了通过 syscfg 配置器件以允许引导加载程序之外、无需进行软件更改或任何其他操作。无需更改应用代码。

我们可以将任何 GPIO 配置为后门引脚/触发器引脚以进入引导加载程序模式吗？还是固定的 GPIO？

实际上、到控制器上、我们连接了 DIO11、我只能使用/访问该 GPIO 作为触发引脚。

[/报价]

它应该是任何 GPIO。您可以通过调用复位 API 从应用程序内启动复位、但触发引脚必须由外部某个器件驱动。

此致、

1 月

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好 Jan、

例如、在 syscfg 中、我将 GPIO (DIO11) 配置为正常 GPIO、并设置其触发值、如下所示：

引导加载程序将如何知道它配置为触发器引脚/引导引脚的这个特定 GPIO？

此致、

Rushikesh。

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Rushikesh：

此设置在引导加载程序在每次引导时查看的映像的 CCFG 中设置、这是引导加载程序通过什么方式知道要查看的 IO 以及目标值。

此致、

1 月

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好 Jan、

配置为以下设置。通过此设置、ROM 引导加载程序现在知道我已将 DIO11 配置为触发器/后门、并使用索引= 1 、这意味着我已将 DIO12 DIO13 配置为 UART Rx、Tx 引脚。因此 ROM 引导加载程序会在该 UART 通道上向我发送 ACK/NACK。

我遵循的步骤（全部在 CC2340R5 LaunchPad 上）：

1.将触发器引脚拉至低电平 — 连接至 GND。

2.重置。

3.~500ms-1s 后释放。

在 UART 上发送 0x5555

5.等待 ACK/NACK。

6.收到 ACK 为 0x00CC。

7、将 ping 命令发送为 0x032020

8.收到 0x00CC。

我期待这种流程从您那里流出。但无论如何、我能够进入 ROM 引导加载程序。

您能告诉我如何针对 TRM 第 8.5.4 节中给出的命令流计算 CRC 吗？

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您之前确认需要将.bin 发送到 ROM 引导加载程序。现在、基本示例代码会在编译后创建一个.hex 文件。

是否有任何可能的方法获取/生成.bin 格式的相同映像？

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Rushikesh：

您能告诉我如何针对 TRM 第 8.5.4 节中给出的命令流计算 CRC 吗？

CRC 是标准的 IEEE CRC-32 流程。我认为它应该与 Python 中的 binascci.CRC32 () 函数相同,所以你应该能够使用它作为参考。此值进入 BLDR_CMD_DOWNLOAD_CRC 数据包的字节 9–12（MSB 在前）。引导加载程序会针对所有接收到的 BLDR_CMD_SEND_DATA 字节重新计算相同的 CRC、如果存在不匹配情况、则返回 BLDR_CMD_RET_CRC_FAIL (0x45)、并立即擦除部分写入。请注意、您需要分别为应用映像（步骤 4–5、在§8.5.4 中）计算和发送 CRC、然后再次为 CCFG（步骤 6–7）计算和发送 CRC。

是否有任何可能的方法以.bin 格式获取/生成相同的映像？

是的、使用与 CCS TI Clang 捆绑的 tiarmobjcopy。由于应用和 CCFG 会发送到不同的地址、因此您需要两个单独的.bin 文件：

应用二进制文件（发送到 0x00000000）：

tiarmobjcopy myapp.out --output-target binary myapp_app.bin --remove-section=.ccfg

CCFG 二进制（发送至 0x4E020000）：

tiarmobjcopy myapp.out --output-target binary myapp_ccfg.bin --only-section=.ccfg

您可以在 CCS 的 Project Properties→Build→Steps→Post-build steps 下将两者作为编译后处理步骤添加。使用`$｛CG_TOOL_ROOT｝/bin/tiarmobjcopy`、而不是硬编码路径。 SDK 中的 basic_ble_oad_offchip 示例已经使用了相同的方法。

此致、

1 月

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好 Jan、

感谢您的答复。

根据 TRM、我尝试验证从外部接口通过 UART 进行文件传输。

我想使用 TRM 第 8.5.4 节中给出的命令发送.bin 文件

按照以下命令序列、芯片正在成功擦除。

但在发送 BLDR_CMD_DOWNLOAD 或 BLDR_CMD_DOWNLOAD_CRC 时、 我始终从 ROM 引导加载程序中收到 NACK。

我确实使用 IEEE 32 位 CRC 生成了 CRC、并在 BLDR_CMD_DOWNLOAD_CRC 命令中使用了相同的设置。

命令序列：

1]最初根据示例流程、在芯片擦除后仅发送 BLDR_CMD_DOWNLOAD_CRC。

(13：30：44.677)(11.432)(<<) 55h 55h (2)

(13：30：44.812)(0.135)(>>) 00h CCh (2)

(13：30：46.112)(1.300)(<<) 03h 20h (3)

(13：30：46.245)(0.132)(>>) 00h CCh (2)

(13：30：49.092)(2.847)(<<) 03h 24h (3)

(13：30：49.211)(0.119)(>>) 00h CCh (2)

(13：30：52.522)(3.311)(<<) 0Dh 27h 00h 00h 00h 00h 00h 03h 6Eh F9h A9h 71h B4h CAh 3Ah (15)

(13：30：52.683)(0.160)(>>) 00h 33h (2)

0d — 长度

27-命令 ID

00h 00h 00h 00h — 程序地址

00h 03h 6Eh F9h — 编程大小

A9h 71h B4h CAh - CRC

3Ah — 校验和（不确定是否需要此功能，因为无论有无校验和，都能获得相同的响应）

2]然后尝试首先发送 BLDR_CMD_DOWNLOAD、因为我认为这是正确的预期序列。

(15：17：11.009)(3：11.600)(<<) 55h (2)
(15：17：11.148)(0.138)(>>) 00h CCh (2)
(15：17：11.998)(0.850)(<<) 03h 20h (3)
(15：17：12.163)(0.165)(>>) 00h CCh (2)
(15：17：14.064)(1.900)(<<) 03h 24h (3)
(15：17：14.197)(0.133)(>>) 00h CCh (2)
(15：17：16.227)(2.030)(<<) 09h 26h 00h 00h 00h 00h 03h 6Eh F9h C5h (11)
(15：17：16.366)(0.138)(>>) 00h 33h (2)

注意：也尝试了以小端字节序发送字节、对于这些字节、也会收到 NACK。

但我仍然被否定应答。我不知道这里缺少什么。

我还附加了要发送到 ROM 引导加载程序的.bin 文件。

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

此外、如果我发出 BLDR_CMD_GET_STATUS 命令、点击任何命令后、ROM 引导加载程序不会返回响应。

事实上,它不响应任何其他命令之后.

这里的问题是什么？

您能否确认每个命令的超时时间是多少？

0 admin 4 个月前

TI__Guru**** 2893300 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Rushikesh：

但在发送 BLDR_CMD_DOWNLOAD 或 BLDR_CMD_DOWNLOAD_CRC 时、 我始终从 ROM 引导加载程序中收到 NACK。

[/报价]

问题在于数据包成帧。在 TRM§8.5.1.1 中将 CC23xx ROM SBL 数据包格式定义为：

[SIZE][CHECKSUM][DATA bytes...]

其中、size =数据字节数+ 2、checksum =所有数据字节的 8 位和 (mod 256)、数据以命令字节开始。数据包的校验和和命令字节处于交换位置、size 字段缺少+2。

您的 download_crc 数据包：

    0D  27  00 00 00 00  00 03 6E F9  A9 71 B4 CA  3A
        ^cmd here (wrong)                           ^checksum here (wrong)
    ^size=13 (wrong)

正确的 DOWNLOAD_CRC 数据包：

    0F  29  27  00 00 00 00  00 03 6E F9  A9 71 B4 CA
    ^   ^   ^cmd
    |   checksum = 0x29 (sum of 0x27+0x03+0x6E+0xF9+0xA9+0x71+0xB4+0xCA mod 256)
    size = 0x0F = 15 (13 data bytes + 2)

如需在同一映像上下载 (0x26)：

    0B  90  26  00 00 00 00  00 03 6E F9
    size = 0x0B = 11 (9 data bytes + 2), checksum = 0x90

还有一个注意事项：BLDR_CMD_GET_STATUS 为 0x21、而不是 0x24。您发送的 0x24 个数据包为 BLDR_CMD_CHIP_ERASE（这就是擦除成功的原因）。正确的 GET_STATUS 数据包为 03 21 21。

此外、如果我发出 BLDR_CMD_GET_STATUS 命令、点击任何命令后、ROM 引导加载程序不会返回响应。

[/报价]

接收到大小错误的数据包后、引导加载程序上的 UART 接收缓冲区将不同步 — 它读取了错误的字节数，并等待数据不能正确到达。无论等待什么、都不会解析后续命令。没有将恢复此结果的每命令超时；您必须执行完全硬件复位：将触发器引脚置为无效、切换 RST、将触发器引脚重新置为有效、然后从自动波特同步重新启动 (55 55)。

此致、

1 月