Device not booting after bootloader copy

RE: Device not booting after bootloader copy

Jean-Louis Bonnaffé — Thu, 02 Jul 2015 10:34:59 GMT

@hungbui Indeed, it was exactly that. I hadn't realized that the MBR swap meant to reset. Thank you very much !

RE: Device not booting after bootloader copy

jpo38 — Thu, 02 Jul 2015 07:38:30 GMT

No problem, I'm just not sure @Jean-Louis Bonnaffé got your message ;-)

RE: Device not booting after bootloader copy

Hung Bui — Thu, 02 Jul 2015 07:35:19 GMT

@Jean: Sorry about that. I didn't know the there is notification when using @. Will use correct name next time :)

RE: Device not booting after bootloader copy

jpo38 — Thu, 02 Jul 2015 06:31:42 GMT

@Hung Bui, you may want to edit you comment and replace @Jean by @Jean-Louis Bonnaffé, we are not the same person ;-)

RE: Device not booting after bootloader copy

Hung Bui — Wed, 01 Jul 2015 15:56:45 GMT

@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.

RE: Device not booting after bootloader copy

Jean-Louis Bonnaffé — Wed, 01 Jul 2015 10:01:32 GMT

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 ?

RE: Device not booting after bootloader copy

Hung Bui — Tue, 30 Jun 2015 15:09:03 GMT

@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 ?

RE: Device not booting after bootloader copy

Jean-Louis Bonnaffé — Tue, 30 Jun 2015 13:32:05 GMT

Hi Hung Bui,

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

The UICR boot address hasn't changed (0x38000).
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)
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

RE: Device not booting after bootloader copy

Hung Bui — Mon, 29 Jun 2015 12:48:15 GMT

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().