Bootloader Reliable Update

Introduction

Reliable update is an optional but important feature of MCU bootloader. During a firmware update, an unexpected loss of power or device disconnect from the host can happen. This may result in a corrupted image or non-responsive devices. The reliable update feature is designed to solve this problem.

Parent topic:Bootloader Reliable Update

Functional description

The reliable update works by dividing the device memory into two regions: the main application region and backup application region. Only the backup application region is allowed to be updated by the host. Once the backup region is updated with the new firmware image, the reliable update process needs to be initiated . The MCU bootloader here checks the validity and integrity of the new application image in the backup region,and copies the new image to the main application region.

Bootloader workflow with reliable update

There are two methods to initiate reliable update process. The first method is to reset the device to enter the bootloader startup process, causing MCU bootloader to detect the presence of a valid image in the backup region, and kicking off the reliable update process. The second method is by issuing a reliable-update command from host using BLHOST.exe while the bootloader is running on the device.

Using the first method, the reliable update process starts before all interfaces are configured. The figure below shows the call to reliable update process during startup flow of the MCU bootloader.

The second method occurs while the bootloader state machine is running. The reliable update process is triggered when the host sends the reliable update bootloader command.

Bootloader workflow with reliable update |

|

Parent topic:Functional description

Reliable update implementation types

There are two kinds of reliable update implementations. They can be classified as either the software version or hardware version. The main differences between software and hardware implementation are listed below:

Software and hardware implementation

Item	Software implementation	Hardware implementation
Applicable device	All Kinetis devices	Devices with flash swap support
Device memory distribution	Bootloader + main application + backup application	Main bootloader + main application + backup bootloader + backup application
Backup application address	Flexible	Fixed
The ability to keep two applications	No	Yes

The most obvious difference is that the software implementation copies the backup application to the main application region, while hardware implementation swaps two half flash blocks to make the backup application become the main application. The detailed differences will be reflected in Section 12.2.3, “Reliable update flow”.

See Section 12.3, “Configuration macros” on how to enable different implementations of the reliable update.

Parent topic:Functional description

Reliable update flow

This chapter describes in detail both the software and hardware implementation of the reliable update process.

Software implementation

For software implementation, the backup application address is not fixed. Therefore, the application address must be specified. There are two ways for the bootloader to receive the backup application address. If the reliable update process is issued by the host, the bootloader receives the specified application address from the host itself. Otherwise, the bootloader uses the predefined application address.

After the reliable update process starts, the first thing for the bootloader is to check the backup application region . This is to determine if the reliable update feature is active by checking:

If the application pointer in the backup application is valid.
If the Bootloader Configuration Area is enabled.

If above conditions are not met, the bootloader exits the reliable update process immediately. Else, the bootloader continues to validate the integrity of the backup application by checking: the following

Is crcStartAddress is equal to the start address of the vector table of the application.
Is crcByteCount (considered as the size of backup application) is less than or equal to the maximum allowed backup application size.
Is the calculated CRC checksum is equal to the checksum provided in backup application, given that the above conditions are met.

If the backup application is determined to be valid, the remaining process is described in the following figure.

Reliable update software implementation workflow

Note: Not all details are shown in the above figure.

Once the main application region is updated, the bootloader must erase the backup application region before exiting the reliable update process. This prevents the bootloader to update the main application image on subsequent boots.

Parent topic:Reliable update flow

Hardware implementation

For the hardware implementation, the backup application address is fixed and predefined in the bootloader, but a swap indicator address is required to swap the flash system. There are two ways for the bootloader to get the swap indicator address. If the reliable update process is issued by the host, the bootloader receives the specified swap indicator address from the host itself. Otherwise, the bootloader tries to receive the swap indicator address from the IFR, if the swap system is in the ready state.

The top level behavior of the reliable update process depends on how the bootloader gets the swap indicator address:

If the reliable update process is issued by the host, the bootloader does the same thing as software implementation until the validity of the backup application is verified.
If the reliable update process is from the bootloader startup sequence, the bootloader first checks the main application. If the main application is valid, then the bootloader exits the reliable update process immediately, and jumps to the main application. Otherwise, the bootloader receives the swap indicator address from IFR, then continues to validate the integrity of the backup application as the software implementation.

Note: It is expected that the user erases the main application region when reliable update process is intended with the next startup sequence. Otherwise, the reliable update process assumes no update is required, exits the process, and boots the image from the main application region

If the backup application is valid, see the remaining operations in the following figure.

Reliable update hardware implementation workflow

Note: Not all details are shown in the above figure.

Once the flash system is swapped (upper flash block becomes lower flash block), the bootloader naturally treats the backup application as the main application. In the hardware implementation, after the swap, it is not necessary to erase the image from the backup region.

Parent topic:Reliable update flow

Parent topic:Functional description

Parent topic:Bootloader Reliable Update

Configuration macros

The configuration macros defined in bootloader_config.h are used to enable the reliable update feature. For MCU bootloader v2.0.0, the feature is only enabled in the K65 Freedom and Tower flash target builds. All code added for this feature should be enabled only if the macros are defined. Currently, these macros are defined as:

BL_FEATURE_RELIABLE_UPDATE – Used to enable or disable the reliable update feature.
BL_FEATURE_HARDWARE_SWAP_UPDATE – Used to switch to the hardware or software implementation of reliable update.
BL_BACKUP_APP_START – Used to define the start address of the backup application if the reliable update feature is enabled.

Parent topic:Bootloader Reliable Update

Get property

A property has been added to get the state of reliable update. To implement this, a property member called reliableUpdateStatus has been added to propertyStore. Additionally, eight new status codes have been defined for the reliable update status. See the following table for details.

Reliable update status error codes

Status	Value	Description
kStatus_ReliableUpdateSuccess	10600	Reliable update operation succeeded.
kStatus_ReliableUpdateFail	10601	Reliable update operation failed.
kStatus_ReliableUpdateInactive	10602	Reliable update feature is inactive.
kStatus_ReliableUpdateBackupApplicationInvalid	10603	Backup application is invalid.
kStatus_ReliableUpdateStillInMainApplication	10604	(For hardware implementation only) The bootloader still jumps to the original main application.
kStatus_ReliableUpdateSwapSystemNotReady	10605	(For hardware implementation only) Failed to get the swap indicator address from IFR due to the swap system not being ready.
kStatus_ReliableUpdateBackupBootloaderNotReady	10606	(For hardware implementation only) Failed in copying the main application image to the backup application region.
kStatus_ReliableUpdateSwapIndicatorAddressInvalid	10607	(For hardware implementation only) Swap indicator address is invalid for the swap system.

Parent topic:Bootloader Reliable Update