LAUNCHXL-CC3235SF: CC32xx Local OTA: How to configure commit timeout after reboot

Hi Ryan,

When you download an OTA update, your device will be in PENDING_COMMIT. Out of speculation, you may be experiencing a fault in your OTA update and a watchdog timer expiration is causing your OTA bundle to get rolled back. Details about that can be seen in 8.9.6 of the NWP manual. It discusses changing the watchdog timer timeout (not necessarily the commit timeout).

I can try to test the demo on my end and see what I get. 

Hi Brandon,

Thanks for the reply. Just to clarify, my question is specifically about the OTA commit timeout in the SDK, not the watchdog timer.

After the device downloads an OTA update and reboots into PENDING_COMMIT, there is a limited time window to commit the new firmware; otherwise, it rolls back.

I would like to know:

1. What is the default commit timeout duration?

2. Is there an official way to increase or configure this commit timeout?

3. Are there recommended practices for safely verifying the new firmware before committing, especially if I need more time for verification without triggering rollback?

My use case:

• Using local OTA (HTTP PUT /ota/update)

• Verifying device functionality via GET /ota/verify before commit

Thanks for the guidance.

Hi Ryan,

Are you talking about a separate timeout? Essentially, what I'm talking about is during an OTA update, when your device is pending commit, there is a watchdog timer set and it will trigger an rollback if the watchdog timer times out. This is because if you automatically commit the update without a watchdog timer and the image is faulty and cannot accept new OTA updates, the device remains in a state where it will never work properly. The watchdog timer acts as a fail safe such that if the image pending commit doesn't work, the device can go back to an image that accepts future OTA updates.

That is the only "timeout" I am currently aware of, but I'm also looking into the example to find what other timeout you are referring to. 

Hi, thanks for the clarification.

Yes, you are correct — by "commit timeout" I was referring to exactly what you described:

• After the device reboots into PENDING_COMMIT,

• A watchdog timer is started (configured via /sys/mcubootinfo.bin),

• If the new image is not committed within this time window, the device automatically rolls back to the previous version.

I looked into the demo code and found that this is configured in 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;
}

And the file is written using 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;
}

From my testing:

• If I include mcubootinfo.bin inside the OTA bundle, then because the file is pending commit, I cannot overwrite it at runtime.

• If I don’t include it in the bundle, the call to FILE_write() seems to get stuck (I haven’t confirmed the exact reason yet, still investigating).

Currently, my workaround is to manually modify the binary of mcubootinfo.bin to extend the timeout (e.g. longer than the default ~15s), and it works.

My questions are:

1. Is there an official/recommended way to safely extend ulStartWdtTime without manually patching the binary?

2. Or should the correct approach be to always ship a modified mcubootinfo.bin inside the OTA bundle if we want a longer commit window?

3. Is directly modifying the file contents (as I’m doing now) considered acceptable, or is there a better practice?

Thanks