This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Device not booting after bootloader copy

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 ?

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

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

Reply
  • 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 ?

Children
No Data
Related