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

0 Members and 1 Guest are viewing this topic.

Offline JoeNTopic starter

  • Frequent Contributor
  • **
  • Posts: 991
  • Country: us
  • We Buy Trannies By The Truckload
So I have an idea for a portable product.  I would like to be able to provide my customers with firmware updates for bugs or improvements to the product after release.  We have all seen this provided for many products, including the very IDEs we program with that reflash the hardware programmer device every time something new arrives on the scene.  But I personally don't know how to do that.  Obviously I could read the datasheet for the programming algorithm and include a programming circuit on the product itself (probably a second USB enabled MCU), but I know that flashing can be done with just the primary MCU in some cases because I took apart my Peak DCA75 which I have upgraded the firmware several times for since purchase and that device has only a single USB MCU (PIC18F47J53-I/PT).   I assume to do this there is some sort of bootloader arrangement.  I want to make my device with a low-power Atmel ARM MCU.  My thought right now is the ATSAM4LS2CA-AU.  Any ideas where to being so my firmware can be field-upgradable with a Windows host application over USB?

Thank you.
Have You Been Triggered Today?
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 4228
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #1 on: November 17, 2015, 09:18:15 am »
In principle, what you need to do is create a bootloader:

- set it as the primary function which gets run at start-up, ie. it provides main()
- check that the application is valid, typically by calculating and comparing a checksum
- if the application is valid, jump straight to it
- if not, configure the USB interface (or serial, or whatever other interface you want to use)
- when ready, erase the Flash sectors that contain the application code
- download code a section at a time into RAM, and copy it into Flash. If the download process isn't too fast, you might be able to write directly into Flash and avoid the RAM stage.
- when the download is complete, check the new application code as before, and jump to it

The trick is ensuring the bootloader doesn't contain or use any code which is part of the main application. You'll need to set up your Flash placement very carefully - expect to become very familiar with your linker - and may end up duplicating some functions. Ideally the bootloader and application will be completely independent of each other, so neither one ever calls any part of the other.

The easiest way to upgrade over USB is probably to use a USB-to-serial cable. You can use a UART in the MCU, and don't need a USB stack.

When the application is to update itself, have it write a magic word into RAM and then reboot the processor. The bootloader can check for this magic word and go into the update routine rather than branching to the application.

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #2 on: November 17, 2015, 10:21:00 am »
The ST Cortex-M have built-in bootloaders, so if all you want is to load a new firmware image, just set with jumpers on BOOT0/BOOT1 and load a new image. It even supports USB bootloading (DFU)
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #3 on: November 17, 2015, 10:52:34 am »
The ST Cortex-M have built-in bootloaders, so if all you want is to load a new firmware image, just set with jumpers on BOOT0/BOOT1 and load a new image. It even supports USB bootloading (DFU)
The problem with that is that you'd need to distribute an image everyone can read so competitors can clone your product in a heartbeat. End-user firmware updating needs encrypted firmware images.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline 0xdeadbeef

  • Super Contributor
  • ***
  • Posts: 1576
  • Country: de
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #4 on: November 17, 2015, 11:18:52 am »
For the NXP LPC1768 and similar devices there is an application note for a secondary USB bootloader (secondary because the primary bootloader only support UART).
Newer devices like the 1549 have a built-in USB bootloader (also CAN and UART).
Anyway, back to the secondary bootloader as it's the only concept that can be modified for personal needs:
When a certain pin is low/high during startup, the bootloader is entered  which mounts as USB disk with (simulated) FAT filesystem. Else it jumps up to the main subsystem.
In the bootloader, deleting this file will erase the application flash and "copying" a file onto the disk will reprogram the flash.
There is no encryption implemented but that could be easily added. Note that for this to make sense you also need to disable the JTAG access, lock the bootloader flash segments if possible etc.
Trying is the first step towards failure - Homer J. Simpson
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #5 on: November 17, 2015, 11:22:47 am »
The problem with that is that you'd need to distribute an image everyone can read so competitors can clone your product in a heartbeat. End-user firmware updating needs encrypted firmware images.

It depends on the volume/profitability of the products and the risk of cloning. If the MCU is but a small part of the widget, then it may not be a bad idea.

But you are correct in the general case. Symmetrical key encryption can take as little as a few K bytes so not a problem.

Teensy actually uses an M0 for bootloading, which I think is an overkill for its purpose.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 4228
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #6 on: November 17, 2015, 12:29:34 pm »
A built-in bootloader is a nice convenience for R&D, and perhaps for a design which is meant to be 'open', but I'm not convinced it's a good fit for a proprietary application.

Unless there's explicit support included for adding your own encryption and/or signature checking code, it's hard to see how you might implement these, given that the CPU is running manufacturer-supplied code from ROM. Perhaps this isn't a big deal in your product.

The bootloader may also be the first thing to become disabled if you use the security bits in your chosen processor. In that event, you'll have to provide your own.

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6460
  • Country: nl
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #7 on: November 17, 2015, 12:40:47 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.

Next if you go this way you must make sure that:
-  or you have enough ROM to store two firmwares and you can flash the new firmware in the other location and check after flashing if everything is ok (faulty flash write or corrupt cells or maybe another error occured during reading) with a simple checksum or again a MAC if you want something sturdier. If it is ok then the jump adress in the bootloader should be changed to the new firmware location.
- or you have an external flash where you keep an (authenticated and encrypted) copy of the old firmware before flashing. If you make sure that the CMAC checks out after the copy you can always restore to the older firmware if something goes wrong.

BTW the single point of failure is the bootloader so spent the most time on this piece of software and test extreme, it should be bugfree and never be modified again so protect it and make sure you never ever write on that location.
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6190
  • Country: us
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #8 on: November 17, 2015, 02:14:33 pm »
NXP have a great built-in USB bootloader for some of their ARM MCUs. You reset the MCU with a certain pin pulled down and the MCU installs itself as a USB hard drive. Then you copy the new image file to the driver and the device is updated. No special cable, adapter or software needed.

Check the schematic of the ARM Pro Mini for example.
« Last Edit: November 17, 2015, 02:17:13 pm by zapta »
 

Offline donotdespisethesnake

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #9 on: November 17, 2015, 07:00:10 pm »
Teensy actually uses an M0 for bootloading, which I think is an overkill for its purpose.

Paul uses a second chip to make the Teensy harder to copy, there's no other reason. I've never seen a Teensy clone, so I guess it meets the purpose well :)
Bob
"All you said is just a bunch of opinions."
 

Offline donotdespisethesnake

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #10 on: November 17, 2015, 07:08:08 pm »
My thought right now is the ATSAM4LS2CA-AU.  Any ideas where to being so my firmware can be field-upgradable with a Windows host application over USB?

Most SAM chips have a ROM bootloader called SAM-BA, Atmel distribute a Windows programming tool confusingly also called SAM-BA. Details will be on the Atmel website.

I looked at using it for one of our products, but we already have an in-house bootloader so wanted to keep the same interface, so I ported our bootloader code to ARM.
Bob
"All you said is just a bunch of opinions."
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6190
  • Country: us
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #11 on: November 17, 2015, 07:19:35 pm »
Teensy actually uses an M0 for bootloading, which I think is an overkill for its purpose.

Paul uses a second chip to make the Teensy harder to copy, there's no other reason. I've never seen a Teensy clone, so I guess it meets the purpose well :)

It's a licensing chip. You can buy it separately for -$5.
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #12 on: November 17, 2015, 08:03:41 pm »
It's a licensing chip. You can buy it separately for -$5.

Licensing for what? Thanks!
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline JoeNTopic starter

  • Frequent Contributor
  • **
  • Posts: 991
  • Country: us
  • We Buy Trannies By The Truckload
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #13 on: November 17, 2015, 09:32:29 pm »
Teensy actually uses an M0 for bootloading, which I think is an overkill for its purpose.

Paul uses a second chip to make the Teensy harder to copy, there's no other reason. I've never seen a Teensy clone, so I guess it meets the purpose well :)

So he is going the full route where the M0 is actually a programmer for the main processor?  The firmware on the M0 is never changed, takes an encrypted image, decrypts it, verifies it, and the programs most the M4?  This is more or less the most secure way of doing things?  What's to stop an attacker from grabbing the cleartext firmware between the M0 and M4 and simply making a clone device with the latest decrypted firmware and also change the M0 bootloader to take unencrypted firmware to program the M4 which the attacker can provide from time to time by grabbing it again from his hacked Teensy?
Have You Been Triggered Today?
 

Offline dadler

  • Supporter
  • ****
  • Posts: 851
  • Country: us
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #14 on: November 17, 2015, 09:56:33 pm »
It's a licensing chip. You can buy it separately for -$5.

Licensing for what? Thanks!

To use their toolchain (teensyduino/teensy loader etc)... An attempt to make cloning their boards difficult.

You can still program the mcu manually.

https://www.pjrc.com/store/ic_mini54_tqfp.html

https://www.pjrc.com/store/ic_mkl02.html
« Last Edit: November 17, 2015, 10:00:36 pm by dadler »
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #15 on: November 17, 2015, 10:18:10 pm »
In general if code confidentiality is needed,  built-in bootloaders are useless and you need to roll your own. Stream ciphers like RC4 are good candidates for w encryption algorithms because of efficiency and small code size. Firmware integrity can be ensured by using CRC or other checksum. In case bootloader detects corrupt application image, erase the flash (this might be an attempt to over write part of the code in order to gain program flow control and dump firmware) and notify user. User just has to flash application again. Application or bootloader must ensured that after the application start, bootloader flash area can't be read,  so that decryption key can't be dumped.

Sent from my HTC One M8s using Tapatalk.

I love the smell of FR4 in the morning!
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #16 on: November 17, 2015, 10:27:36 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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline donotdespisethesnake

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #17 on: November 18, 2015, 12:45:07 am »
Teensy actually uses an M0 for bootloading, which I think is an overkill for its purpose.

Paul uses a second chip to make the Teensy harder to copy, there's no other reason. I've never seen a Teensy clone, so I guess it meets the purpose well :)

So he is going the full route where the M0 is actually a programmer for the main processor?  The firmware on the M0 is never changed, takes an encrypted image, decrypts it, verifies it, and the programs most the M4?  This is more or less the most secure way of doing things?  What's to stop an attacker from grabbing the cleartext firmware between the M0 and M4 and simply making a clone device with the latest decrypted firmware and also change the M0 bootloader to take unencrypted firmware to program the M4 which the attacker can provide from time to time by grabbing it again from his hacked Teensy?

I'm not sure why people are talking about encryption, I don't think Teensy uses it. I've never really looked.

Clearly, the Teensy loader could be easily cracked, but the point is cloners are generally lazy, and it's enough to make it a bit hard for them.
Bob
"All you said is just a bunch of opinions."
 

Offline donotdespisethesnake

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #18 on: November 18, 2015, 12:56:33 am »
Teensy actually uses an M0 for bootloading, which I think is an overkill for its purpose.

Paul uses a second chip to make the Teensy harder to copy, there's no other reason. I've never seen a Teensy clone, so I guess it meets the purpose well :)

It's a licensing chip. You can buy it separately for -$5.

It's a licensing chip for the bootloader software on the licensing chip. The Teensy hardware is not licensable, only the software in the M0.

Since hardware designs are not covered by copyright, there is nothing to stop anyone cloning the Teensy PCB. However, if they want to use it with the Teensy loader, they need the software on the M0 which is copyright (and not published). The Teensy addon for Arduino is published with a rather non-open license, but that would not deter cloners.

The Freescale Kinetis chips don't have ROM bootloaders, so you either need external programmer, onboard programmer, or bootloader programmed to Flash. The Kinetis chips can be a bugger to program even with a JTAG programmer. Apart from lack of ROM bootloader, the Kinetis chips are quite nice.
Bob
"All you said is just a bunch of opinions."
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8275
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #19 on: November 18, 2015, 05:37:14 am »
Teensy actually uses an M0 for bootloading, which I think is an overkill for its purpose.

Paul uses a second chip to make the Teensy harder to copy, there's no other reason. I've never seen a Teensy clone, so I guess it meets the purpose well :)
Or the fact that no one sees any compelling reason to clone them. "imitation is the sincerest form of flattery"
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6460
  • Country: nl
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #20 on: November 18, 2015, 06:06:04 am »
Stream ciphers like RC4 are
Totally insecure and shouldnt be used anymore.
Use aes or if thats too big xtea.
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #21 on: November 18, 2015, 06:24:31 am »
I'd use xtea, simple to implement in C and asm, and secure enough for most purpose.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5319
  • Country: gb
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #22 on: November 18, 2015, 01:30:18 pm »
The problem with that is that you'd need to distribute an image everyone can read so competitors can clone your product in a heartbeat. End-user firmware updating needs encrypted firmware images.

It depends on the volume/profitability of the products and the risk of cloning. If the MCU is but a small part of the widget, then it may not be a bad idea.

But you are correct in the general case. Symmetrical key encryption can take as little as a few K bytes so not a problem.

While that is the case, you need to consider where that key resides. It's useless if someone can read the key with a JTAG emulator or sniffing or lifting a serial eeprom off a board. It needs to be baked in write once and write only somewhere, and JTAG needs disabling to prevent third party code being uploaded and sniffing about. Typically the use of firmware individually generated and tied to a unique baked in write once serial number is going to be more secure than a generic file, but equally that demands some infrastructure to support unique firmware generation.

Also be wary of code protection schemes, some of them can be circumvented quite easily.

Sometimes you need to consider whether it's even worth it at all. While I realise there is a school of thought that says everything should be open, at the end of the day you have to pay bills and keep a roof over your head. I've had two of my projects ripped off over the years, one was fully open source for non-commercial use which ended up keeping a few individuals will fed and watered at my expense, and the second, which had an open API, was ripped off by circumventing a chip's code protection (by running the device outside of documented parameters). In either case, there is little you can do, I don't have the resources to fund an IP lawyer, and even if I did what is a cease and desist notice going to do to someone on the other side of the planet?

One possible way is to make use of certain vertical market proprietary devices that are only available from the manufacturer. If someone rips off your design, you can usually ask the manufacturer not to supply the perps. The downside is that you're tied to a single vendor/manufacturer, and if it's a limited market part, you have to be careful about that manufacturer keeping in business and the lifetime of the part.

For me, the jury is still out on the value of IP protection, as a designer and OEM I can see both arguments. What I find more than a little concerning though are the black and white attitudes of a few open source nazis, almost certainly with too much time on their hands, who sit in their utopian ivory towers mulling over world peace and defeating poverty while dictating to someone they've never met that a project should be completely open, and that they should sport unnecessarily large beards and wear socks with their sandals. The world is rarely that simple.
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #23 on: November 18, 2015, 11:44:08 pm »
As a commercial vendor, our philosophy is to make it difficult without inconvenient the end users too much and without us going to heroics. We all know that anything can be copied: chip's covering can be removed and the flash can be copied using microscope. Any software protection can be defeated etc.

Another consideration is that if your Widget/software is copied/pirated, it's unlikely to be used by commercial users in US/EU/etc., especially if some anti-piracy measures have been taken. So the likely pirates will be in countries like Russia, China, India etc., and then you have to ask yourself whether those people will buy the stuff in the first place. If not, then you didn't really lose a sales.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 593
Re: Anyone have any experience with field upgradable firmware for ARM MCUs?
« Reply #24 on: November 19, 2015, 05:27:37 pm »
As a commercial vendor, our philosophy is to make it difficult without inconvenient the end users too much and without us going to heroics. We all know that anything can be copied: chip's covering can be removed and the flash can be copied using microscope. Any software protection can be defeated etc.

Another consideration is that if your Widget/software is copied/pirated, it's unlikely to be used by commercial users in US/EU/etc., especially if some anti-piracy measures have been taken. So the likely pirates will be in countries like Russia, China, India etc., and then you have to ask yourself whether those people will buy the stuff in the first place. If not, then you didn't really lose a sales.

Which is weird to me when like above, people are using other chips to handle security, almost any Cortex M0 out there could (in theroy) be dumped, so I'm not understanding why bother with that route at all.

IMO, I've found the only thing to be truly reliable is online authentication. Preshared key, known serial number and other data, etc. Which is why all of my products now get a $6 bluetooth module even if "technically" I don't "need" to have them get online via a gateway like a phone.

If anything in your plan is foiled by metaphorically "handing your source code to the Chinese" you're not actually secure.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf