Remote firmware updates for embedded systems
Firmware updates are one of the most important factors to take into account very early in the process of starting the development of any IoT project. When the software is maintained by a development team, anything that goes wrong can be fixed on the field and new features can be deployed quickly, as long as remote updates are efficient, reliable and trusted.
Products can be pushed into production earlier, offering the possibility for a different strategy that involves remote updates when new features are ready, or when defects on the current version have been fixed. For this reason, it is in general a good idea to include a firmware update mechanism since the very early phases of your product or platform definition.
Microcontroller-based systems are quite challenging when it comes to firmware updates. On one hand, modern microcontrollers provide a wide range of features, a large choice of embedded operating systems, significantly reduced engineering costs for products based on a simpler design and the ability of running in ultra low-power environment, some even relying solely on energy-harvesting devices. On the other hand, embedded systems cannot relocate executable code at run-time. Even if a system is capable of multi-threading, threads are almost always defined at compile time, assigned a fixed stack space, and all the code is often linked together into a single executable firmware image.
Using a monolithic image makes impossible to update single components on the system without changing the layout of the code stored in flash. A bootloader can be helpful in this case.
MCU bootloaders
A classic approach for updating the firmware of a running embedded system is by using a bootloader.
Chip manufacturers often provide very simple pre-installed bootloaders, that can be used to update the partition images on a running system. A very common strategy adopted by these bootloaders is to provide a “DFU mode” as an alternative boot stage to choose, where DFU is the acronym for “device firmware update”. This mechanism often allows to update all the software stored on the target flash, using local devices such as UARTs or the DFU-USB device class specification. Pre-installed bootloaders may result helpful during the development of a few prototypes to speed up the life-cycle, or when the number of targets and their geographical location allows for manually-activated updates.
Connected devices however have a different range of challenges to deal with. Updates must be fail-safe in order to prevent the node from being unreachable after a software failure. Security considerations arise whenever the firmware is transmitted using a public network, or over-the-air, about the authenticity and the integrity of firmware update images. How do IoT projects deal with this? Building your own bootloader may seem viable, but it may become as time and resource consuming as maintaining the firmware itself, and definitely does not help cutting down your time to market.
wolfBoot
wolfBoot is an open source secure bootloader for all microcontrollers, designed to support remote firmware updates in embedded systems. It currently supports ARM Cortex-M and RISC-V architectures, and can be integrated in embedded systems using by partitioning of the non-volatile memory available on board.
Thanks to its in-place swapping mechanism, any memory support can be used by the application to store the firmware updates. The updates are then verified and authenticated by wolfBoot after the system reboots. A copy of the old firmware, overwritten only by a validated update, is temporarily stored into the update space to provide a fall-back mechanism in case of boot failures due to a defective firmware release. The image must in fact be confirmed after a valid update.
Continue reading “Remote firmware updates for embedded systems with wolfBoot”
