Updating firmware - can I do it using only 1 mcu and flash?

Hello Lacho,

Clarifications

1. The sflash.c is a PC side utility for serial download. You can use the concepts from it to implement an external master to transfer the code

2. When the main MCU goes into UART bootloader, it is the device/PC that is running sflash that communicates the flash image.

To implement what you want to do with a single MCU, it would be advisable to have the image in an external flash with CRC such that when there is an issue during the external flash image being corrupted, the CRC checksum will catch it. In case the CRC checksum passes, you can use a flag in the external flash to indicate to the MCU that the image is a valid image and then prepare the internal flash copy. Again the checksum is checked for the internal flash such that if it fails then the boot loader firmware will re-try the external to internal copy. If the internal flash check sum passes, then the boot loader will mark it as a valid image and jump to the new image.

Regards

Amit

Hi Amit, thanks for the quick reply.

Ok, so I need to put the firmware file into the flash + a CRC checksum.

However I don't understand how to the make mcu's bootloader perform the crc check and copy the file from flash? I can't use ROM_UpdateUART() in this case, right?

Can the original bootloader perform this update using its standard API or do I need to customize it - to perform the crc check and copy from flash? 

Oh ok, so I'll need to put some other bootloader. I'll check again the examples - this is boot_demo1/2, right?

And one more question - so by default, with the standard tivaware bootloader - it doesn't get executed everytime upon reset, right? It runs directly the user app?

So the new bootloader will need to get executed everytime upon reset, then check if firmware is ok or update is needed, and then switch to the user app?

Hello Lacho,

The Flash Based boot loader is C:\ti\TivaWare_C_Series-2.1.0.12573\examples\boards\dk-tm4c123g\boot_serial.

The boot_demo1 and 2 are the application code that the boot loader will flash and run.

Regards

Amit

Ok, thanks!

Ok so I understand there are 2 bootloaders that TI offers - the default ROM bootloader (documented in the tivaware docs), and the flash bootloader (separate document: http://www.ti.com/lit/ug/spmu301a/spmu301a.pdf).

However what I wanted to make - the bootloader to autonomously download the firmware from external flash - doesn't seem possible with either of them. If I understand it correct - it still needs another "host" chip or a desktop computer to send it the firmware using the specific protocol.

So the way to make that "1 chip update" would be to make a new bootloader.

Or just add another chip for this purpose to play as the "host" and use the existing bootloaders.

I'm still not sure which road will be better for a newbie soul like mine, but I'll probably go with the "second chip" option.

Our small group has followed this - and have never understood the motivation for, "Using only one MCU & flash."

If only the MCU is to be deployed (by itself) does that not imply that you "know" - at that moment of deployment - what each/every (future) update will contain?  Is that true - can that be true?  Are no changes/improvements or "fixes" to be allowed?  How do you "predict" each/every one of them?  Is not it likely - that at some point in time - this single MCU is located remotely from you?  How then - minus a 2nd MCU or PC - do you input your updated firmware?

In many years @ this/other tech forums - this 1 MCU desire has escaped my note.  One suspects there's good reason...

Hmm that's interesting... I don't really know if this 1 mcu approach is a good one.

It's just that when I first started scratching my head over this (not knowing anything about bootloaders) - it sounded like the obvious thing - mcu gets file over bluetooth, saves it to external flash and then upgrades itself with it...

And there's actually one more reason I wanted to do it like this - because I got scared reading about various product certifications - FCC, CE, etc. (if it ever reaches this point of course) . To me it sounded like the more hardware you have - the more things could possibly go wrong - cause EM noise, fail certifications, etc. So at first I didn't want to have one more chip to worry about (don't know really how "worrying" this may be).  But if this is not the usual/preferred approach - ok, that's good to know (that was one of the reasons to ask here :)). 

And I was actually wondering how come I didn't encounter anybody using that "1 mcu" approach :) So indeed there should be a good reason for that, that may be currently beyond my head, but I could just take it for being truth :)

So - I'll go with a second mcu. Thanks!

cb1- said:

 Is not it likely - that at some point in time - this single MCU is located remotely from you?  How then - minus a 2nd MCU or PC - do you input your updated firmware?

It's (should be) getting the firmware over a bluetooth connection, so the PC (or another host) is not really needed. 

Lacho Tomov said:

getting the firmware over a bluetooth connection, so the PC (or another host) is not really needed.

Really?  Might you describe just HOW you get that "firmware" into the transmitting, Bluetooth? (IBM 80 column cards are a bit passé)

My friend - clearly - some where/place there MUST be a "dreaded" 2nd MCU (or PC) to pass the info to your (stand alone) single MCU - even via your esteemed Bluetooth! 

And - if you believe any RF link to be stable, secure & at critical times robust - then your RF experience is unlike mine.  (ex U.S. Army Signal Officer, Amateur Radio Extra License @ 16, FCC First Class RadioTelephone w/Radar Endorsement (17), and multi-year vendor to various defense contractors...RF & other...)

Solutions - strictly "in the mind" - may not prove so simple/realizable in the real world. 

cb1- said:

Really?  Might you describe just HOW you get that "firmware" into the transmitting, Bluetooth? (IBM 80 column cards are a bit passé)

My friend - clearly - some where/place there MUST be a "dreaded" 2nd MCU (or PC) to pass the info to your (stand alone) single MCU - even via your esteemed Bluetooth! 

Hmm it's a mobile phone that's sending it... so yeah there is a second mcu, but it never crossed my mind that it could be used to communicate with the bootloader... that's an interesting thought :)

But actually I don't think that would be very easy, because the flash bootloader expects communication from spi, i2c, ethernet, usb, uart... can't make the phone to use any of those (and over bluetooth)... Does that make sense?

I'm unaware of any MCU (by any vendor) which (natively) can receive/decode/process Bluetooth directly.  This vendor (and others) produces RF ICs which may receive & transmit via Bluetooth - and input/output via SPI, I2C etc.  Thus such extra IC - and its support components - and its command/control software - all add to your effort.

Our small tech group NEVER attacks a project which is so complex - so demanding - without a good attempt at simplifying via KISS.  Spend any time here (this forum) and you'll note the rarity of 1st time users "instantly succeeding" with basic, wired bootloader!  Now throw Bluetooth - and possible interference to the mix - ticket upon the Titanic, anyone?  (they're discounted...)

Strongly suggest that you read/review the many documents this vendor supplies re: Bootloader.  That will give you a good idea of what's ahead.  Only after you've got that, "bullet proofed" would I even begin adding RF (of any form) to the mix.  And bring then a calendar full of "open weeks/months - and a fat wallet..."

I see what you mean and it makes a lot of sense. The way I explained it makes it sound like a really weird and crazy decision to take - why would I do such a thing over bluetooth.

The thing is that there's already a bluetooth module there and it's already working fine. The module takes care of all the complex RF stuff, supporting components, etc. So I'm not putting it there because of the firmware update, but more like "borrowing" it.

And besides, the bluetooth is pretty much the only entrance point into that device, so I don't have much choice either. And as a user I actually find this to be a really cool feature - being able to update from the smartphone. Some products do it with usb, but why bother the user with cables, flash drives, when they can update with a click on the smartphone. To me that makes a big difference in terms of user experience.

The only additional complexity that this brings is implementing the BT file transfer protocol, but I should handle it (I'm a beginner in hardware, but with good software background, besides it's nothing too complex).

But indeed I'll need more reading about bootloaders, as there are still many things unclear. 

Once again thanks for your comments, as usual they are very useful.

Lacho Tomov said:

Hello,

I'm wondering what would be a good way to organize a failsafe firmware update, possibly using 1 mcu only.

The idea - a TIVA mcu receives the firmware file over bluetooth and stores it in some external flash. Then I need to somehow put that file into the mcu - as the firmware.

I read the available docs - bootloader pdf and some application notes... From what I understand, I'll need to do that over some serial connection such as UART. I don't have USB.

I can imagine how this would work using another mcu that only handles the firmware update (please correct me if I'm wrong):

1) on the main mcu (the one being updated) I run ROM_UpdateUART() and it goes into update mode

2) the second mcu starts sending the firmware from flash to the main mcu's bootloader. I see there's an example code of sflash.exe application that handles the update protocol. So probably I should reuse that - and port it to the second mcu?

 

This way (with 2 mcus) even if power is interrupted during the update - the secondary mcu will be able to retry the update next time. So this should be safe.

However I'd like to implement that using a single mcu only. Would that be possible?

I don't understand when the main mcu goes into ROM_UpdateUART() mode - who will send the file to it? Or perhaps in this case ROM_UpdateUART() shouldn't be used?

Does it make sense to modify the bootloader to do the copy from the external flash - wouldn't it be easier this way?

Any tips and advices on this matter will be much appreciated. 

Thanks!

 

I don’t see why it couldn’t be done, it’s been done for years and still is, for many devices…

But you’ll need to write your own bootloader, to first,  as mentioned, check if you have a valid firmware, and then secondly, copy(program) the firmware form external flash(say SPI) to the internal flash.

You’ll also need a function in the firmware to download the image (from your cell phone), into the external flash, then when done, raise a flag  to indicate there’s a new valid firmware, and jump into the bootloader.

You might also read this: http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/242443.aspx

OTH, can’t you implement a virtual com port with your Bluetooth adapter(modul?). Then you could simply use the UART bootloader (slightly modified to initialize the Bluetooth adapter), and upload it with TI’s flash programmer…(but you’ll need a laptop or pc to do it).

As past el presidente stated, "Depends what "is" is." 

Or "what" constitutes that 2nd MCU.  If that 2nd MCU (somewhere (perhaps disguised) in this update process/link) is not employed I'd be surprised - and expect any such methods to suffer limitations & compromise.

Love to learn "how/where" a "new" update is created/processed & CRC'ed - without use of that 2nd MCU - somewhere.  Seems a very minority "use case" (at best) and far more provocative than efficient...

marc_rir said:

But you’ll need to write your own bootloader, to first,  as mentioned, check if you have a valid firmware, and then secondly, copy(program) the firmware form external flash(say SPI) to the internal flash.

 You’ll also need a function in the firmware to download the image (from your cell phone), into the external flash, then when done, raise a flag  to indicate there’s a new valid firmware, and jump into the bootloader.

 

Yes, I was also imagining something like that. I'll probably try it and see how it goes.

marc_rir said:

OTH, can’t you implement a virtual com port with your Bluetooth adapter(modul?). Then you could simply use the UART bootloader (slightly modified to initialize the Bluetooth adapter), and upload it with TI’s flash programmer…(but you’ll need a laptop or pc to do it).

The problem that I see with this is that the smartphone will need to "speak" the update protocol, so would need to port the sflash.exe source code to the smartphone... Sounds a bit more complex than the other options. And having a PC to do it won't be very convenient in the particular case.