trouble with nrf_dfu_mbr_copy_bl

[steve]

Hi,

I'm trying to implement a custom bootloader update on the nRF52840 using SoftDevice s140 and SDK 13.0.0. With my new bootloader staged in a scratch region of flash, I'm trying to use nrf_dfu_mbr_copy_bl() to copy the new bootloader. The relevant code is:

res = nrf_dfu_mbr_compare( bootloader_address, scratchpad_address, update_len );
if ( NRF_SUCCESS != res )
{
  res = nrf_dfu_mbr_copy_bl( scratchpad_address, update_len );
}
else
{
  scratchpad_erase();
}

What happens is nrf_dfu_mbr_copy_bl() triggers a reset (as expected), but the next time around nrf_dfu_mbr_compare() still returns NRF_ERROR_NULL, and so the device continually calls nrf_dfu_mbr_copy_bl() and resets. Is there some initialization I'm missing? Do I need to disable the SoftDevice before doing this? I'm not using anything else from the DFU module, and I have the bootloader start address and MBR params page programmed into UICR. Any help would be appreciated!

Update 2017/8/7:

As I mentioned in the comments below, the behavior I'm seeing now is rather than constantly resetting, the code gets stuck in nrf_dfu_mbr_copy_bl(). Attaching a debugger I see I'm getting a hard fault. It appears to be a bus fault at address 0x10040013 that is escalated to a hard fault. Stack dump is:

r0	0x20000400
r1	0x000008E5
r2	0x00000579
r3	0x000008C5
r12	0x00000583
lr	0x0000058D
pc	0x00000597
psr	0x00000000

Update 2017/8/8:

I've reproduced the problem with a really simple project: copy_bl_test.zip

[steve]

I've done some playing around with how my code list laid out in flash (thinking maybe I needed a BOOTLOADER_SETTINGS region even though I'm not using DFU), and now it seems to hang in the call to nrf_dfu_mbr_copy_bl. Resetting has no effect, nothing runs, only completely re-programming the chip gets things running again.

[steve]

For reference I have UICR.NRFFW[0] = 0xd2000 and UICR.NRFFW[1] = 0xfe000

[Hung Bui]

Have you modified anything in the bootloader ? Or it's your bootloader you are developing ?

You can check if the new bootloader is actually copied and overwritten over the old bootloader by reading the flash content and compare it with before doing DFU.

[steve]

This is my bootloader, not the Nordic bootloader. I have dumped the contents of flash and compared, and the only difference between before and after is some values written to the MBR params page. The actual bootloader itself is identical, so it hasn't been updated.

I did try erasing the MBR params page via JTAG after it gets stuck, and then after resetting it comes back again and tries to do the bootloader update, so it appears as though it's getting stuck in the MBR.

[Hung Bui]

Hmm, it's hard to say what could be wrong. But have you tried to update modified bootloader ? In our MBR code we use a memcmp to compare the area where the bootloader is and the address where the image is and check if they match. If matched, we stop, erase the mbr param page and do a reset. Seems that the MBR param page is not erased. And from what you described, the chip stuck in a loop inside MBR after you call nrf_dfu_mbr_copy_bl() ?