9
\$\begingroup\$

We will create an ARM board with a GSM modem on-board.
We want to be able to upgrade the ARM firmware over the air.

Is there any good, reliable, open source solution for that?
If not, is there a paid OS with this feature?

\$\endgroup\$
  • 2
    \$\begingroup\$ ARM is quite generic: there are many manufacturers that embed ARM architectures, and some of them may provide that feature. \$\endgroup\$ – clabacchio May 7 '12 at 9:49
  • 1
    \$\begingroup\$ A more specific info on what ARM chip/family you're planning to use would be nice. Many if not all Cortex-M microcontrollers support writing to flash from user code. Example open-source implementations exist, such as the Maple bootloader leaflabs.com/docs/bootloader.html, and I think I've seen firmware upgrade over a radio link supported in some quadcopter. \$\endgroup\$ – Thorn May 7 '12 at 10:02
  • \$\begingroup\$ We have not chosen the ARM device at the moment ;) \$\endgroup\$ – hotips May 7 '12 at 12:49
  • 7
    \$\begingroup\$ The big problem with firmware upgrades is how to force the chip into update mode once there is something wrong with the firmware. When you have access to the chip you can reset it and force a bootload pin high, but how are you going to do that over the air? The only reliable solution I can imagine is having a second chip (non-updatable) that handles the basic communication an can update the main chip. After solving that problem the actual bootloading can be as simple as using (for instance) the bootloader built into the chip (for instance, the LPC uC's I know all have a serial bootloader). \$\endgroup\$ – Wouter van Ooijen May 7 '12 at 14:31
  • 2
    \$\begingroup\$ @Hernan That would make subtle failure modes possible, like one chip (somehow running the wrong code) keeping the other in reset. The only realy reliable solution is keeping the functions in one chip so simple that you will never need to update it. \$\endgroup\$ – Wouter van Ooijen May 29 '12 at 18:49
9
\$\begingroup\$

I'm not aware of any pre-made solutions but I'll describe how I went around it in one project. It's not totally 'unbrickable' but I'm not aware of it failing over thousands of upgrades. For this application a very low failure rate would still be cheaper than having to gain access to the units.

The main application has three additional packet types added to it's normal communication protocol that includes error detection and a retry stategy on top:

  1. A begin firmware update command clears a reserved memory area in an external SPI Flash. It returns an error if the unit is running from its backup battery or if it's running from external power but the battery state of charge is below 25%.

  2. A write block command accepts an offset address and data that is written to the external Flash memory in small chunks. The higher level protocol takes care of error detection and retransmissions. After each block is written it is read back and verified before the command is acknowledged.

  3. A finish firmware update command includes the length that the received firmware should be along with a CRC32 of the whole image for further verification. If that matches the contents of the external Flash memory and the power conditions are still OK the same length and CRC32 is transferred to an EEPROM area along with a 'magic number' to indicate that a firmware update is pending.

  4. A hard loop is executed in the main application to force a watchdog restart.

  5. The bootloader (that is located in a write protected area of the ARM's Flash) sees the magic number in EEPROM and once again verifies the CRC32 of the image. If all is OK it transfers the image from external Flash into the main program area of the ARM's Flash.

  6. The pending upgrade information is cleared from EEPROM and a hard loop forces another reboot. This time the bootloader will start the main application normally.

While I've never seen the update phase fail testing new firmware releases before deploying is crucial using this method. If a new release isn't capable of connecting to the GSM network and accepting future update comands it will require an on-site firmware update.

\$\endgroup\$
1
\$\begingroup\$

Are you running Linux or an RTOS, or bare metal? If using Debian you can take a snapshot of the current filesystem, do an upgrade via "apt-get" then keep or rollback the changes depending on whether it worked or not.

\$\endgroup\$
  • \$\begingroup\$ We have Linux and bare metal depending of the application ;-) \$\endgroup\$ – hotips Jun 5 '14 at 21:03
  • 1
    \$\begingroup\$ If you have Linux then you can leverage a lot of that infrastructure. The way I am handling updates on my current project is to create .deb files for the custom applications, then use apt-get update to update the system. I am also experimenting with btrfs. That filesystem lets you take snapshots. So my plan is to snapshot the desired directories, try and update, and if it didn't work, revert the snapshot. If you are on bare metal then you'll need to probably go with the usual dual memory approach, one image for the latest working code, and other one for the freshly downloaded code. \$\endgroup\$ – fred basset Jun 6 '14 at 15:23

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.