Author Topic: Anyone have any experience with field upgradable firmware for ARM MCUs?  (Read 13352 times)

0 Members and 1 Guest are viewing this topic.

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 593
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #25 on: November 19, 2015, 05:34:24 pm »
IMHO you should put as less functionality in the bootloader as possible (definitely no communication!). It should detect/verify a different firmware image has been loaded which then needs to be programmed into the flash.

Going to disagree.

The bootloader in my case, should have all of the routines to update the system if the main flash is entirely corrupted. This means I have copies of the communication functions in the bootloader. If the flash is missing (I ship with no code on the module) or it's really corrupted, I can still have users log in via bluetooth and update. An RMA is expensive. "Wasting" a 2-6k of ROM on making sure the bootloader can recover flash on it's own, pretty cheap.

In this case, I usually hold inside of bootloader to do any flashing, since all the code is there, I like it to live there and just reboot into bootloader from main app when an update is available. Handle it there when

So in this case, a LOT of my comm stuff is in the bootloader. The majority of it, for sure. But I'm not using a simple comm like UART. I have a lot of bluetooth and other routines going on.

For what it's worth... I am trying to not develop my main application as a "function" but rather as it's own program. So the bootloader and main application are entirely separate. Just by changing rom locations I can test both separately or together. ie; Both bootloader and application have main()s that run. Once bootloader jumps, everything is reset to the application's main.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4069
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #26 on: November 19, 2015, 06:31:33 pm »
I created the bootloader in a reversed manner as described in the first post. Which is easier to "add" to existing projects, but less robust.
It exists of a separate firmware project that is able to read from [interface] and write to flash. This application is linked for RAM space and compiles to an C array which is included in the main program.
The bootloader can be activated by user request, the chip does a software reset, reads the magic keyword somewhere in RAM from the startup assembly and copies the C array to SRAM and starts running from there, ARM can do that without a problem.

It was not ROM independent, but linked against it's target range.
« Last Edit: November 19, 2015, 06:36:09 pm by Jeroen3 »
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #27 on: November 19, 2015, 09:31:34 pm »
The bootloader in my case, should have all of the routines to update the system if the main flash is entirely corrupted. This means I have copies of the communication functions in the bootloader.
There are multiple ways of doing it.
If we agree that the bootloader shall never be updated (most robust and failsafe) then you can never update any functionality in that bootloader.
That means in your case that the way of communicating the new firmware will stay the same over the lifetime of the product. If you do find a bug in that code you are out of luck. That is why the bootloader should be as small as possible so the chance of bugs is as small as possible. The more code the bigger the chance for bugs you can never fix.
I am not saying that is wrong but it is less flexible then if you keep the communication of the firmware in the firmware it self and have a fallback if ever the firmware gets corrupted. Such a fallback can for instance be USB and you can email the encrypted firmware to the customer who had a corrupted firmware. However rule nr 1 is that during firmware update the product should never ever get corrupted unless the flash is broken. So if power fails or other things go wrong during the update the bootloader has to restart the firmware authentication, decryption and flashing. Till it finishes correctly.
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 593
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #28 on: November 20, 2015, 05:31:08 pm »
The bootloader in my case, should have all of the routines to update the system if the main flash is entirely corrupted. This means I have copies of the communication functions in the bootloader.
There are multiple ways of doing it.
If we agree that the bootloader shall never be updated (most robust and failsafe) then you can never update any functionality in that bootloader.
That means in your case that the way of communicating the new firmware will stay the same over the lifetime of the product. If you do find a bug in that code you are out of luck. That is why the bootloader should be as small as possible so the chance of bugs is as small as possible. The more code the bigger the chance for bugs you can never fix.
I am not saying that is wrong but it is less flexible then if you keep the communication of the firmware in the firmware it self and have a fallback if ever the firmware gets corrupted. Such a fallback can for instance be USB and you can email the encrypted firmware to the customer who had a corrupted firmware. However rule nr 1 is that during firmware update the product should never ever get corrupted unless the flash is broken. So if power fails or other things go wrong during the update the bootloader has to restart the firmware authentication, decryption and flashing. Till it finishes correctly.

Maybe I'm mistaken, but what you're talking about is effectively splitting the bootloader and the comms into basically just two bootloaders. If you have a comm section that doesn't get overwritten.... That's just another bootloader.

I'm saying just combine them and if you ever do have to update the bootloader (unlikely scenario, bad case), might as well do it. I have a project I'm launching with a bootloader update code that gets loaded into RAM and won't exit until the bootloader was sucessfully updated. Power loss at just the right time would be bad, but you know what, life is full of risks.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26761
  • Country: nl
    • NCT Developments
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #29 on: November 20, 2015, 09:14:45 pm »
Power loss at just the right time would be bad, but you know what, life is full of risks.
I would never implement a firmware update method which is prone to bricking the device due to a power failure during an update. This will cost a lot of money guaranteed!
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #30 on: November 21, 2015, 07:03:11 am »
Power loss at just the right time would be bad, but you know what, life is full of risks.
I would never implement a firmware update method which is prone to bricking the device due to a power failure during an update. This will cost a lot of money guaranteed!

I agree. The firmware update bootloaders I've written specifically deal with every conceivable instance, including power outage or device removal mid-update. The devices always boot first into the immutable bootloader and won't even jump to the application firmware unless the in-flash CRC is correct. In addition, any traps for stack overflows, illegal instructions or watchdog timeouts and the like always reset to the bootloader.

If all else fails, the end user can reset the device to the bootloader by shorting two exposed pads, although I've never actually needed to go to that level with any end user, of which there are tens of thousands, and that procedure is only known to me this far. Myself, yes, I've used the process many times, when testing the bootloader itself!

The cost of having to have a unit returned and repaired or replaced easily outweighs any profit margin for most consumer devices, so it is to be avoided at all costs. A full product recall would be disastrous. The amount of effort in getting a bootloader bulletproof should be significant, and that includes plenty of testing. In fact if you should probably pay more attention to the bootloader than to any other software component!
 

Offline Boomerang

  • Regular Contributor
  • *
  • Posts: 52
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #31 on: November 21, 2015, 01:51:43 pm »
... In fact if you should probably pay more attention to the bootloader than to any other software component!

 :-+
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #32 on: November 22, 2015, 08:02:39 pm »
Maybe I'm mistaken, but what you're talking about is effectively splitting the bootloader and the comms into basically just two bootloaders. If you have a comm section that doesn't get overwritten.... That's just another bootloader.
Not what I meant.
The firmware program itself takes care of the firmware update communication (intake) (being ethernet or USB or whatever) and stores it after verification in a safe place, being an external flash rom or spare internal flash (in that last case your ROM size should be >2x the max firmware size). After the firmware intake has been verified it sets some NV flag and resets, starting up with the bootloader.
The (minimalistic) bootloader sees the flag and verifies the new firmware from the location it was stored, after verification it unpacks the new firmware and overwrites the existing firmware.
After verification the new firmware was written OK it resets the flag and jumps to the new firmware.

Now incase the new firmware has a bug (for instance in the communication module) and can not be updated that is the reason the bootloader always should have a fallback mechanism to also store a firmware from a second input channel (being USB or serial or whatever) so you can email the user the new firmware and it has to update it manually.
Hope it makes more sense now.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4069
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #33 on: November 22, 2015, 09:15:02 pm »
Routers often have the option to upload a new firmware image, they usually have plenty of flash and are capable of some compression on the image.
But they also carry a ROM bootloader capable of minimal ethernet capability to use tftp to download the new image. As a last resort so you don't need to jtag the image if you've bricked it, since that takes ages.
 

Offline gmb42

  • Frequent Contributor
  • **
  • Posts: 294
  • Country: gb
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #34 on: December 16, 2015, 11:22:25 am »
Ran across an Atollic tutorial on ARM Cortex M bootloaders here, might be useful, I haven't checked it myself.
 

Offline bson

  • Supporter
  • ****
  • Posts: 2265
  • Country: us
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #35 on: December 17, 2015, 07:42:00 pm »
Encryption will only insure Confidentiality. Change one bit and the firmware is corrupt but you can not detect it on forehand.
What you also would like is to insure Integrity, you can do that by adding a secure hash aka MAC.
That way noone can change any bit without failing the integrity check and no-one can generate a fake firmware.
Integrity checking is easy, even a CRC works fine for this.  However, the real reason for encryption is keep cloners from using your software.  They can always go roll a clone board - this is easy, but the secret sauce is in the software so all the cloner gets is a generic board.  Now with PSoC's things are getting even more generic.  From an IP perspective, generic is good - assuming you protect your software!!!
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #36 on: December 17, 2015, 09:29:11 pm »
Integrity checking is easy, even a CRC works fine for this.  However, the real reason for encryption is keep cloners from using your software.  They can always go roll a clone board - this is easy, but the secret sauce is in the software so all the cloner gets is a generic board.  Now with PSoC's things are getting even more generic.  From an IP perspective, generic is good - assuming you protect your software!!! 
I understand and agree, the reason to add a MAC is to sign the firmware so that the bootloader knows that the encrypted firmware is genuine. The same way as Microsoft signs its drivers, you can find drivers everywhere on the net, they can be tampered or invested with malware, but signing prooves that it came from a trusted source.  ;)
 

Offline CypressPSoC

  • Contributor
  • Posts: 46
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #37 on: December 17, 2015, 09:56:01 pm »
If you end of using any of our Cypress PSoC microcontrollers, here's some handy examples on how to make bootloaders over UART/I2C/SPI or USB-HID:

http://www.cypress.com/documentation/application-notes/an68272-psoc-3-psoc-4-and-psoc-5lp-uart-bootloader

http://www.cypress.com/documentation/application-notes/an86526-psoc-4-i2c-bootloader

http://www.cypress.com/documentation/application-notes/an73503-usb-hid-bootloader-psoc-3-and-psoc-5lp


With our Bluetooth Low Energy SoCs, you can also have Over-the-Air bootloading over BLE
http://www.cypress.com/documentation/application-notes/an97060-psoc-4-ble-and-proc-ble-over-air-ota-device-firmware-upgrade?source=search&keywords=AN97060


hope this helps!

EDIT: I should have added that PSoC are ARM-based MCUs. Our portfolio includes Cortex-M0 (PSoC 4) and Cortex-M3 (PSoC 5) products
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf