Problem with bootloader relocation

[naveenj]

My goal is to replace the legacy bootloader present in nRF52832 with a new bootloader with the DFU process.

I am using nRF5 SDK v15.3.0, GCC ARM and S132.

I have done the following with the help of this.

To summarize,

• The new bootloader was copied into bank-1.
• Next, the UICR region is erased and the new address is written into 0x10001014 and also the other content which was present before erasing.
• I had verified the new address being written to 0x10001014 (NRF_UICR->NRFFW[0]).

Now the problem is that, after calling the sd_mbr_cmd(..) with SD_MBR_COMMAND_COPY_BL command, the device resets and doesn't start the new bootloader.

A similar question was asked here, but doesn't seem to have a solution.

I am not sure if I am missing something.

Thanks in advance.

Update: I have also verified (with the help of JLink by reading bytes at the new location) that the new bootloader is being copied into the new location.

[Hung Bui]

Hi Naveenj,

Could you do a nrfjprog --readcode and read the entire hex dump of the chip ? So that we would know if the softdevice and the bootloader is copied properly or not. 

Could you tell the softdevice version of the old one and the new one ? I would suggest to try to move from SDK v11 to SDK v12 as described in the guide first before trying to jump from SDK v11 to SDK v15. 

[naveenj]

I am using SDK v15 and softdevice S132 v6.1.1.

I verified with the help of nrfjprog --readcode that there is no change in the softdevice (at 0x1000), between the hex files obtained from 1. before writing the bootloader to the new location (working) and 2. after DFU, copying the new bootloader and resetting (not working).

I also verified that the bootloader is being copied to the new location (0x70000) which was 0x71000 previously. Also UICR->NRFFW[0] (0x10001014) reads 0x70000.

I have modified the code that copies the bootloader ("bl_activate()" in nrf_bootloader_fw_activation.c ) to include the UICR region erase and writes (from the post mentioned).

Also would you like to know any differences between the above said hex files?

[Hung Bui]

It's a little bit more complex now. 

You can have a look at  this case: https://devzone.nordicsemi.com/f/nordic-q-a/44768/sdk-15-3-cannot-program-default-bootloader

In SDK v15.3 (Softdevice v6.1.1) the MBR doesn't look into UICR first to check the bootloader start address but now it's inside MBR. 

The MBR is still backward compatible, so if there is no information inside the MBR setting page, it will look into UICR. 

Could you tell which legacy bootloader , softdevice and SDK you are updating from ? Or you are trying to update from SDK v15.3 to SDK v15.3 but with different bootloader address ? 

Please also be aware that inside the UICR there is not only bootloader start address but other information, so you need to copy the UICR content before erasing it, and then writing it back after (except for the bootloader start address) 

[naveenj]

Thanks for the info, I will look into that and see if that fixes the problem.

I am trying to update from SDK v15.3 to SDK v15.3 but with a different bootloader address. 

Yes, I had taken care of the UICR region as suggested by post. (Buffered the UICR data, modified 0x10001014 corresponding data alone and wrote back the buffered data to UICR region).

[Hung Bui]

Ok, so most likely that the MBR sees the bootloader star address inside the MBR setting page and won't update to follow the UICR change that you make. (this is not covered in the guide you followed because it's for earlier SDK).

What you need to do is to update the MBR setting page instead of UICR. Note that we call nrf_bootloader_flash_protect() at the beginning of the bootloader, this may block the bootloader from modifying the MBR setting page. So you need to update a bootloader that doesn't do so. 

[naveenj]

The address 0xFF8 shows FFFF.., every time, which means there is no address in the MBR region. In which case, it should use the address present in UICR region (0x10001014) but seems like it isn't doing so.

Or by saying "MBR Setting Page", did you mean the one present in UICR.NRFFW[1] (just after the bootloader - higher address / MBR Param Storage)?

Additionally, the following two check scenarios could be of help (supporting your hypothesis):

- copied the same bootloader to a different address (0x60000) faraway from the current one (also modified the UICR address to this) and it still jumps to the same old address 0x71000.

- over-wrote the existing bootloader just in place (i.e. at 0x71000) with the same code and I could verify that it works (staying at the older address).

I am lighting up an LED in the main() of the bootloader to know that the bootloader is functioning.

Update: when I read the content present at the address in UICR.NRFFW[1] (MBR Param Storage), it is cleared. Before writing the new bootloader, this address has some content.

Also, could you tell me how to interpret the data present in MBR Parameter Storage?