Bootloader Tutorial, Part 2: Backup Firmware

In the second part of the bootloader series, I'd like to discuss the concept of backup firmware. This was developed by MEDtech-Ingenieur to increase the reliability of firmware that uses pre-installed bootloaders.

Problem description

To understand the underlying problem, let’s imagine the following scenario:

A medical device consists of two software systems, among others. One is the GUI controller, which handles the visualization of signals (ECG, respiratory waveform, etc.). The other component is a microcontroller, which handles hardware-specific functions (e.g., power management, data acquisition, etc.). The GUI controller can receive updates via Wi-Fi. The update file contains, among other things, an image with firmware for the microcontroller. This can be transferred via the bootloader protocol. To save time during development, the microcontroller manufacturer's pre-installed (and tested!) bootloader is used. There are two ways to start it:

1. The host controller sets a pin assigned to the bootloader to a specific level and then performs a reset by toggling the microcontroller's reset line.
2. The microcontroller automatically jumps to the address where the bootloader is stored.

Option 1 has a crucial disadvantage: It requires a reset line between the host and the microcontroller. In our case, this would mean that a software error in the GUI controller could cause the microcontroller to reset at any time (even during treatment). In medical technology, this problem would make it significantly more difficult to argue why the GUI controller should be classified in a lower risk category than the microcontroller.

Option 2, however, also has a serious disadvantage: The microcontroller must receive a command from the host that initiates the jump to the bootloader. This sounds trivial at first, but it should be noted that after a failed update, there is usually no firmware left that understands this command. Therefore, if the user disconnects the power supply during the update, the device will be unusable. With the backup firmware, we are trying to address precisely this problem.

Solution

The goal is to install a "slimmed-down" firmware on the microcontroller that is still capable of performing another update even after a failed update. Ideally, this firmware should be located at the entry address from which the CPU loads the first instruction after a reset (virtual address 0x00).

The backup firmware is therefore always executed after a reset. The following figure shows an example of a backup firmware process. It's important to note that the backup firmware's functions should be as limited as possible, as it won't be overwritten during an update. In the example below, the backup firmware performs only one of two actions:

1. If a main application with a valid checksum exists, it is accessed.
2. If no valid checksum is present, the backup firmware waits for a command from the host and then jumps to the bootloader.

What you need to consider

When do I need a backup FW

Using backup firmware only makes sense if you can actually access a pre-installed bootloader that isn't run during startup. One example is STM32 microcontrollers (note: those with two flash panels have their own rules for handling the bootloader!). With this microcontroller family, the bootloader can be accessed at any time from within the main application. On the other hand, with EFM32 and PIC32 microcontrollers, for example, the manufacturer provides the bootloader as a software project, which in most cases must be customized by the developer anyway. It is therefore recommended to integrate the backup firmware functions directly into the bootloader.

It may also be useful to align the bootloader protocol with the protocol between the host and peripheral controller. In this case, too, it's recommended to write your own bootloader.

Protect storage areas

It may be useful to protect the memory area where the backup firmware is located from write access. This prevents the host from having to know the memory allocation of the peripheral controller. Many microcontrollers offer the option of protecting the memory on a page-by-page or sector-by-sector basis to prevent overwriting during the update process.

Do not overload backup FW

While it's logical to assign additional functions to the backup firmware, this would significantly increase the risk of errors and thus the need for an update. If the backup firmware were to be copied over and the process aborted before completion, no firmware would remain that would allow another jump into the bootloader. Updating the backup firmware should therefore be avoided if possible.

outlook

In the third and final part, I'd like to write about the development of a live update bootloader. This isn't a classic bootloader, but rather an extension of the main application with functions normally assigned to the bootloader. This allows updates to be performed in the background without the main application having to stop working.

Back to Part 1

Continue to Part 3