Electronic – Upgrade ARM over the air

armfirmwarewireless

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?

Best Answer

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.