[参考译文] LAUNCHXL-CC3235SF：CC32xx 本地 OTA：如何在重新启动后配置提交超时

您好、Ryan、

下载 OTA 更新时、您的器件将处于 pending_commit 状态。 出于猜测、您可能 会遇到 OTA 更新故障、看门狗计时器到期会导致 OTA 捆绑包回滚。 有关这方面的详细信息、请参阅 NWP 手册的 8.9.6。 其中讨论了更改看门狗计时器超时（不一定是提交超时）。

我可以尝试在我这边测试演示、看看我得到了什么。  

您好 Brandon、

感谢您的答复。 为了澄清一下、我的问题具体涉及 OTA 提交超时 不是看门狗计时器。

在器件下载 OTA 更新并重新引导进入后 Pending_commit 、提交新固件的时间窗口有限；否则、它会回滚。

我想知道：

1. 什么是 默认提交超时 持续时间？

2. 是否有正式的方法 增加或配置 此提交超时？

3. 是否有在提交新固件之前安全验证新固件的建议做法、尤其是在我需要时 有更多时间进行验证 而不触发回滚？

我的用例：

• 使用本地 OTA (HTTP Put/ota/update )

• /ota/verify在提交前通过 GET 验证器件功能

感谢您的指导。

您好、Ryan、

您是否在谈论单独的超时？ 本质上、我要说的是在 OTA 更新期间、当您的器件等待提交时、会设置一个看门狗计时器、如果看门狗计时器超时、它将触发回滚。 这是因为、如果您在没有看门狗计时器的情况下自动提交更新、并且映像出现故障且无法接受新的 OTA 更新、则器件会保持其始终无法正常工作的状态。 看门狗计时器具有失效防护功能、因此如果等待提交的映像不起作用、器件可以返回接受未来 OTA 更新的映像。

这是我目前知道的唯一“超时“、但我也在研究示例、以查找您提到的其他超时。  

您好、感谢您的澄清。

是的、您是正确的—通过“提交超时“、我指的是您描述的内容：

• 在设备重新引导至之后 Pending_commit 、

• a. 看门狗计时器 已启动（通过配置）/sys/mcubootinfo.bin、

• 如果在此时间窗口内未提交新映像、器件会自动回滚到之前的版本。

我查看了演示代码、发现这是在中配置的 ConfigureOtaWDT_CC32XX () ：

static int ConfigureOtaWDT_CC32XX(int32_t TimeoutInSeconds)
{
    // TODO - write only if file doesn't exist (check before writing)
    sBootInfo_t sBootInfo;
    int rc;

    memset(&sBootInfo,0,sizeof(sBootInfo_t));
    sBootInfo.ulStartWdtTime = 40000000*TimeoutInSeconds; /* max 104 seconds */
    sBootInfo.ulStartWdtKey = APPS_WDT_START_KEY;
    rc = FILE_write("/sys/mcubootinfo.bin", sizeof(sBootInfo_t), (uint8_t*)&sBootInfo, NULL, 0);

    if(SL_ERROR_FS_FILE_IS_PENDING_COMMIT == rc)
    {
        /* "/sys/mcubootinfo.bin"  was part of the OTA image */
        UART_PRINT("OtaWatchDog: Watchdog is updated by mcubootinfo.bin from the OTA image");
        rc = 0;
    }
    else if(0 != rc)
    {
        UART_PRINT("OtaWatchDog: Failed to store the bootinfo file (%d)", rc);
    }
    return rc;
}

使用编写该文件 file_write() ：

int FILE_write(char *pFilename, uint16_t length, uint8_t* pValue, uint32_t *pToken, uint32_t flags)
{
    int32_t  lFileHandle;
    int   rc;
    uint32_t ulToken = 0;
    int32_t  OpenFlags = 0;


    /* Open the file as bundle !!!*/
    OpenFlags = (SL_FS_CREATE | SL_FS_OVERWRITE);
    OpenFlags |= (SL_FS_CREATE_SECURE | SL_FS_CREATE_NOSIGNATURE);
    OpenFlags |= flags;

    if(!pToken)
    {
        pToken = &ulToken;
        OpenFlags |= (SL_FS_CREATE_PUBLIC_WRITE | SL_FS_CREATE_PUBLIC_READ);
    }

    lFileHandle = sl_FsOpen((uint8_t *)pFilename,  OpenFlags| SL_FS_CREATE_MAX_SIZE( length ), (unsigned long *)pToken);
    if(lFileHandle < 0)
    {
        UART_PRINT("FILE_write: Error sl_FsOpen %s, Status=%d", pFilename, lFileHandle);
        return (int16_t)lFileHandle;
    }

    rc = (int16_t)sl_FsWrite(lFileHandle , 0, (uint8_t *)pValue,length);
    if(rc < 0)
    {
        UART_PRINT("FILE_write: Error sl_FsWrite, Status=%d", rc);
        return rc;
    }

    rc = sl_FsClose(lFileHandle, NULL, NULL, 0);
    if(rc < 0)
    {
        UART_PRINT("FILE_write: Error sl_FsClose, Status=%d", rc);
        return rc;
    }

    return rc;
}

通过我的测试：

• IF I mcubootinfo.binOTA 捆绑包中 、因此、由于该文件处于等待提交状态、我无法在运行时覆盖它。

• IF I 不要将其包含在捆绑包中 、的呼叫FILE_write()似乎被卡住（我尚未确认确切的原因，仍在调查）。

目前、我的解决方法是 手动修改的二进制 mcubootinfo.bin可延长超时时间（例如比默认值~15s 长）、并且有效。

我的问题是：

1. 有没有 官方/推荐的安全延伸方式 ulStartWdtTime而无需手动修补二进制文件？

2. 还是应该始终采用正确的方法 mcubootinfo.bin在 OTA 捆绑包中发送修改后的数据 如果我们想要更长的提交窗口？

3. 直接修改文件内容（就像我现在所做的那样）是否被认为是可以接受的、或者是否有更好的做法？

谢谢