This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHCC3220MODASF: Rollback of firmware after OTA

Part Number: LAUNCHCC3220MODASF
Other Parts Discussed in Thread: CC3200

Hi,

I have an issue with the automatic rollback when doing an OTA update of the cc3220modasf. 

I'm writing the file /sys/mcuflashimg.bin (Opened with the the flag SL_FS_WRITE_MUST_COMMIT), calling Power_shutdown and testing the new firmware. If it succeed, I call sl_FsCtl(SL_FS_CTL_COMMIT, ...).

I am expecting the file to be automatically reverted to the previous one if it does not get validated by sl_FsCtl(SL_FS_CTL_COMMIT) during its first start. But what I'm seing is that the device reboots on the new file, fails to connect to http server and goes back to hibernate with Power_shutdown, it then always restarts on the non-validated file.

As expected the SlFsFileInfo_t.Flags is 0x250 after commit, and 0x254 when commit is pending, and this also after each successive start.

My questions:

  1. Shall the file be automatically be reverted if there is no commit?
  2. If yes, what could be preventing it?

I'm using the latest sdk and service pack.

  • Hi Cedric,

    Correct, the file should revert if it is not committed. We wouldn't expect this behavior.

    A few things to check:
    1. Are you using the default OTA library? Have you made any changes?
    2. Do you see this behavior using the OTA example? If not, can you share how your implementation is different?
    3. What flags are set for mcuflashimg.bin in ImageCreator?
    4. To verify, do you mean SDK version 2.40.02.00 and CC3x20 service pack sp_3.10.0.5_2.0.0.0_2.2.0.6? I'll see if I can replicate this.

    Best regards,
    Sarah

  • Hi Sarah,

    Thank you for your reply!

    1+2: No I'm not using the ota library. I'm reusing the mechanism which we implemented for the cc3200 where we download the new binary on our server with an http request, writing the file /sys/mcuflashimg.bin (Opened with the the flag SL_FS_WRITE_MUST_COMMIT), calling Power_shutdown and testing the new firmware. If it succeed, I call sl_FsCtl(SL_FS_CTL_COMMIT, ...). 

    If possible I'd like to keep this, as it's much simpler/lighter than the whole ota lib.

    Does the bootloader automatically rollback only the file opened in bundle mode?

    3: Failsafe, secure, public write

    4: Usefull verification indeed... I was only looking at this link which does not show the latest one http://www.ti.com/tool/SIMPLELINK-CC32XX-SDK

    I'm downloading the latest one there now:http://www.ti.com/tool/download/simplelink-cc32xx-sdk and will confirm whether it helps. 

    (Is there a way to be informed when a new sdk is released?)

    Best regards,

    Cédric

  • I confirm that the same thing happens with sdk 2.40.02.00 and CC3x20 service pack sp_3.10.0.5_2.0.0.0_2.2.0.6

  • Hi Cédric,

    Do you see the automatic rollback happen as expected if you bundle the MCU image? The NWP Programmer's Guide does discuss updating the host application as a bundle, but I'm clarifying internally if we also expect /sys/mcuflashimg.bin to rollback automatically when not in a bundle.

    The "alert me" button on the tool folder page should notify you when a new version is available. It may have been missed for the minor update between the 2.40 versions, but those changes wouldn't affect the behavior you're seeing.

    Best regards,
    Sarah
  • Hi Sarah,

    I have tried to open the file with a few combination of flags, but could not find one which is working as I expect.

    With sl_FsOpen(FW_FILE_NAME,(SL_FS_WRITE_MUST_COMMIT | SL_FS_WRITE | SL_FS_CREATE_MAX_SIZE( FW_MAX_FILE_SIZE )), 0);
    The file does not rollback on restart without commit.

    When just adding SL_FS_WRITE_BUNDLE_FILE I get a bad flag combination error.

    Can you advise on which combination I should use?

    Thanks for the tip on "alert me", I missed that.

    Best regards,
    Cédric
  • Hi Sarah,

    I finally found all the issues.

    With the following flags it's ok.
    uint32_t flags = SL_FS_OVERWRITE;
    flags |= SL_FS_CREATE;
    flags |= SL_FS_CREATE_FAILSAFE;
    flags |= SL_FS_WRITE_BUNDLE_FILE;
    flags |= SL_FS_CREATE_MAX_SIZE(FW_MAX_FILE_SIZE);
    flags |= SL_FS_CREATE_SECURE;
    flags |= SL_FS_CREATE_PUBLIC_WRITE;

    It did not work initially because I did not call sl_stop before restarting.

    Thanks for your help.
  • Thanks for posting your solution, Cédric! I'm glad you got it working.

    Best regards,
    Sarah