16
\$\begingroup\$

What kind of techniques are used to enable a user to safely upgrade a device firmware post sale? I want to do this with a Cortex M3/4 microcontroller, but I guess techniques for any micro should do.

Preferably with the least amount of extra components of course.

\$\endgroup\$
16
\$\begingroup\$

Use a chip that has more than twice the amount of Flash memory you will need for your code. This way you can get the new firmware to this memory while still leaving the old one in case anything goes wrong.

After you decrypt and verify the checksums on the new firmware a bootloader can copy it to it's final location, replacing the old one. If anything goes wrong during this part, after a hard-reset the bootloader should see that the new firmware is not valid (by running the checksum once again) and retry the copying.

This is the simplest and most foolproof way I know. It also requires little code in the bootloader and does not require duplicating any functionality between the main program and the bootloader (you do not need any communication logic in the bootloader).

\$\endgroup\$
  • 10
    \$\begingroup\$ As a user of electronics, I might add that it'd be nice to have a button somewhere to hold while booting that would boot the old firmware, in case the new one has a correct checksum but the software itself has a bug. \$\endgroup\$ – Zan Lynx Aug 18 '11 at 18:52
  • 4
    \$\begingroup\$ The "Problem" I see with this solution is that you need some kind of relocation table or complete position independent code. Otherwise your code will not run. \$\endgroup\$ – Nico Erfurth Aug 18 '11 at 20:12
  • 2
    \$\begingroup\$ @Masta - You're not understanding the part where the firmware is copied to its final (normal) location. \$\endgroup\$ – Kevin Vermeer Aug 18 '11 at 21:03
  • 3
    \$\begingroup\$ @jpc - We use this technique with an external serial Flash chip on some in-house tools at work. You don't need to have a microcontroller with more than twice the Flash if you have room for an 8-pin SOIC or QFN part. 1MB serial Flash memories can be had for less than a dollar so it may be cheaper to go this route than upgrade the microcontroller in some cases! \$\endgroup\$ – Kevin Vermeer Aug 18 '11 at 21:08
  • \$\begingroup\$ @zan - Yup, we use this too. One concern or benefit is that the device gets reset to defaults when you recopy the old firmware (we don't have EEPROM on our micro; we store configuration data like the MAC address and IP address in self-written Flash). For us, this makes it easy to find a board when we forget the IP address. \$\endgroup\$ – Kevin Vermeer Aug 18 '11 at 21:16
12
\$\begingroup\$

Use a bootloader and a few KB of extra flash.

An upgrade is performed by the bootloader, by sending some special command over UART, USB, I2C, or another protocol. Only the main code is ever updated - bootloader code is never touched except via an external programmer (i.e. JTAG/PICkit for PICs etc.)

If the update fails (power failure, someone tripped over a wire or another reason), then the widget won't work, but the bootloader will still be there so the upgrade can be attempted again.

A flag could be set in some byte somewhere which prevents the main code executing incorrectly because it has not been fully updated.

\$\endgroup\$
  • \$\begingroup\$ You could also force the bootloader to run if the boot is because of a power-up. This would help if you load in bad firmware that immediately crashes. The bootloader would need a timeout to run the application after X seconds. \$\endgroup\$ – Robert Aug 18 '11 at 19:33
  • \$\begingroup\$ It is a good idea if you can use a simple protocol (like an async serial, TTL or 485). For more involved cases (SD cards, GPRS, USB) I would not include the complex support code in the (non-upgradeable) bootloader. Ethernet OTOH (raw UDP or TFTP) is simple enough for this. \$\endgroup\$ – jpc Aug 18 '11 at 21:23
3
\$\begingroup\$

If your device is comparatively expensive and you can afford the cost ( and you customers care about upgrades) you can do this...

( generally this technique requires either external storage or devious use of jtag..)

Have a fixed program micro (like a little PIC) that can halt the system and reprogram it.

because you cannot change the "upgrade processor" firmware, it cannot ever go wrong.

1) the user can upgrade the device

2) if an upgrade fails, they can always try again. It cannot be bricked

3) even when your target device doesn't support a boot-loader ( it just wants to boot and run) you can still make it do what you want to.

works for FPGA, DSP and other oddball targets.

Can have a really neat user interface ( even a PIC can run a web server....)

\$\endgroup\$
2
\$\begingroup\$

Make sure your product has some kind of simple serial interface, preferably EIA232. A non-standard connector is OK if you don't have the space for a DB-9. For instance a TRS connector is all you need for TxD, RxD and ground.

When programming the device the first time, include a bootloader. This should be as simple as possible, because sooner or later you would want to upgrade the bootloader itself if it would need new features. (You probably can't even upgrade it)

Then the TRS connector. Use a jack with a switch so that you can detect when there's a connector present. Just check right out of reset, and start the bootloader if the plug is present, otherwise start the application. That way bootloader and user application program remain well separated. (The check is actually part of the bootloader; we'll need it regardless of the application's version, otherwise we won't be able to enter the bootloader!)

\$\endgroup\$
  • \$\begingroup\$ Why would you ever want to upgrade the bootloader? How would you make sure that the upgrade process wouldn't brick the device? If it could, what new features would be so compelling that you would risk bricking to upgrade? \$\endgroup\$ – Kevin Vermeer Aug 18 '11 at 20:58
  • 5
    \$\begingroup\$ @Kevin - I think he meant that the bootloader should be so simple that you will never even think about "upgrading" it. \$\endgroup\$ – jpc Aug 18 '11 at 21:20
  • \$\begingroup\$ @jpc - Ah, you're right, misinterpreted that. We're in agreement! \$\endgroup\$ – Kevin Vermeer Aug 18 '11 at 21:21
1
\$\begingroup\$

What equipment will the 'upgrader' have available? A PC, a USB stick, a micro SD card?

One way would be to have the application in a removable item (usb stick, SD card, etc). The chip loads its application from the item. Your upgrader simply swaps the item and reboots.

The ARM and Cortex microcontroller chips I know (NXP, Atmel) all have a build-in serial bootloader, so if your updater arrives with a PC and a serial cable (and you have arranged for a COM port interface) he can simply download your update.

\$\endgroup\$
  • \$\begingroup\$ So simply by wiring the UART pins to a port, while connected to a COM port and a PC, you can flash the firmware without any code on the mcu at all? Nice tip. \$\endgroup\$ – Imbrondir Aug 26 '11 at 13:04
  • \$\begingroup\$ Check the datasheet, section 'bootloader'. To do this really 'hands off' you will need a way to 1. reset the chip; 2. activate the bootloader (the chip checks a ceratin pin). This can be done by a jumper and a (reset) switch, but a more convenient way (especially on your desk) is to use two handshake lines to do the trick 'hands-off'. Most PC download programs (eg. flashmagic, lpc21isp) can do the handshaking magic for you (if you wire the handshake lines correctly). \$\endgroup\$ – Wouter van Ooijen Aug 26 '11 at 14:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.