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: Application Update using TI Bootloader

Part Number: CC3220SF
Other Parts Discussed in Thread: UNIFLASH

Hello,

I am using CC3220SF for data collection and Tx/Rx with a local server which is not connected to the internet. I am planning to have a OTA update of my application through this local server.

Through the controller TRM I gathered that the for every MCU reset, the bootloader first checks internal flash and then sFlash.

I even read that bootloader checks sFlash only if theres a SoP trigger. Is there any way through which I can make the bootloader check sFlash without external trigger?

so that if there is a new application in sflash it can be read and written over to on board flash. I have gone through the OTA doc from swra10a.pdf but since the device is not connected to internet that approach was not feasible.

  • Please refer to LocalOta example which uses the CC32xx internal HTTP SERVER to get the new image from an HTTP client (e.g. mobile device or laptop) on the local network.

    Basically, if you overwrite the "sys/mcuflashimg.bin"  with the new image, after reset the new image will be identified (by the boot loader) and executed. You will need then to commit it or else, it will revert to the old code.

    I strongly recommend you use the uniflash to create the OTA image TAR file and parse it in app through the "OtaArchive.c" (as being done in the local OTA example).

    The OTA document you referred to is still a good source of info. Just focus on the device side and ignore the operation on the cloud.

    br,

    Kobi

  • Hello Kobi,

    I looked at the local_ota example project and this approach may not solve my problem completely as i need to use a browser to update the application firmware.I have come up with an alternative approach where my main application will fetch the new application file using Wifi Rx and store it into external flash. If I call the MCU reset now I assume the controller will automatically read the new application in external flash and save it to internal flash and run it. Do you foresee any problems with this approach?

    My query is

    1. From TI OTA reference docs, the OTA was done using http/https protocol, Is there any limitation on the type of protocol used to transfer the application file or it can be transferred using any of the available wifi protocols?

    2. What should be the format of the application file to be stored in external flash for the above to work? and any constraints to be taken care of?

    3. Also should I need to store the application into "/sys/mcuflashimg.bin" only?

    Regards,

    Bijoor

  • Hello Kobi,

    Waiting for your reply.

    Bijoor

  • you don't need a browser. You can do the same with an application that communicate using HTTP. The client app basically needs to send a POST request ("/ota") with the TAR file (to start the OTA). It can use GET requests to poll the device status.

    1. there is no limitation on the protocol, but the HTTP is the standard for such and is the only protocol we use in our examples (as a client in the Cloud or as a server in the Local OTA).

    2.Both the local OTA and cloud OTA are based on a the TAR format as is created by Uniflash. We recommend using the this format for the OTA image as it provides full image authentication and enables you to work with existing code from the OTA library.

    3.  The MCU Image ("/sys/mcuflashimg.bin") is one file within the OTA TAR file. You can build a TAR file (using "Uniflash/Create OTA") that only contains the MCU image.

    Br,

    Kobi