• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 39 subscribers
  • Views 936 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3200: OTA Rollback/Commit & Bootloader Questions

ihearth2o
Intellectual 780 points
Part Number: CC3200
Other Parts Discussed in Thread: UNIFLASH,

Hello,

I've read through the OTA App Note and other E2E posts and have some questions about the bootloader and committing process. I think they are pretty trivial questions but I can't seem to reach certainty on them, would love some input.

  • Do we need to change anything in the default TI Application Bootloader to enable rollback functionality? 
  • Should we test upon runtime of the new user application? Then send the COMMIT flag if the test passes? 
  • After sending the COMMIT, do we perform a reset? Or only if the test fails?
  • Does this mean the "test" will run at runtime each time? Or, how do we ensure it does not?
  • What does checking the "rollback" box on Uniflash do? 

When we perform the OTA, we run a CRC, then switch to the new image if the CRC is successful. We currently are not calling any sort of "commit" but overall it seems to be working fine. I was advised the rollback should be added though so I'd like to make sure I do it right.

Thank you!

  • 0
    TI__Guru 64455 points

    Hello,

    • Do we need to change anything in the default TI Application Bootloader to enable rollback functionality? 

    [Shlomi] rollback means that a 2nd "copy" of a file is stored on the serial flash. Basically, when a rollback is used for a file, writing to it is applied on the older copy such that the newer copy becomes the older one. In case of power fail during write, the older copy becomes valid instead of the "corrupted" one. With cc3200 file system, you cannot choose via API which copy to use. It is done automatically. With TI application reference, the mcuimg which is the MCU binary appliation is a special case where no rollback is used. The reason is that the application bootloader is responsible on checking which image to load and execute (mcuimg1, mcuimg2, mcuimg3) so the rollback functionallity is implemented on the application bootloader rather than inherently on the file system. This has been changed with the newer cc3220 generation.

    • Should we test upon runtime of the new user application? Then send the COMMIT flag if the test passes? 
    • After sending the COMMIT, do we perform a reset? Or only if the test fails?
    • Does this mean the "test" will run at runtime each time? Or, how do we ensure it does not?

    [Shlomi] to all 3 questions above, let me explain the process.

    When download is done, OTA app sets to TESTREADY and reboots.

    The application bootloader tests the TESTREADY flag and when set, moves to TESTING and executes the latest downloaded image.

    The OTA app test for the new image (as in your case it can be CRC but you can for example just try to connect to an AP and run ping). If it is OK for you, send a COMMIT. If the mode is TESTING and you send a COMMIT, there is no need to reboot as the new image is already running. If COMMIT is not set (since you failed your test), a reboot would mkae the older image to be loaded and executed, hence doing "rollback".

    • What does checking the "rollback" box on Uniflash do? 

    [Shlomi] as explained on the 1st item, rollback creates another copy of the file which is toggled with each write operation.

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Intellectual 780 points

    Thank you, Shlomi.

    Is "rollback" option on Uniflash mandatory? I am currently programming mcuimg2 and mcuimg3 manually. Should I just change to programming only mcuimg2 and select rollback option? Will this take any extra space? Technically I do not need to check this rollback option right?

    We are not using mcuimg1 (factory default) due to space limitations.

    During runtime there are some conditions under which we will reset the MCU. Will it run the COMMIT test again and send a failure in case if (for example) internet is coincidentally out at the same time? Can we only run this check once somehow?

    Last question, if we are already doing a CRC check upon download, do you think it is necessary to utilize this rollback mechanism? If CRC fails we simply do not reboot and do not change the image pointer.

    Thank you!

  • 0 in reply to ihearth2o
    TI__Guru 64455 points

    Hello,

    Since on CC3200 there is no real rollback on the file system and this mechanism is implemented in application level (using the application bootloader), I do not see a reason in using rollback at all. It would occupy twice the space and wouldn't be useable.

    If you reboot while in TESTING mode, you automatically revert to the older image (i.e. rollback). It is because the bootloaderinfo file is not updated and the ACTIVE image remains unaltered.

    Again, some kind of rollback should be implemented as I see it. But, it is up to you.

    Regards,

    Shlomi