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.

CC32xx OTA firmware update for application processor

Other Parts Discussed in Thread: CC3200, UNIFLASH, ENERGIA

Hey Team,

Is the CC3200 capable of over the air updates to the firmware? My thoughts were yes. I was thinking you could establish a connection to an FTP server pull down the update to SFLASH and then instruct the bootloader to load that code on the next restart. As long as the device has the correct SOP setting of 0x000 which would instruct the bootloader to load the application image from SFLASH to internal MCU RAM. Is this the correct way of thinking of this? One thing I’m unsure of is if the application processor has access to write the SFLASH?

 

Thank you in advance

-Jason

  • Jason,

    Yes, the device is capable of Over the Air firmware update.

    CC3200 ROM includes an External Serial Flash bootloader which combined with an OTA Application on the MCU can be used to implement this feature.

     

    Adnan

  • Hi Adnan,

    This is great news! Will there be an example provided at some stage?

    Glenn.

  • Hi Adnan,

    Do we need an extra EEPROM or Serial Flash for OTA aplication update?

    YK

  • Hi YiKai, All,

    In September TI will release an SDK update with example code enabling device boot with one of two firmware images stored in the serial flash. 

    There is no need to add another EEPROM or serial flash. The same serial flash is used to store the old image and the new image.

    Adnan

  • Hi Adnan,

    If we don't use external EEPROM or serial flash for application FW update, it means that we need to reserve some space on CC3200 for application FW update and it will make application code more limited. Is my understanding right?

    YK

  • Hi YK,

    The CC3200 does not contain any onboard flash, it is designed to use serial flash. This offers the flexibility of using what ever sized serial flash you would require.

    So to answer you question, I'd imagine you would need serial flash that is twice the code size + space for resources/data/config files (images, html, ccs, xml, rtf etc.) 

    Glenn.

  • Hi Glenn,

    Thanks for clarify. so, what is the max size of serial flash that cc3200 can support?

  • Hi YK,

    According to the data sheet here (see Memory section) - http://www.ti.com/product/CC3200/datasheet/detailed_description

    The CC3200 has been verified to function with up to 128Mb/16MB serial flash, which should be enough for code and resources. Can anyone from TI confirm this is the upper limit, as it isn't exactly clear?

    If you need more space, for example to store video or audio then the CC3200 also has SD/MMC peripheral support.

    Glenn.

  • YK, Glenn,

    Yes, 16MB is the upper limit as we support 24 bits addressing.

    Shlomi

  • Hi Glenn and Shlomi,

    Understand and Thanks!

    YK

  • @Shlomi

    A question which goes into same direction: When you select a certain (serial-) FLASH (with SPI), they offer commands to read/write/write-enable data. When you have smaller ones (below 64 KBytes), they need only 2 bytes as address, bigger one 3 bytes (for the above mentioned 24 Bits). Does the ROM use a certain command set (which the SPI Serial-Flash obviously must support to work)? Or does it even support multiple sets, e.g. when the first one is not working another one is tried? I assume, because it is in ROM, it cannot be updated via patches, so offered functionality is fixed. Is there perhaps a list of supported/suggested devices of different size?

    Does it only support serial FLASH or also serial FRAM (which perhaps have a bit different command sets, because they are faster, don't need ready bits, don't know if in general backward compatible to serial FLASH)?

  • Hi Martin,

    I believe most of this is answered at the following link, at 5.8 Memory - http://www.ti.com/product/CC3200/datasheet/detailed_description

    This details the following:-

    • The command set that the serial flash must support
    • A list of serial flash devices verified to work with the CC3200

    Glenn

  • Thanks Glenn,

    Just to add up, the command set applies to all kinds of serial flashes. It may be confusing but the 24 bits addressing implies a maximum size of 16MB but lower capacities are supported using the same command set. Please note there is a minimum required capacity so 64KB in your example will not be sufficient.

    Shlomi

  • Hi,

    I need to implement OTA flash upgrade. Is there an sdk example of how to do this? I would use tcp to download the

    image...how would I tell the bootloader which image to load?

    thanks, Tom

  • Hi Tom,

    We will release an OTA SW library by Nov 15th.

    Thanks,
    Alon

  • Best news in a very long time!!!!

    now we only need some progress on support for IPv6 and functionality like:

    getaddrinfo() & getnameinfo() and the supporting functions like get????by???? (substitute host/serv/name/addr).

    Any possible good news on these?

    André 

  • Hi Alon,

    I see that TI has released SDK for OTA. Are there any example codes available?

    I tried searching but am unable to find any yet.

  • Hi Ankur,

    I have it downloaded. I think I was not clear enough in my post. 

    I'm specifically looking at any example codes and documentation about how to use OTA on cc3200. 

    In the SDK, there is a service pack bin file, but I'm not able to locate any examples.

  • I found the Documentation for OTA Update, looks like application note for both bootloader and OTA library are bundled together in this document. 

    I found some information missing, I'd suggest its a good idea to update the app note. 

    In section 3.2.1.2, It doesn't imply that image1 has to be OTA update example binary. It took me sometime to figure out that OTA update binary has to be written to get the output as mentioned in the consecutive sections. 

    Here are some of the implications that I made (correct me if I'm wrong)

    -> There can be two images one factory reset and other is updated one, in this case, to update the code, MCU will first have to jump to factory reset image and trigger update (since only two images can be maintained on the storage). 

    -> Other option is there is no factory reset (image1 as active image) and whatever is the inactive image(say image2), that will be updated with new image and after commit, system will boot using image2 and image1 will become inactive image. So in future updates, image1 location will be updated and this will go in a loop. 

    Another question I have here is, since memory once allocated to an image, cannot be changed over the air, so we should allocate a maximum size using "maxsize" while writing through uniflash. What is a good approximation for that value?

  • Hi Shatuddha,

    Thanks a lot for your feedback.

    Please see below details for your specific queries.

    1. Regarding section 3.2.1.2 point 8 : We will add another step after this like "Set  /sys/mcuimg1.bin or /sys/mcuimg2.bin  URL to point ota_update_os.bin or ota_update_nonos.bin" located inside example\ota_update

    2. If you start with option of retaining a factory default image "/sys/mcuimg1.bin" always. mcuimg1 brings in mcuimg2 via OTAU. Further mcuimg2 brings in mcuimg3 via OTA and then for further updates mcuimg2 and mcuimg3 start replacing one another for every OTA update. Note that /sys/mcuimg1.bin is always retained and never overwritten.

    3. If you start with option of not having a factory default image . You would program /sys/mcuimg2.bin as the default image. Further mcuimg2 brings in mcuimg3 via OTA and then for further updates mcuimg2 and mcuimg3 start replacing one another for every OTA update.

    4. Max file size to choose would depend on the application, but a reasonable choice would be to go with 256 KB which matches the MAX RAM size available.

    Thanks and Regards,

    Siddaram

  • Hi Siddaram,

    Thanks for your inputs. 

    Another underlying assumption is that Wireless credentials for access point are already stored in the NVMEM and cc3200 is configured for autoconnect. 

    With the application note saying to format and then load the images, all this information will be lost. 

    Moreover I'm wondering, if I make OTA_update as factory default, how will my system ever connect, considering the fact that right in the beginning there are no wifi credentials stored. 

    OTA_update example should have been merged with wlan_ap or provisioning app, that would make more sense to me. 

    Or am I missing something?

  • Alright, sorry my mistake. There is a connection part from STA to access point.I missed that whole things in first go.

    But somehow I'm still not able to get through. In the terminal, I see Wifi status as "connecting..." and it never proceeds from there.

    I'm not able to figure out what am I doing wrong.

  • I was not able to go ahead with ota_update example, so I ported OTAupdateTask method into energia, where I have rest of my code. 

    I know I need to make back to back calls to sl_extLib_OtaRun. On my first call, it returns with 0, i.e ota_stat_continue. But when this function is called 2nd time, it never returns. There is no way to debug it and looks like I'm at dead end.

  • Hi Shatuddha,

    This is regarding your observation " I see Wifi status as "connecting..."" . I am assuming you have configured  the SSID_NAME as per your AP. For the OTA update example You don't need any network credentials to be present in the SFLASH. Please check if your code is able to go past the below line in main.c

    lRetVal = NetWlanConnect(SSID_NAME,&SecurityParams);

    Thanks and Regards,

    Siddaram

  • Hi Shlomi,
    Can you confirm if this 16MB limit is the total size of the Flash, or only the file size limit. The datasheet (5.8.1) indicated up to 128 files and the maximum file size is 16MB. Does that mean we can use Flash larger than 16MB?

    Thanks,
    Angelo
  • Can anyone confirm this question about Flash size? There is some debate here about the meaning of the data sheet information, which doesn't seem to match what's said on the forum.