A very common requirement for modern embedded devices is the need to update the embedded software via an arbitrary communication channel (e. g. a serial interface, ethernet connection, some field bus like CAN or a wireless link).
The redBlocks component library addresses this requirement by providing an out-of-the-box solution, consisting of the necessary target code as well as a host software update tool running on Windows and Linux operating systems.
The components of the redBlocks In-Target Software-Update Framework can also be used as a basis to implement a custom In-Target Software-Update solution for both the target software and host tools.
Concept
A typical memory layout for a system that is running from flash and needs to support In-Target-Software-Update looks like this:
Upon system startup, the Bootloader image is started. Its single purpose is to decide whether to start the Loader-Image or the Application-Image. The Loader-Image's sole purpose is the software update of the Application-Image, i. e. this image is started during the software update process of the Application-Image. The Application-Image on the other hand may provide the functionality to update the Loader-Image, if this is required. It is even possible to update the Bootloader from either the Loader-Image or the Application-Image. However, if a sudden power loss happens during this process, the device will not be able to boot again. Therefore, the most common approach is to allow only the Loader-Image and the Application-Image to be updated in the field.
Depending on the system requirements and the amount of available flash memory, the Loader-Image and the Application-Image may have identical functionality. Then the Loader-Image can act as a redundant standby Application-Image that takes over, if the active Application image gets corrupted (e. g. due to cosmic radiation).
If, on the other hand, the target is extremely short on flash memory, the functionality of the Bootloader and the Loader-Image can be combined to a single image, in order to avoid the common overhead of the two separate images.
The redBlocks In-Target Software-Update-Framework provides a number of classes that support this general approach and several variations of it:
- Image selection in Bootloader: The Bootloader only knows its own size and the flash page size. From this information it derives the address where to read the Loader-Image and Application-Image location. Different strategies are supported (and should be selected depending on the size of the flash memory): Either a dedicated flash page is used to maintain a table of contents or an algorithmic approach is chosen in order to determine the Application-Image position if needed.
- Bootloader database maintenance: During a software update process, the Bootloader database needs to be maintained / updated by the Loader-Image or Application-Image.
- Checksum calculation: Before starting one of the two images, the Bootloader does an image consistency check.
- Workflow that supports software image download and activation. It guarantees that one of the two images will always stay consistent, i. e. the device will always be able to continue the software update process in case of unexpected power interruptions while a software update process is in progress.
- Configurable application level protocol that can be used across an arbitrary interface (serial, UDP, TCP, CAN, ...) in order to control the process and transmit the image data from a host computer or an embedded device to the target.
- C++ host library that can be used to build a software update host application (e. g. a GUI running on a Windows or Linux system) that is used to update the embedded device's software.
- Command line software tool for Windows that can be included in the application's build process in order to add the additional information to the target Loader-Image and Application-Image (checksum information, size, address, version information, ...)
Just like all the other redBlocks components, the classes of the In-Target Software-Update Framework are highly modular and configurable. Thus, even in a totally different scenario (e. g. software update by accessing an update host per FTP) major aspects of the required functionality can still be covered with the redBlocks In-Target Software-Update Framework.