Firmware updates, part 1: Bootloader

This is the first post in a series (part 2, part 3) about doing device firmware updates (DFU) over the air (OTA) and continuous delivery of firmware for embedded devices. We'll explore the different parts of a complete end-to-end system with this capability.


This is a companion discussion topic for the original entry at https://blog.drogue.io/firmware-updates-part-1/

May I suggest just having two active partitions and the bootloader just makes the decision on which one to boot?

Having to move around the currently active (and working) partition to load in the new one is just another opportunity for something to go wrong and for you to be left with a bricked device (without further intervention). Murphy’s law, if anything can go wrong, it will. The algorithm looks convincing but I still think its better to not touch what’s already working. I see the argument for being able to use external flash for the DFU partition but in my experience I’ve found it typically lower cost to just use a larger flash MCU instead of having to have external memory.

Thanks for sharing, really enjoyed the article!

Thanks for the feedback! Yes, having two active partitions is certainly less risk in terms of things that can go wrong, and I guess it will reduce flash wear out as well.

Unfortunately, Rust does not yet support supports position independent executables[1], so we wouldn’t be able to bootload embassy applications without lots of tweaks to the linker scripts. Once supported though, I would like to support the mode you suggest for targets that have the PIE capability.

Some MCUs like STM32 H7 have the ability to ‘switch’ the address spaces for two banks, so it could be possible to almost get this ability for those MCUs.

[1] Vtables not position independent for target thumbv7em-none-eabi · Issue #54431 · rust-lang/rust · GitHub
[2] Position Independent Code · Issue #322 · rust-embedded/cortex-m-rt · GitHub

Very interesting, I didn’t know. Thank you for linking the relevant issues.