• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 40 subscribers
  • Views 304 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.

CC3220SF-LAUNCHXL: OTA-Bundle upgrade

Naga SuresH
Intellectual 560 points
Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: UNIFLASH
Hi,
I'm using the following modules for my application.
Amazon FreeRTOS -> 202107 
FreeRTOS Kernel V10.4.3
AWS IoT Over-the-air Update v3.0.0
SL Host Driver Version 2.0.1.27
Service Pack Version sp_3.14.0.0_2.0.0.0_2.2.0.7.bin
 
  

I am planning to upgrade the deployed device with the OTA as a bundle of files CC3220SF-LaunchXL.  As of now I have done only sys/mcuflashimg.bin upgrade using the OTA.  

   

Now I want to add new files to the deployed devices (deployed devices do not contain some of the new files - did not flash / created at least once).  

From the swru455m - 8.9.1 Bundle File States developers guide, I can see the following statement The file has a valid copy (meaning that the file was successfully written at least once).

   

This means at least once we should flash the device using UNIFLASH with the new files? then only bundle upgrade is possible? Please advise

  

 

And also please help me with the OTA bundle upgrade user guide / example code (step by step procedure).

  

Regards,

Suresh

  • +1
    TI__Guru 63006 points

    The statement you referred to talks about a file that was already existed by the time of the OTA update (i.e. a modification of an existing file a not creation of a new one). In such case the existing instance could have been created in factory (programming) or by a previous OTA update.

    The idea behind failsafe is that upon creation (of a FAILSAFE file) the File System allocates storage space for 2 instances of the file. One is the "operational" instance. The 2nd is used during OTA and is kept as "test" image until the user commits the change (then the 2nd instance becomes the "operational"). If the user roll-back or MCU reset is used, the bootloader will revert to the 1st ("operational" instance.

    The bundle protection trigger the reversion for the files in the bundle in case even one of the files in the bundle was not written (and closed) correctly.

    To my knowledge, AWS OTA doesn't support bundle but enables updating of the MCU image only.

    In the CC32xx SDK we have the OTA library that handles the processing of a bundle (a TAR file created by Uniflash). It is demonstrated in the OOB example and as an addon to the the MQTT_Client example in SDK 6.10 (see readme of the example for instruction to enable the OTA). In previous SDK we had cloud and local OTA examples that demonstrated the use of this (see also https://www.ti.com/lit/pdf/swra510 and the OTA documentation in the SDK).