1. Home
  2. Embedded Programming
  3. Firmware upgrade strategies

Firmware upgrade strategies

The first thing to think of is the firmware upgrade strategy of an electronic device with embedded software.

There are a multitude of bootloader out there for different microcontrollers, physical communication links and features.

I know it's difficult, but is there a somewhat standard firmware upgrade procedure/strategy/protocol? Some open approach that is followed by different vendors/software.

In my case, I need a firmware upgrade strategy for AVR and SAM devices (from Atmel/Microchip) over UART half-duplex master/slave bus: the master should manage the firmware upgrade of all the devices. The devices could be different, so the upgrade should be done for a device at a time, keeping the other device in an inactive state.

There are some issues:

- the protocol should use an address, so the bootloader should share the address with the application (in a shared memory zone?);

- the master should sends a signal to force entering the bootloader (I think a shared reset line is the simplest way to achieve this);

- all the devices on the bus should implement the same upgrade protocol and this could by a challenge if the MCUs are very different (from small 8-bit devices to big 32-bits devices);

Is there an open bootloader project that can be used in my application?

Reply to
pozz
Loading thread data ...

I'm using quite extensively an AVR109 type bootloader for any MCU. Used on "real" AVR parts but also on Cortex parts including some LPC devices, STM32 and Kinetis. The thing is: no matter which the real MCU is, the protocol is faking it to be an AVR part. But this is only to please the "avrdude" PC software, if you make your own software, you can do anything.

AVR109 protocol is half duplex. Doesn't include an address, but you can modify it easily to add an address. Of course, an off-the-shelf avrdude program won't work anymore with it...

Reply to
raimond.dragomir

I rarely find that ready-made bootloaders are useful in the field at the best of times. It is going to be even harder to find something that supports two completely different architectures.

A key aspect of upgrading in the field is that it needs to play well with the normal protocols you are using. If your cards are normally communicated with Modbus and suddenly your master wants to use a third-party protocol to upgrade the firmware on one of the slaves, you can expect chaos. The correct way to handle it in this case is to have a firmware protocol that is embedded in Modbus, and to use normal Modbus registers to transfer things like program version numbers, jump to bootloader requests, etc.

So start by looking at the communication you normally have here, and see how upgrades can fit in with that.

And consider if the firmware can be transferred and saved while running in normal mode, rather than bootmode. That takes more flash space, and requires flexible erase and program capabilities on the microcontrollers (or an external SPI flash), but will minimise down-time and keep your bootloader code as simple as possible because it does not have to communicate.

Reply to
David Brown

Yes, this is possible. However if you base your firmware upgrade on the main application, a critical bug could prevent the upgrade process itself, because you could have a device that is not able to enter bootloader anymore by a command on the bus. I think this is why you need a reliable hardware method to enter bootloader.

The problems with mixing different protocols (bootloader and normal communication) can be avoided by stopping all the devices on the bus during upgrade.

Here the main requirement is to upgrade the firmware from a remote site, so without pressing buttons or similar manual/local operations. I have an embedded Linux box that features remote connection (Ethernet) and local connection (bus). The Linux box should manage the firmware upgrade of the devices on the bus.

I'm thinking to have a shared reset line on the bus to force a hard reset of all the devices that enter the bootloader at the same time. Of course, only one device enters firmware upgrade (because it is addressed by the master in a period of time) while the others stay in bootloader (because not addressed, but they see another device is addressed so avoid launching main application).

When the upgrade finishes, another pulse on shared reset line launch the main application on all the devices.

This is a good point. However, as I said before, this could be implemented as a "low-reliable" upgrade method that uses the current firmware to download and save the new firmware. However you always need another method (the hard reset to enter bootloader).

Reply to
pozz

There is no fixed answer here - it depends on a variety of things, such as the complication of the protocol (maybe it is too complicated for a bootloader), the consequences of failures (are you losing lives or millions of dollars, or does someone just need to turn their automatic light switch on and off?), the level of testing (a critical bug in the main program should never be released!), etc.

Yes, that is a possibility - at least for some systems. What if the critical bug in the main program means that some cards don't go into bootloader mode?

Drawing out a reset line directly onto your bus sounds risky.

As I say, there is no one strategy that fits every use-case - but I'd be aiming for something that can run alongside normal communication, rather than instead of it. Whether that means getting the new firmware while in main program mode, or that the bootloader has a limited version of the normal communication protocol is a design choice to make.

No, you most certainly do /not/ always need such a method. You /might/ want it - but it many cases it is simpler, cheaper, and more reliable to say that if the unit fails to upgrade via the normal upgrade method, then the unit is broken and gets thrown away or sent back to the shop for repairs. ("Repair" possibly meaning "firmware upgrade via JTAG".)

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.