Device not booting after bootloader copy

[Jean-Louis Bonnaffé]

Hi,

Slight problem here with bootloader updates : right after download, I copy from SWAP (0x16000) to normal location (0x38000 in my case).

sd_mbr_cmd.command               = SD_MBR_COMMAND_COPY_BL;
sd_mbr_cmd.params.copy_bl.bl_src = 0x16000
sd_mbr_cmd.params.copy_bl.bl_len = settings.bl_image_size;
sd_mbr_command(&sd_mbr_cmd);

After this operation , the bootloader is correctly copied. However, my device doesn't boot any more. Flash dumps indicate that the two last pages of s110 (0x0800 to 0x0FFF) have been updated, as indicated in this thread : devzone.nordicsemi.com/.../

the updated data parts are :

0x800 : 00 00 00 00 00 60 01 00  20 35 00 00 04 98 03 00
0xC00 : 00 00 00 00 FF FF FF FF  FF FF FF FF FF FF FF FF

Any idea why this happens ?

[Hung Bui]

Hi Jean,

Could you check if the bootloader start address in UICR (NRF_UICR_BOOT_START_ADDRESS, 0x10001014) is correctly point to the start address of your bootloader ?

If you update the same hex file for the bootloader, would it work ? You can try to read out the image before and after the bootloader update and compare them, you can upload them here.

You can try to run the bootloader in debug mode and see if it can get to main().

[Jean-Louis Bonnaffé]

Hi Hung Bui,

I've tried downloading the same bootloader that was already flashed.

1. The UICR boot address hasn't changed (0x38000).

2. Flash dumps are attached here and here. The diffs are located at 0x800 (softdevice), 0xC00 (softdevice), 0x16000 (swap area - contains the bootloader image), and 0x3EC00 (data copied from the swap area, every time I boot)

3. Debug session under Keil : the execution is stuck at offset 0x38334, which is in the arm_startup_nrf51.s

(according to the .map output)

0x00038320   0x00000048   Code   RO    63    .text         arm_startup_nrf51.o
0x00038368   0x000006e0   Code   RO    70    .text         main.o

[Hung Bui]

@Jean-Louis: I assume that you modified the start address of bootloader ? Seems your is at 0x38000 Our bootloader starts at 0x3C000.

Address 0x3EC00 is pretty strange for me, what is that Swap ?

Comparing the 2 dump I also saw difference at 0x37800. I assume that's where your application data is ?

Could you send me your bootloader project file for testing here ? Please let me know your SDK version, and S110 version. Have you tried to test with our stock bootloader example ?

[Jean-Louis Bonnaffé]

Yes, 0x38000 is our mapping for the bootloader.

What you can see at address 0x3EC00 is just some data copied from the swap area @0x1CC00, which is some remaining data from the application present when we started downloading - it was not fully erased.

For address 0x37800, good guess - it is our application data, which was updated during the download process. Noteworthy, we have modified this structure to fit our needs - could it be responsible for boot pb ?

FYI my SDK version is v6_1_0_b2ec2e6, the softdevice is v7.1.0, the bootloader in the SDK is fine, and I can send you my project, but only on a private channel.

One more note : after investigation, the only diffs that prevent our device from booting are those located in s110 (@0x800, @0xc00) AND in the app data (@0x37800). Is the bootloader start sequence expecting to find something specific in the app data ?

[Hung Bui]

@Jean: I found maybe a bug in your code.

In your bootloader code, you have modified bootloader_dfu_sd_update_continue() to again do a dfu_bl_image_swap() if p_bootloader_settings->bl_image_size != 0, this is not enough. You should combine it with a SD_MBR_COMMAND_COMPARE (dfu_bl_image_validate) to check if the image is already copied correctly or not. If it already copied correctly, don't do another dfu_bl_image_swap() or you will stay in a loop forever.

The reason for that is when you call dfu_bl_image_swap(), it's a kamikaze call. The MBR will take over, swap the bootloader and do a reset. The result is that you will reset back to bootloader, and if you do another swap you will stay in a dead loop.

When you finished with updating the bootloader (validate return success), you should erase the swap area (0x16000).

However, I tried to fix that in your code, and ended up the bootloader being erased (0xFFFFF). I 'm running out of time for futher debug for now, but I would suggest you to look into the bug I mentioned above.

If the MBR succeed in swaping the BL, data at address 0xC00 should = 0xFFFFFFFF. Otherwise it will stuck in updating the BL.