This post reports two problems we identified with the integration of a secondary bootloader (SBL) for firmware updates on a LPC11U68. We followed the application note AN12037 (LPC11U6x USB DFU Secondary Bootloader, Rev. 1 – September 2017), and performed tests with the development board OM13058 (LPC11U68 development board, Xpresso v2 rev. C, OM13058), and MCUXPresso IDE 10.0.0.
Note: ZhangJennie This is the second post we made on the SBL described in AN12037. The first post concerned the creation of a factory image: How to create a non-encrypted factory image with custom secondary bootloader on LPC11U68
Problem 1: The SBL re-entry code generates a hard-fault when some big-enough static variables are defined in the application. Hence the SBL cannot be invoked from the application and become useless.
The problem is quite easy to reproduce from the code provided with the AN12037 and the development board OM13058. Here are the steps:
- Import the source code of AN12037 in MCUXpresso containing four projects: “app_blinky”, “lpc_board_nxp_lpcxpresso_11u68”, “lpc_chip_11u6x”, and “sbl_dfu_lpc11u60”.
- Erase the flash of the development board to be sure that there is no remaining application in image "slots".
- Build the “sbl_dfu_lpc11u60” and program the SBL to the development board (via LinkServer or using the primary bootloader).
- In the project “app_blinky”, in the file “app_blinky.c” add an array declaration outside any function and a reference to this array in the main (to avoid optimization):
uint8_t buffer; // This must be added at Line 28
buffer = 0; // This must be added at Line 129
- Build the “app_blinky” application and create a binary. Add a CRC to the binary using “lpc11xx_secimgcr.exe”:
lpc11xx_secimgcr.exe app_blinky.bin app_blinky.dfu
- Load “app_blinky.dfu” using “dfu-util.exe” (via USB connected to “Target” on the development board):
dfu-util.exe -t 64 -D app_blinky.dfu
- The application will boot, then after 10 seconds, the application reinvokes the SBL and the SBL will crash,i.e. call to hard-fault handler.
It seems that the SBL crashes when “SystemCoreClockUpdate()” is called in “main_dfu.c” line 250. It may be due to the AEABI division patch, or a problem with the BSS section.
Problem 2: It seems that there is no “dynamic” management of the “dual-image” feature. Using “dfu-util.exe” to update the application with a binary, whatever the new application version is, it will be placed in the first application space (starting from 0x2000).
To what I understand, the dual image feature should protect from firmware update failure. That is, when the most recent application resides in the image slot 1, the SBL will use the slot 2 to download the new firmware and vice versa. It is only when a new application as been completely downloaded with a correct CRC and a more recent version number, that the SBL will boot it. That is not how the proposed SBL in AN12037 works.
Hence my question; how should the “dual-image” feature work?
Again, thanks for your support.