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.

Firmware update over the air (BLE, CC2541)

Other Parts Discussed in Thread: CC2540

Hi,

I'd like to implement a firmware update procedure that would work for a BLE Peripheral running 2541 with 256KB Flash.

Since I didn't find any readily available solution, here is how I plan to go about and make it happen:

  1. Define a BLE service that will transfer firmware images from Central to the Peripheral via lots of GATT Characteristic writes (20 bytes each). While collecting all these buffers, data will be written to a few pages in the Flash memory, where they will be stored. Data will possibly be transmitted in some compressed format, and possibly signed with some hash (e.g. CRC32) for verification.
  2. Upon resetting the device, a modified version of the universal boot loader will load, recognize that a new firmware image is pending (by reading some flag stored in flash memory).
  3. Above modified boot loader will open pending firmware image, decompress & verify as necessary to some memory area, to get the raw image which can now be used as-is. On a 256KB Flash, and disregarding the UBL footprint and possibly a few more Flash pages, firmware images of up to 128KB may be used with this process if we can safely override the current firmware version. If we can't override the current version, tighter restrictions will apply.
  4. Delete previous firmware image (or possibly keep it for recovery purposes).
  5. When done, reset again and load the (new) firmware image. Run normally.
I would appreciate any feedback on the following issues:
  1. Using GATT characteristic writes to transfer data is slow. From what I read, under good conditions, effective throughput for this method doesn't get much higher than 5KBps (kilo-bytes). For a firmware image of 128KB, it will take ~25sec just to transfer the data. Is there a cleaner and/or faster way to do this?
  2. Are there any samples for bulk data transfer over BLE I can start off from?
  3. Are there any samples I can use as reference for modifying the UBL to do something similar to what I described? 
  4. What is the footprint of UBL and other management data in the flash? From what I read it seems the UBL itself takes around 5 pages == 10KB. Is my information correct? Is there any "reserved" data I'm missing here?
  5. Which tools can I use to effectively minimize the object size of my firmware images? I realize it's already pretty bare-bones, but if there are specific compiler/linker flags I can use, modules that may be removed etc. It would make things quicker.
  6. Can the process be done more effectively than I described? Any suggestions would be welcome.
Thanks in advance
  • Hi Amir,

    I haven't read the entire post of yours, but the Over the air firmware update

    feature will be part of in BLE stack v.1.3.0, which should be available sometime

    around the Christmas (there's a discussion on this topic in the forum)

    Are you willing to wait till a solution from TI comes out?

  • Igor,

    Will this new stack and OTA update work on the CC2540 with 128k flash?

  • I'm not a BLE expert exactly, but I think the answer is no, since the update is for the

    whole stack, so an external storage would be needed.

  • Hi Igor,

    I'm glad to hear this feature will be part of version 1.3.0!

    A few questions regarding that release:

    • Is there any more information available regarding the general features planned for that version ("planned release notes")?
    • Specifically for OTA Firmware update - how is it supposed to work? Is something similar to what I suggested planned, or will another approach be adopted?
    • Will there be a counterpart-SDK (or at least samples) from TI for iOS (CoreBlueTooth) or Android (some BLE library) to actually send the firmware OTA?
    Also, I would be glad to hear your thoughts on the suggestion I wrote as well, in case we'll have to fall back implementing it by ourselves.
    Thanks
  • Amir Eshel said:
    • Is there any more information available regarding the general features planned for that version ("planned release notes")?
    • Will there be a counterpart-SDK (or at least samples) from TI for iOS (CoreBlueTooth) or Android (some BLE library) to actually send the firmware OTA?

    These questions are better be answered by TI employees (I think tomorrow you'll be answered).

    Amir Eshel said:
    Specifically for OTA Firmware update - how is it supposed to work? Is something similar to what I suggested planned, or will another approach be adopted?



    It suppose to work very similar with what you described in your previous post (1-5).

    I suggest you to search this forum for OTA in BLE, maybe you will dig something up.
     

    Now, since I'm coming from the field of ZigBee, I have no any particular opinion on the "issues" part,

    I simply not familiar with BLE.

  • Oh I see.

    Thanks Igor!

  • Hi Amir,

    I am afraid you'll have to wait for the official release to obtain the details.

    Best Regards

  • But one detail that you do not have to wait for is that OTA upgrade is not possible using the 128k parts - the image being sent OTA has to be stored somewhere until it is complete and can be verified - there is no magic for that, so the 256k is needed for that storage even as the app & stack fit well within 128k.

     

  • I googled and found the industry named this technology FOTA, it seems that only two or three companies are providing solutions. 

    I've searched a page on TI that is recommended a solution for Firmware Over-the-Air Update, I tink it may meet your requirements.

    It is one of the top technology, the chip/hardware company does not provide this software by itself.