• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 31 subscribers
  • Views 2574 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Over the Air Firmware update for Tiva C series Micro controller

Dinesh K M
Intellectual 380 points
Other Parts Discussed in Thread: CC3100

Hi ,

We are planning to develop a product which uses Tiva C series Mircro controller(TM4C129EN) and CC3100 Wi-Fi module. We need to do over the air update for the host MCU (Tiva C series). Do you have any sample code for demonstrating this? This WiFi module CC3100 is connected to host MCU through SPI interface.

We hope that we can define a protocol for receiving data at host MCU and we can update the flash while receiving the packet itself after packet validation. But we had some confusion on the following items.

1) Development of Boot Loader : As per our understanding, we can not use the boot loader in the ROM for this purpose. So we need to write a small boot loader & which is to be stored in flash memory. Is this possible?

2) We planned to divide the Flash memory to three like Boot Loader, Image1 & Image 2. Boot Loader will check for some boot config parameters to decide which image to be loaded and then load corresponding image (image1 or image2). If image1 is loaded then next update is to be done on image 2 area and after successful update, change boot config parameters also for loading image 2 in next restart.Please check this logic is OK or not.

a) is this possible to load image1/image2 from the custom boot loader exists in flash memory? What is the mechanism for this?
 We got some information regarding the boot loader in ROM but we think that this information is not suitable for our purpose.


Please get back with your comments.

Regards,

Dinesh

  • 0
    TI__Guru**** 244380 points
    Hello Dinesh

    While an OTA TI Design is being planned for TM4C129x+CC3100, it would not be available any time soon.

    1. Yes, it is possible and the TM4C12x series of devices have code examples for Flash based "customizable" boot loaders in TivaWare. Please do read the Boot Loader User Guide document.
    2. Yes, it is possible. Please look at my comment #1

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 380 points

    Hi Amit,

    Thanks for the support.

    We have gone through Boot Loader user guide document & we got some idea about the flash based boot loader. But it will be helpful if we get any code sample of boot loader. Would you please provide the same?

    We checked this in internet and found some code samples but we could not understand how boot loader pass the control to application and we need to know about who will copy the application code from flash to SRAM for execution. We couldn't understand these details. Would you please help us for this?

    We found the start up code in startup_ccs file and Reset handler(ResetISR()) is defined in this file. We also couldn't understand how startup code will pass control to boot loader? It will be helpful if you can share these types of information.

    As per my understanding, our boot loader needs to check only a boot config (a memory location in flash memory) and based on that load the application in a particular address (image1 or Image2) and there is no need for firmware update support in boot loader. I hope this can be achieved in our boot loader. Please comment about this understanding.

    Regards,

    Dinesh

  • 0 in reply to Dinesh K M
    TI__Guru**** 244380 points
    Hello Dinesh.

    The TivaWare has examples for flash based boot loaders. This are kept in the respective directories for the EVM or LaunchPad under examples/boards and start with the name "boot_". Note that you should look at the examples which have bl_config.h

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Along w/following Amit's guidelines - our firm has found it best (always) to "first" perfect the "wired" bootloader.

    When this step is "skipped" it becomes a "crap-shoot" to identify the (near certain) failure as "OTA or BL" caused.

    As KISS proves (repeatedly) "Haste indeed makes Waste..."

  • 0 in reply to cb1
    Intellectual 380 points

    Hi Amit & cb1,

    Thanks for your support.

    We will check the available boot loader code and get back if any doubts exists in this.

    We are not plan to do firmware update (OTA) from boot loader and boot loader is for taking a decision that which image is going to load Image1 or Image2.

    If Image1 is loaded and then firmware update will be done on Image 2 location in the flash memory. So I think wired boot loader is not needed in this case.

    Regards,

    Dinesh

  • 0 in reply to Dinesh K M
    Guru 47900 points

    Dinesh K M said:
    firmware update will be done on Image 2 location in the flash memory. So I think wired boot loader is not needed in this case.

    Do you not stray (unusually far) from the herd - in this quest?  

    Amit has first suggested boot-loader as a resource - I've seconded.

    As a long-term RF/Radio guy - (ham, military & commercial RF design) I "know" RF to (always) be suspect - never as robust as wired...

    Mastering the suggested "Wired Bootloader" builds your understanding & confidence.   OTA - minus that earlier (learning) - not so much...

  • 0 in reply to Dinesh K M
    TI__Guru**** 244380 points
    Hello Dinesh,

    I strongly second cb1's point. The boot loader should be in charge and not the application firmware. What if there is a failure during image 2 download, the application may not recover itself with a corrupted image 2 and the mechanism of a boot loader should still survive to get a fresh copy.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Point very soundly delivered Amit - good that.

    Brief, RF "Command/Control" broadcasts are likely to, "Get thru."   Long code updates (assumed) most always "over-challenge."
     
    Such OTA pioneers (like past in the U.S. west) are recognized by their bloody, arrow-strewn bodies - littering the (otherwise) pristine (bootloaded) landscape...