[参考译文] CC1314R10：CC1314 — 使用专有 RF 命令和 MCUboot 实现 OTA 过程

尊敬的 Muniyappan：

我不太明白这个问题。 这是自定义 OAD 实现还是我们的示例之一？ 问题的第一部分（您成功运行 OAD 的位置）和第二部分 (OAD) 之间有什么区别？

请查看以下指南 https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__ASjZ9RLT3t-JeXWUfsK50w__com.ti.SIMPLELINK_ACADEMY_CC13XX_CC26XX_SDK__AfkT0vQ__LATEST

以及用户指南 OAD 专有射频 https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__AF4qnA2RLWd6BQ856R4f-w__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK__BSEc4rl__LATEST 

Q1) 是的、下载后您必须检查 CRC 以验证映像的完整性、否则您可能会尝试引导至损坏的映像。 请查看其中一个示例中的 crc232.c

Q2) 是的、您需要进行重新启动并拥有引导加载程序 (BIM/MCUBoot)。 您可以使用 SysCtrlSystemReset()。 例如、检查位于 oad_client.c 中的 OADClient_processEvent() 中的 rfOADClient 示例

void OADClient_processEvent(uint32_t *pEvent)
{
    /* Is it time to send the next sensor data message? */
    if(*pEvent & oadClientParams.oadReqEventBit)
    {
        static int32_t prevBlock = -1;
        static bool oadComplete = false;

        if(oadComplete)
        {
            /* Reset to BIM */
            SysCtrlSystemReset();

            /* Clear complete flag in case reset did not work */
            oadComplete = false;
        }

Q3) Q4) 是的、我相信您可能需要将映像填充到插槽的整个大小、因为您使用的是 BIM 还是 MCUBoot 限制 (e2e.ti.com/.../cc2340r5-why--pad-paramter-is-needed-in-imgtool-for-dual-image-oad-but-not-for-on-chip-oad

此致、

Daniel

尊敬的 Muniyappan：

我刚刚使用 SimpleLink F2 SDK 8.32.00.07 进行了构建测试。

应用程序映像 bin 文件 (ns_CoAP_oad_offchip_LP_EM_CC1314R10_tirtos7_ticlang-noheader.bin) 大小为 327KB。 通过 oad 映像工具 (ns_CoAP_oad_offchip_LP_EM_CC1314R10_tirtos7_ticlang.bin) 运行映像后、文件大小已增加到 367KB。 我可以在文件的末尾看到有一堆 0xFF 后跟一些其他字符。 因此、在较新的 SDK 中、这似乎仍然是一个问题。

以下是调用 oad 映像工具的编译后命令：

$｛CG_TOOL_ROOT｝/bin/tiarmobjcopy -O ihex $｛BuildArtifactFileName｝$｛BuildArtifactFileBaseName｝.hex
$｛CG_TOOL_ROOT｝/bin/tiarmobjcopy $｛BuildArtifactFileBaseName｝.out --output-target binary $｛BuildArtifactFileBaseName｝-noheader.bin
$｛COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR｝/tools/common/mcuboot/imgtool 符号--header-size 0x80 --align 4 --slop-size 0x5A000 --pad --version 1.0.0 --pad-header --key $｛COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR｝/source/third_party/mcuboot/root-ec-p256.pem $｛ArtifacArtifactFileName｝-noheader.bin

我认为这里的罪魁祸首是“Pad"命令“命令。 如果我将其删除并重试、则删除填充。  

您可以在以下位置找到编译后处理命令：“Project"->"Properties"->"Build"->"Steps"->"Post-build"步骤“步骤。“。</s>“ ““““““这是我在片外 OAD 工程中使用的命令：

$｛CG_TOOL_ROOT｝/bin/tiarmobjcopy -O ihex $｛BuildArtifactFileName｝$｛BuildArtifactFileBaseName｝.hex
$｛CG_TOOL_ROOT｝/bin/tiarmobjcopy $｛BuildArtifactFileBaseName｝.out --output-target binary $｛BuildArtifactFileBaseName｝-noheader.bin
$｛COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR｝/tools/common/mcuboot/imgtool 符号--header-size 0x80 --align 4 --slop-size 0x5A000 --version 1.0.0 --pad-header --key $｛COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR｝/source/third_party/mcuboot/root-ec-p256.pem $｛BuildfacArtifactBaseName｝-noheader.bin $｛BuildFileArtiFileName｝

希望这有所帮助。 谢谢、

Marie H

您好、

这是我得到的答案：

BOOT_MAGIC 和 BOOT_MAGC_2 都验证映像、但也提供有关字节对齐方式的信息。 与中一样、如果最后 16 个字节与 boot_magic 匹配、则表示默认为 8 字节写入对齐。 否则、如果最后 14 个字节与 boot_magic_2 匹配、则表示有自定义写入对齐、魔法字段的前 2 个字节表示实际对齐值、在这种情况下、接下来的 14 个字节与 boot_magic_2 匹配。 这使得 MCUboot 能够支持任何对齐值（16、32、64 等）、而无需每个值使用不同的魔术常数。

例如 0x20 0x00 | 0x2D 0xe1 0x5d 0x29 0x41 0x0B 0x8d 0x77 0x67 0x9C 0x11 0x0F 0x1f 0x8a
前 2 个字节：小端字节序格式中的 0x20 0x00 = 32（对齐值）
剩余 14 个字节：boot_magic_2 签名
请参阅同一文件中的以下代码片段：

if trailer_magic == BOOT_MAGIC:
      max_align = 8  # Default alignment
elif trailer_magic[-len(BOOT_MAGIC_2):] == BOOT_MAGIC_2:
      max_align = int.from_bytes(trailer_magic[:2], "little")  # Custom alignment   

MCUboot 在固件映像末尾的映像尾存储状态信息。 这包括以下字段：
image_ok — 图像是否已确认正常工作
COPY_DONE — 交换操作是否完成
SWAP_INFO — 交换状态信息
swap_size — 交换操作的大小
在引导/升级过程中、必须单独写入这些字段中的每一个字段。 由于闪存对齐要求、每个字段必须至少占用 max_align 字节、即使实际数据仅为 1 字节也是如此。
示例
使用 8 字节对齐：
| SWAP_SIZE（4 个字节）|填充（4 个字节）|总共<- 8 个字节
| SWAP_INFO（1 字节）|填充（7 字节）|总共<- 8 个字节
| COPY_DONE（1 字节）|填充（7 字节）|总共<- 8 字节
| image_ok（1 字节）|填充（7 字节）|总共<- 8 字节
| boot_magic（16 字节）|

谢谢、

Marie H