Q&A: Where Should Firmware Update Capabilities Live?

Here’s a question we answered in the Interrupt Slack channel after the OTA updates panel. We’re sharing the answer on our blog to make it available to a wider audience.

Quote
Thoughts on implementing the update application outside of the bootloader, such as in a userspace process?

Ultimately, where the updater lives is dependent on the overall system architecture.

A big consideration is where is my code executing from. The other item is where am I writing to. For modern MCUs, the answer is often “I’m executing code out of flash”. If you’re writing to a separate flash partition, having an update process in your application could be fine. If you’re resource limited, and writing an update to the same section of flash that you’re currently executing from (i.e., you rely on a single application partition and a fixed fallback image), you’re going to crash your system. In contrast, if you’re executing out of SRAM, it might be totally fine to safely erase + write flash, even with one application partition.

The other consideration is resource availability. You might not have enough free RAM when your full application is running to receive the firmware payload and perform the update. You might want a separate application to handle updates simply because you can guarantee sufficient compute and memory for the update operation.

There’s also the complexity factor. The more complex the operations are, the more things can potentially go wrong. Simplifying the system state as much as possible makes your work easier. You want to have restrictions on what’s happening during the update process, which would prevent other system processes from potentially undermining the update operation.

Quote
Associated question: What is the rationale for having your update functionality live in the bootloader? Do your thoughts about this change in a Linux vs bare metal environment?

For an MCU, I don’t recommend having the update functionality live in the bootloader, although it is common (e.g., MCUBoot). Rather, I would create a separate application that is just used for the update process. If your bootloader has the update capabilities itself, common restrictions (e.g., running code out of flash) prevent the bootloader from being able to update itself.

With Linux, you get a lot more leeway, and often there is an update client that runs as a separate application/process.

References

Share Your Thoughts

This site uses Akismet to reduce spam. Learn how your comment data is processed.