Boot loop during secure DFU upgrade with S140 from SDK 14.2.0 to SDK 15.0.0

[Austin]

I'm in the process of migrating from SDK 14.2.0 S140 5.0.0-2.alpha to SDK 15.0.0 with S140 6.0.0 on an nRF5280 based custom board.

It should be possible to do a secure DFU upgrade of BL+SD+APP by creating a zip package containing all these items. The BL+SD will be upgraded first, followed by the appliation.

The following command has been used to generate the BL+SD+APP zip package where 0x96=S140 5.0.0 and 0xa9=S140 6.0.0 with appropriate hex file inputs.

nrfutil pkg generate \
--hw-version 52 \
--sd-req 0x96,0xa9 \
--bootloader-version "$version_as_int" \
--bootloader "$bootloader_path_dest" \
--softdevice s140_nrf52_6.0.0_softdevice.hex \
--sd-id 0xa9 \
--application "$app_firmware_path_dest" \
--application-version "$version_as_int" \
--key-file src/bootloader/private.key \
"$app_sd_bl_firmware_dfu_dest"

After succesfully bonding in the app running from SDK 14.2.0 and initiating DFU using PC nRF Connect v2.3.0, the DFU download of BL+SD occurs and then hangs at 99% waiting for
the target device to respond.

If I turn on RTT logging for the SDK 14.2.0 bootloader, it's clear that the bootloader is in a reboot loop and outputs the following messages:

<info> app: Inside main
<debug> app: In nrf_bootloader_init
<debug> app: in custom nrf_dfu_init_user
<debug> app: In real nrf_dfu_init
<debug> nrf_dfu_settings: Running nrf_dfu_settings_init(sd_irq_initialized=false).
<debug> nrf_dfu_flash: Calling nrf_dfu_flash_init(sd_irq_initialized=false)...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> app: Initializing the clock.
<debug> app: Enter nrf_dfu_continue
<debug> app: Valid SD + BL
<debug> app: Enter nrf_dfu_sd_bl_continue
<debug> app: Enter nrf_bootloader_dfu_sd_continue
<debug> app: SD already copied
<debug> app: Verifying BL: Addr: 0x000E0000, Src: 0x000A43C8, Len: 0x0000AB74
<debug> app: Bootloader not verified, copying: Src: 0x000A43C8, Len: 0x0000AB74
**** Device resets and loops with the same messages ****

I have used nrfjprog to verify that the flash contents at 0xa43c8 do contain the new BL downloaded as part of the DFU zip package.

The nrf_dfu_mbr_copy_bl SVC call issued during the upgrade seems to result in a reset. I've added logging after the call, but the SVC call into the MBR never returns.

I'm using the following locations for binaries:

Binaries programmed from sdk 14.2.0
-----------------------------------
Bootloader 0xe0000, len 0x1e000
Bootloader settings page 0xff000, len 0x1000
MBR params page 0xfe000, len 0x1000
App 0x22000, len 0xbb000
app_data 0xdd000, len 0x3000

Updated binaries based on sdk 15.0.0 for BL+SD+APP DFU
-------------------------------------
Bootloader 0xe0000, len 0x1e000
Bootloader settings page 0xff000, len 0x1000
MBR params page 0xfe000, len 0x1000
App 0x26000, len 0xb7000 (Note: Both flash and RAM allocations for app have moved from sdk 14.2.0)

I have see this post but I don't believe this is relevant for SDK 14.2.0 and later.

How do I go about debugging this issue further?

[tesc]

Hi,

According to the release notes, s140_nrf52840_5.0.0-2.alpha uses MBR version 2.1.0, which has the following limitation:

• The SV-calls sd_mbr_command_vector_table_base_set() and sd_mbr_command_copy_bl() are not supported
  (DRGN-8197). Using these calls leads to undefined behavior.

What that means in practice is that bootloader update is not possible from the s140 5.0.0-2.alpha SoftDevice, as it leads to the behavior that you are experiencing. Since the MBR is not updated on SoftDevice update, the only option to fix this issue is to program MBR version 2.3.0, where the issue has been resolved, using a programmer. Preferably by using s140 version 6.0.0.

The issue only applies to alpha releases of the s140 SoftDevice, and was fixed prior to release of the (qualified) s140 v6.0.0 release which is the first production quality SoftDevice for the nRF52840.

Regards,
Terje