0

I want to update my mcu firmware on the air.The method I choose is Delta Firmware Update which find differences between old firmware & new one then a patch file is generated which can use for constructing new firmware on the mcu side.

I can build this patch file with jDiff on windows but I do not have an idea how can I dispatch & construct new firmware on STM32 side.

Do any one help me to find a solution?

Best.

  • Most of the STM32 MCU neither include WiFi nor cellular network. So if "on the air" is supposed to use one of these technologies, you should provide a more detailed description of your hardware. – Codo Aug 22 '21 at 15:27
  • No I want to use LoRa to update my firmware remotely. – Amin-nano-sys Aug 23 '21 at 09:48
  • LoRa has very restricted bandwidth. It would likely take days to transmit the needed data to update the firmware. – Codo Aug 23 '21 at 19:42
  • This is the only reason I want to use Delta firmware update! – Amin-nano-sys Aug 24 '21 at 07:32

1 Answers1

0

Given the low bandwidth of LoRa, firmware updates over LoRa will be very slow even if differential updates and compression are used. Let's put that aside for the moment and assume that the new firmware can be successfully sent to your MCU.

Since the firmware transmission is slow and unreliable, you must split your MCU's flash memory into two halves:

  • 1st half: current firmware, used for executing the code
  • 2nd half: next firmware version, incomplete, being received

As you can see, the flash memory needs to be at least double the size of currently used firmware.

The firmware is then received in many pieces. Most likely, a protocol is needed to ask for the re-transmission of pieces that haven't be received at all or received with errors.

Once the next firmware version has been completely received and verified (some check sum), you basically have two options:

Simple firmware update

A small firmware update routine is copied into RAM and started. It overwrites the current firmware with the next version and then resets the MCU.

This is straight-forward to implement. However, if the update fails (e.g. power hick-up), the device no longer works (colloquially "is bricked") and needs to be reprogrammed manually. So it's not excalty robust and suitable for device in the field.

Robust firmware update

The robust firmware update overwrites the vector tables with the addresses of the new firmware version and then resets the MCU. So the currently active firmware is alternately in the lower and upper half of the flash memory.

While this approach is more robust, it's more difficult to achieve. Either the firmware must be created using position-independent code or it must be specifically created with addresses either in the lower or upper half of the flash address range. None of this is supported out-of-the-box by the typical development environment.

As this is not trivial to achieve, some STM32 MCUs offer a dual bank mode to address this problem. It basically offers the robust firmware update without the hassles of a specially crafted firmware.


It of course make sense to only transmit the difference between two firmware versions. I'm however not certain if it helps a lot. Small changes to a function can lead to new addresses for variables and functions throughout the entire code, thereby introducing far more differences than you would expect.

Anyway, jDiff certainly isn't the tool of choice as it prefers speed over patch size.

Some links

Codo
  • 75,595
  • 17
  • 168
  • 206
  • Thanks! Do you know any source code or example or link to explain this or demonstrate it? – Amin-nano-sys Aug 25 '21 at 10:33
  • I don't fully understand which route you want to go, whether it's a commercial or private project, if hardware cost, development cost or time-to-market are more important, if hardware is already given or constraint. Anyhow, I've added a few links. – Codo Aug 26 '21 at 07:15