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