Anyone have any experience with field upgradable firmware for ARM MCUs? - Page 1
Forum section: electronics / general

author: JoeN
author_rank: Frequent Contributor
timestamp: November 17, 2015, 09:03:08 am
content: 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.

author: AndyC_772
author_rank: Super Contributor
timestamp: November 17, 2015, 09:18:15 am
content: 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 itThe 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.

author: richardman
author_rank: Frequent Contributor
timestamp: November 17, 2015, 10:21:00 am
content: 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)

author: nctnico
author_rank: Super Contributor
timestamp: November 17, 2015, 10:52:34 am
content: Quote from: richardman on November 17, 2015, 10:21:00 amThe 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.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: November 17, 2015, 11:18:52 am
content: 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.

author: richardman
author_rank: Frequent Contributor
timestamp: November 17, 2015, 11:22:47 am
content: Quote from: nctnico on November 17, 2015, 10:52:34 amIt 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.

author: AndyC_772
author_rank: Super Contributor
timestamp: November 17, 2015, 12:29:34 pm
content: 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.

author: Kjelt
author_rank: Super Contributor
timestamp: November 17, 2015, 12:40:47 pm
content: 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.

author: zapta
author_rank: Super Contributor
timestamp: November 17, 2015, 02:14:33 pm
content: 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.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: November 17, 2015, 07:00:10 pm
content: Quote from: richardman on November 17, 2015, 11:22:47 amPaul 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

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: November 17, 2015, 07:08:08 pm
content: Quote from: JoeN on November 17, 2015, 09:03:08 amMost 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.

author: zapta
author_rank: Super Contributor
timestamp: November 17, 2015, 07:19:35 pm
content: Quote from: donotdespisethesnake on November 17, 2015, 07:00:10 pmIt's a licensing chip. You can buy it separately for -$5.

author: richardman
author_rank: Frequent Contributor
timestamp: November 17, 2015, 08:03:41 pm
content: Quote from: zapta on November 17, 2015, 07:19:35 pmLicensing for what? Thanks!

author: JoeN
author_rank: Frequent Contributor
timestamp: November 17, 2015, 09:32:29 pm
content: Quote from: donotdespisethesnake on November 17, 2015, 07:00:10 pmSo 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?

author: dadler
author_rank: Unknown
timestamp: November 17, 2015, 09:56:33 pm
content: Quote from: richardman on November 17, 2015, 08:03:41 pmTo 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.htmlhttps://www.pjrc.com/store/ic_mkl02.html

author: poorchava
author_rank: Super Contributor
timestamp: November 17, 2015, 10:18:10 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: November 17, 2015, 10:27:36 pm
content: 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.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: November 18, 2015, 12:45:07 am
content: Quote from: JoeN on November 17, 2015, 09:32:29 pmI'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.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: November 18, 2015, 12:56:33 am
content: Quote from: zapta on November 17, 2015, 07:19:35 pmIt'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.

author: amyk
author_rank: Super Contributor
timestamp: November 18, 2015, 05:37:14 am
content: Quote from: donotdespisethesnake on November 17, 2015, 07:00:10 pmOr the fact that no one sees any compelling reason to clone them. "imitation is the sincerest form of flattery"

author: Kjelt
author_rank: Super Contributor
timestamp: November 18, 2015, 06:06:04 am
content: Quote from: poorchava on November 17, 2015, 10:18:10 pmTotally insecure and shouldnt be used anymore.Use aes or if thats too big xtea.

author: richardman
author_rank: Frequent Contributor
timestamp: November 18, 2015, 06:24:31 am
content: I'd use xtea, simple to implement in C and asm, and secure enough for most purpose.

author: Howardlong
author_rank: Super Contributor
timestamp: November 18, 2015, 01:30:18 pm
content: Quote from: richardman on November 17, 2015, 11:22:47 amWhile 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 afewopen 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.

author: richardman
author_rank: Frequent Contributor
timestamp: November 18, 2015, 11:44:08 pm
content: 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.

author: jnz
author_rank: Frequent Contributor
timestamp: November 19, 2015, 05:27:37 pm
content: Quote from: richardman on November 18, 2015, 11:44:08 pmWhich 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.

author: jnz
author_rank: Frequent Contributor
timestamp: November 19, 2015, 05:34:24 pm
content: Quote from: nctnico on November 17, 2015, 10:27:36 pmGoing 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 whenSo 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: November 19, 2015, 06:31:33 pm
content: 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  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.

author: Kjelt
author_rank: Super Contributor
timestamp: November 19, 2015, 09:31:34 pm
content: Quote from: jnz on November 19, 2015, 05:34:24 pmThere 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.

author: jnz
author_rank: Frequent Contributor
timestamp: November 20, 2015, 05:31:08 pm
content: Quote from: Kjelt on November 19, 2015, 09:31:34 pmMaybe 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.

author: nctnico
author_rank: Super Contributor
timestamp: November 20, 2015, 09:14:45 pm
content: Quote from: jnz on November 20, 2015, 05:31:08 pmI 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!

author: Howardlong
author_rank: Super Contributor
timestamp: November 21, 2015, 07:03:11 am
content: Quote from: nctnico on November 20, 2015, 09:14:45 pmI 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!

author: Boomerang
author_rank: Regular Contributor
timestamp: November 21, 2015, 01:51:43 pm
content: Quote from: Howardlong on November 21, 2015, 07:03:11 am

author: Kjelt
author_rank: Super Contributor
timestamp: November 22, 2015, 08:02:39 pm
content: Quote from: jnz on November 20, 2015, 05:31:08 pmNot 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: November 22, 2015, 09:15:02 pm
content: 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.

author: gmb42
author_rank: Frequent Contributor
timestamp: December 16, 2015, 11:22:25 am
content: Ran across an Atollic tutorial on ARM Cortex M bootloadershere, might be useful, I haven't checked it myself.

author: bson
author_rank: Unknown
timestamp: December 17, 2015, 07:42:00 pm
content: Quote from: Kjelt on November 17, 2015, 12:40:47 pmIntegrity 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!!!

author: Kjelt
author_rank: Super Contributor
timestamp: December 17, 2015, 09:29:11 pm
content: Quote from: bson on December 17, 2015, 07:42:00 pmI 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.

author: CypressPSoC
author_rank: Contributor
timestamp: December 17, 2015, 09:56:01 pm
content: 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-bootloaderhttp://www.cypress.com/documentation/application-notes/an86526-psoc-4-i2c-bootloaderhttp://www.cypress.com/documentation/application-notes/an73503-usb-hid-bootloader-psoc-3-and-psoc-5lpWith our Bluetooth Low Energy SoCs, you can also have Over-the-Air bootloading over BLEhttp://www.cypress.com/documentation/application-notes/an97060-psoc-4-ble-and-proc-ble-over-air-ota-device-firmware-upgrade?source=search&keywords=AN97060hope 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