LAUNCHXL-CC3235SF: Amazon FreeRTOS OTA demo fails

Hi Hans,

I can't access the log, please use the following link to upload it: 

https://txn.box.com/s/ueqzkvtn318hi4x3ziy4fxbt99srtlxk

The sl_Stop issue is probably relevant for the 2nd issue - can you provide NWP logs for this (see chapter 20.1 in http://www.ti.com/lit/ug/swru455j/swru455j.pdf).

Did you see any error before the reset?

Does the new image contain a SP or just the MCU image?

br,

Kobi 

Hi Kobi

Thank you for your quick response!

I don't have the right permissions to upload files to the given box folder. Is it possible to open the following files?

/cfs-file/__key/communityserver-discussions-components-files/968/ota_5F00_demo_5F00_output.txt

/cfs-file/__key/communityserver-discussions-components-files/968/NWP_5F00_output_5F00_MAC.log

/cfs-file/__key/communityserver-discussions-components-files/968/NWP_5F00_logs_5F00_windows.log

The first file is the OTA output file, the second is the NWP log extracted by using a mac computer and the last is the NWP log extracted by using a windows computer.

I don't know if the NWP logs were extracted successfully, so please let me know if this is the case. I followed the instructions documented on the swru445j.pdf: Implemented the required code in the demo application, disconnected the TxD and RxD headers between the CC3235 and TM4C129 chips, connected the left P62 pin to the TM4C129 TxD header pin and set the baud rate of the serial monitor to 921600.

Before the reset, I have not seen any errors.

The new image does not contain a SP. It is just the binary file of the OTA demo application. The initial version of the OTA demo application, certificates and service pack are flashed with Uniflash.

For the SP, I am using the CC3235SF SP included in the SimpleLink SDK version 3.40.00.05.

Greetings

Hans

Hi Hans,

The windows log is readable but it doesn't seem to record the entire use-case (from start of OTA process till the error following the MCU reset).

Also please make sure to log the failing sl_Stop(200).

If I understand correctly, the original app version is 0.9.2 and the OTA image is supposed to include an incremental version number (0.9.3?).

Do you have a CC3220SF to test this AFR OTA (as a reference)? 

what was the OTA_SL_STOP_TIMEOUT that you used? can you try to extend it? I believe  a non-zero value must be used for the OTA to complete successfully.

Br,

Kobi

Hi Kobi

After some more debugging, it looks like the sl_Stop() function is not the failing part in the AFR OTA demo. I have increased the value of the OTA_SL_STOP_TIMEOUT variable from the original 200 to 300 and it now executes successfully. After sl_Stop(300), MAP_PRCMHibernateCycleTrigger() gets executed which restarts the MCU. These two functions ensure the new OTA image is being loaded. But here the problem arises. After MAP_PRCMHibernateCycleTrigger() is executed, the MCU is situated in some kind of 'lock' state. The OTA demo does not start up and led D7, on the launchpad development board, is solid green. Normally when a reset is triggered, D7 will blink green right before the program starts. To get the MCU out of this 'lock' state, I need to push the reset button (SW1). Now the OTA demo runs, but the new OTA image is not loaded and the program fails saying that the version is still the same.

About the version, you are correct. The OTA image must contain a higher version than the initial app version.

Currently, we do not own a CC3220SF to use as reference.

I have again extracted the NWP log with following procedure:

- Used 300 with sl_Stop function

- When the MCU enters the 'lock' state, I waited 5s before I pushed the reset button.

/cfs-file/__key/communityserver-discussions-components-files/968/5658.nwp2.log

Thank you for all your help so far!

Greetings

Hans

Are you using the OTA watchdog (i.e. are you writing the "mcubootinfo.bin")?

see example:

//*****************************************************************************
//
//! \brief
//
//*****************************************************************************
int32_t Platform_CommitWdtConfig(int32_t TimeoutInSeconds)
{
    int32_t lFileHandle;
    uint32_t ulToken = 0;
    sBootInfo_t sBootInfo;
    int32_t lRetVal;

    lFileHandle = sl_FsOpen(
        (unsigned char *)"/sys/mcubootinfo.bin",
        SL_FS_CREATE | SL_FS_OVERWRITE |
        SL_FS_CREATE_MAX_SIZE(
            sizeof(sBootInfo)) |
        SL_FS_CREATE_SECURE | SL_FS_CREATE_PUBLIC_WRITE |
        SL_FS_CREATE_NOSIGNATURE,
        (_u32 *)&ulToken);

    if(0 > lFileHandle)
    {
        //OTA_DBG_PRINT("OtaWatchDog: Error opening bootinfo file
      //        : %d\n\r",lFileHandle);
        return(-1);
    }

    memset(&sBootInfo,0,sizeof(sBootInfo_t));
    /* max 104 seconds */
    sBootInfo.ulStartWdtTime = 40000000 * TimeoutInSeconds; 
    sBootInfo.ulStartWdtKey = APPS_WDT_START_KEY;
    lRetVal =
        sl_FsWrite(lFileHandle, 0, (uint8_t*)&sBootInfo, sizeof(sBootInfo_t));
    lRetVal = sl_FsClose(lFileHandle, 0, 0, 0);
    if(0 != lRetVal)
    {
        //OTA_DBG_PRINT("OtaWatchDog: Failed to close the bootinfo file");
        return(-1);
    }
    //Enable WDT - done by PRCMCC3200MCUInit
    //HWREG(0x4402E188) |= 0x00000020;
    return(0);
}

It looks like there is a problem with regards to your new image so the boot loader fails. If the OTA watchdog is initialized, then I would expect that it trigger an MCU reset automatically after the timeout. In your case, the manual reset (without committing the new version) causes the bootloader to revert to the previous working image. 

You can check this by printing the bootloader state (before and after the MCU reset) and verifying that it is not in "Pending Commit" state.

see instruction http://www.ti.com/lit/an/swra510a/swra510a.pdf 

br,

Kobi

Hi Kobi

Sorry for my late reply

Yes, I am writing the "mcubootinfo.bin" file and configures the watchdog timer. You can find the implementation of this process here.I have compared this function with your snippet function and they are looking very similar. So the configuration of the watchdog is okay, but strangely it does not perform a reset after a timeout (In my case this is 16s). Maybe this is because the MCU gets stuck in hibernate, so the watchdog doesn't work ( I have red somewhere that in hibernate mode, only the RTC works. Is this correct? ).

I have printed the state of the image before and after reboot. Right before sl_Stop is executed, the state of the image is in "Pending Commit" (=~ SL_FS_INFO_PENDING_BUNDLE_COMMIT). Then the MCU reboots and enters the "lock" state. Normally after 16s the watchdog triggers a reset, but this does not happen so I executed a manual reset. Now the state of the image is 'Normal', meaning that the manual reset reverted the image to the previous working state.

I don't think the new image (=~ OTA image) is the problem here, because this is the same image as the initial image except that I increased the app version.

I have tried replacing the MAP_PRCMHibernateCycleTrigger() function with:

// RTC clk as HIB wakeup source
PRCMHibernateWakeupSourceEnable(PRCM_HIB_SLOW_CLK_CTR);

// set HIB interval to 5 seconds
PRCMHibernateIntervalSet(32768 * 5);

// enter HIB mode
PRCMHibernateEnter();

But I experienced the same problem...

I really don't know why this happens. Is it because we are using the CC3235SF instead of the CC3220SF? I find this hard to believe, because the two chips are working on the same SimpleLink SDK. Do you have anymore recommendations against this problem?

Greetings

Hans

The Watchdog doesn't work during hibernate. It is supposed to start by the bootloader upon exit from hibernate and before running the new image (when the pending for commit mode is identified - i.e. following OTA that ended with sl_Sleep(>=200)).

Hey Kobi

We have bought the CC3220SF Launchkit to use as reference for the AFR OTA demo. On this chip the demo works like expected. The chip is able to reboot and applies the newly download image.

What are the main differences between the two chips? Maybe you can point me in the right direction to solve this issue knowing that the code works on the CC3220SF.

Thanks in advance

Hans

The main difference in regards to the OTA is that the you need to use a different SP and different signature for the certificate catalog.

There is a known issue with regards to to CC3235 that it will not raise an error when the CC3220 files (i.e. SP and certificate catalog signature) are used in the OTA image (in  such case the MCU reset will fail).

Make sure you select CC3235SF in your uniflash project and you are using the device specific files. 

Br,

Kobi