OTA Update Tiva C and CC3100

Hi Glenn,

No, for this combination there is not an example available. But if you noticed, there is an bootloader application available in Tiva, so you can use that as a info base to develop a new one, tweaked to your needs. I think you will have a lot of work to do with that.

Regards, 

Petrei

Thanks Petrei,

I have noticed there are a few examples, but none are anything like what I am trying to do.

With the TM4C123G, I notice there is USB bootloader example, which is very different to OTA.

With the TM4C129, I notice there is a Ethernet one, that uses a TCP/IP stack, which is not needed for the CC3100, as it has its own TCP/IP stack

I did try and begin the process and was having trouble even knowing where to start, having never done a bootloader before. I know this will be a common request in the not too distant future...so was hoping there was something!

Glenn.

Hi,

Yes, you are right but you are the first one to walk on this field - although some others could think about the same feature.

I did not analyzed the whole problem, think the UART interface would be good to start with (I do not know what interface did you used in your application). But something special should be in place here - the wireless communication inside the bootloader (through UART for example) and of coarse the management of its parameters - poosibly an common zone between both applications.

In Tiva you have a .pdf doc describing the bootloader. Take into account the chip itself has a ROM bootloader.

Petrei

Not sure I follow your recommendation regarding the use of UART.

The CC3100 communicates with the Tiva C using either UART or I2C, but this is not something you need to be aware of, as you use the CC3100 APIs to work with the CC31000.

The CC3100 also has an external serial flash and you work with this using the FS API, so I wonder if first copying the updated code to this external serial flash (using the FS API) and then starting the bootloader, by again retrieving the update from the external serial flash may be the way to go.

The way I would want to update would be that my App downloads the update from the Internet, and then sends the update to the device, and then the update process would begin to run. And it needs to be 100% successful.

As you can see, this really needs to be thought through, and since I have no previous experience with a bootloader, I really need opinions from experienced people like your self :-)

Glenn.

Glenn,

If "it needs to be 100% successful" then your design will have to tolerate sudden interruption of the fw upgrade process at any time. There can be two kind of interruptions: wireless connectivity loss and power loss.

It's easy to handle loss of connectivity. Just download the whole image before burning it to flash. Although a buffer storage of enough size (perhaps separate Flash part) will be required. But it's not so easy to reliably handle power interruption event as it can happen in the mid-time of flash programming.

Anyway in the straightforward approach you will have to implement a full-blown boot loader. That adds complexity and, which is more important, does not guarantee your 100% rock solid goal achievement even in theory in case the requirement is the boot loader shall be also OTA-upgradeable. The 129x MCU family facilitates some hardware assistance in that regard (the Flash Mirror Mode feature) but the 123x does not.

On the other hand, the MCU already has boot loader in its ROM. After all, you paid for that feature so why do not take advantage of it? The other good facts are:

• The CC3100 does implement TCP/IP stack internally so relatively small code (the host driver) is required on the MCU side.
• With the CC3100 part, TI offers a great bonus in form of reference implementation of the mentioned host driver, which is available for free in source code so it can be easy ported for any suitable MCU.
• The host driver can be compiled with TINY_DRIVER directive that further reduces its memory footprint.
• The CC3100 has user area in its on-board EEPROM.

That suggests another approach. Improve your design with hardware boot loader. I mean a tiny auxiliary MCU (cheap 8-bit one will be enough). Port the host driver for that MCU so it can communicate with the remote server via CC3100. With that setup the firmware upgrade process can be like this:

1. The application checks if new firmware version is available at the remote server. If that's the case, the application writes the session initiation data (e.g. server IP address and port, security parameters, device ID, serial number, firmware version, encryption key, etc.) to the EEPROM on CC3100.
2. The application commands the AuxMCU (e.g. using dedicated GPIO pin) to start firmware upgrade procedure.
3. The AuxMCU acknowledges the procedure is started.
4. The application releases SPI interface to CC3100 and passes control to the ROM boot loader.
5. The AuxMCU instructs the ROM boot loader (e.g. using UART or SPI) to erase the Flash block where the vector table is located (as a precaution to prevent the 123x MCU from starting the application image again in case of sudden POR event).
6. The AuxMCU takes control of CC3100, reads the session initiation parameters from the EEPROM and establishes connection with the remote server.
7. The AuxMCU downloads block of new firmware image from the server (for convenience the block size can be made equal to Flash block size (that is, 1KB for 123x MCU).
8. (optional) The AuxMCU decrypts the block.
9. The AuxMCU sends the block to ROM boot loader (e.g. via UART or SPI).
10. The ROM boot loader programs the block to Flash.
11. The steps 7 through 10 repeats on block by block basis until the last block is programmed.
12. The AuxMCU resets the Tiva MCU starting execution of the new application image.
13. The new application checks its integrity and acknowledges for AuxMCU (e.g. via GPIO pin) that it's up and running.
14. The AuxMCU receives the signal and considers the job is done.

Something like this. After all, it's quite common to use auxiliary MCU in ARM-based designs (e.g. for power control).

---

regards,

    Igor

Hi Igor,

Thank you for your comprehensive answer to my post. Unfortunately adding an additional MCU is not possible, both due to cost and effort required, I am one person who has developed both firmware and mobile apps and design.

Regarding my statement of 100% reliable, the network disconnection is no problem, as the CC3100 requires/comes with serial flash, so as you suggest, this will not be an issue. So the power interruption is the main concern, do you believe there would be some way to have a reset to latest firmware on serial flash by holding down a button on re-power for example, and then it can obtain an image from the serial flash? (It would require the use of the CC3100 SimpleLink API's to perform this task, as this is the only way to access the serial flash connected to the CC3100).

Glenn.

I remember a friend programming a TM4c123 launchpad by bluetooth. He had a bluetooth pen on the pc and a bluetooth receiver that interfaced with the tiva by UART. And he programmed it that way. I will try and ask him how he did that.

The CC3100 interfaces by UART right?

Also, do you need to update the entire flash (excluding the bootloader) or just a piece of it?

Hi Glenn,

No problem from requesting to power cycle or/and to press and hold a button. A fully automated procedure usually looks more attractive but I presume you know about certain specific reason in your project to upgrade firmware in a user-assisted way.

As for serial flash, I think you've noticed that what I've previously posted is not entirely correct. This is because I have more experience with CC3000 module (that has on-board EEPROM) while CC3100 indeed requires external serial flash part. But there are some indications a CC3100-based module (CC3100MOD) is on the TI's roadmap and sooner or later they'll come up with something. Most likely that module will have on-board serial flash. Guess about the size. So the chances are the TI-provided flash is not of enough size to accommodate the firmware image. From that point it'll be more future-proof approach do not share flash with CC3100 using dedicated part instead.

Next, consider power interruption event. When Vcc is slowly going down at the moment the flash is busy doing physical programming, some magic things can happen. It's not designed to operate in such condition so the chances are the internal programming engine went crazy resulting in corruption of a not targeted block. In a shared flash design that can result in CC3100 stopped operating and this is another reason why a dedicated flash approach seems more safe. The alternative is to improve power design implementing early low power notification in hundreds ms before start of Vcc dropping.

So I think if reliability is your concern then additional hardware parts would be necessary anyway.

---

regards,

    Igor

Glenn Vassallo said:

Unfortunately adding an additional MCU is not possible, both due to cost and effort required

May I (very) strongly disagree?     You've a wonderful, skilled, caring resource in Igor - not following his advice subjects your project to great peril.

As a small tech firm owner - I'm aware of the "desire" to constrain cost, size, development effort.      And - as we often sell to even smaller firms - I have long noted that (most)  - who bind themselves to such (unyielding) judgments (i.e. not possible) - almost always, "do not succeed."     

The only thing certain is that you "must" be flexible - heed logical & experienced advice - and follow "new suggestions/findings" rather than stick to a, "premature & flawed plan!"      Might that describe yours - we don't know - but unless you've a "locked-down contract - to that exact spec" I believe "not possible" is mistaken.

Let the record show that I (past) co-founded tech firm - built Sales to > 17M (USD) w/in 4 years - and "change and adaptation" were near constant!      

"Not possible" - offered here w/out any (real) detail nor justification - may better describe "end results" - should Igor's kind, knowing guides be bypassed...

Glad to hear from you again, gentlemen!

Glenn Vassallo said:

I am curious, has there been any examples developed which show how to do OTA updates for the Tiva C and the CC3100?

This has to be a requirement of many applications. 

Igor and CB1,

All respect due, you guys are superior engineers with many more years experience than me.

I have read your advice and thank you for it, all very useful and certainly things to consider.

But it still does not answer my question, on whether there is code available to demonstrate how any of this should be implemented.

There are commercial concerns to consider, clients only have so much they can invest in a project, this includes not just the hardware but most importantly the firmware. For a small company catering to a small market, the cost difference between a custom solution with an additional MCU that needs to be developed from the ground up with no example code is vastly different to one that is developed using existing development boards with example code that shows exactly what to do. This often is the difference between developing a product or not. I am also seeing larger companies being risk adverse with new product categories, even when there is lots of potential. 

I am sure in the mature product categories you are working in, where there is lots of money to invest and teams of developers, none of this is an issue. But I am usually working on new product concepts, in unproven markets, where people are just taking the first steps, and cannot risk it all so early.

Glenn.

Glenn Vassallo said:

and cannot risk it all so early.  

And - by sticking to a "too early" (prior to receiving Igor's detailed advice) "too limited," (Not possible) mind set" - does that not indeed, "Risk it all!"

My findings - in dealing with 100's of clients - over 2 decades - "Trying to optimize, hoard cash, early on" - ticket to disaster!

Clearly you've not fully anticipated many of Igor's powerful points - and surely many more will arise.     If you retain so "closed/frozen" design structure - in which "Not possible rules" such design will be unable to efficiently expand & adapt - to meet, "newly discovered challenges" - and they lurk everywhere!

Neither Igor nor I intend to be "mean" - locking yourself in - to design, size, cost parameters - (before) you had many (avoid all) critical facts - is severely flawed - and "success" under those conditions - drives toward zero.

In my past major success (co-founding, taking firm public) we recognized our limitations - had a major, overseas powerhouse provide our production - and focused almost entirely upon client "comfort, convenience - and best possible (highly adaptable) feature mix!     I cannot recall our use of, "Not possible" - clients are (rarely) pleased by self-limiting attitudes...

Finding a niche product - much mated to your capabilities & interests - and within your business & financial "reach" - never proves easy.    Flexibility and accommodation of the unexpected proves critical (that's happened here - has it not) and you must do all in your power to avoid limiting decisions - especially those which seem, "not possible."

Read every word - (I'm very well paid to do just that - advise tech firms) - wrote what I believe you (and others) need to hear - (perhaps) not what you wanted to hear.  

At some future date - when you're bit more open/receptive - maybe we'll continue.     "Attacking" your helpers may not prove, best/brightest - especially when they speak from (some) depth of (highly related) experience...

Igor's guidance is terrific - and your "closed/stunted" system will not be able to accommodate the (many) things your (very) preliminary investigation has (thus far) identified!      And surely - many more await - just around the bend!      

Your design must embody the flexibility to accommodate new findings - casting as "concrete" too soon (as I "strongly" believe you have) most always proves, "Ticket to disaster!)      You must consider raising the level of, "flexibility & accommodation" - even if (very preliminarily) judged, "not possible!"