Hard-fault on SBL re-entry, Application Note AN12037 (LPC11U6x USB DFU Secondary Bootloader)

[d_m_]

Hi,

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[256]; // This must be added at Line 28
// ...
buffer[0] = 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.

David

[ZhangJennie]

Hi David,

Thanks. I will feedback this to the author.

Regarding to the dual image. They are in different flash locations. SBL checks the header and version numbers. If both the information is valid for SBL, SBL selects the newest version image as the active application. In the case if this version of application image gets corrupt, the other application can still work as a backup.

Jun Zhang.

[d_m_]

Concerning the first point, it seems that there is an error in the linker script of the SBL provided in the source code of AN12037. For re-entry from app, the SBL RAM should start at address 0x10000000 with a length of 0x200 if we follow the recommendation of the doc (Ch. 6). However the linker script set the RAM of the SBL at 0x10000200. In "sourcecode/sbl_dfu_lpc11u60/Debug/sbl_dfu_lpc11u6x_Debug_memory.ld":

Ram0_32 (rwx) : ORIGIN = 0x10000200, LENGTH = 0x7e00 /* 32256 bytes (alias RAM) */

This line should probably be:

Ram0_32 (rwx) : ORIGIN = 0x10000000, LENGTH = 0x200 /* 512 bytes (alias RAM) for SBL */

Also, the symbols "__base_Ram0_32", "__base_RAM", "__top_Ram0_32" and "__top_RAM" must be changed accordingly.

Note that the linker script in the Release configuration seems also erroneous.