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 protected in this call :

ret_val = nrf_bootloader_flash_protect(BOOTLOADER_START_ADDR,area_size,NRF_BOOTLOADER_READ_PROTECT);

Inside nrf_bootloader_app_start_final() of nrf_bootloader_app_start_final.c . Not sure in your case it's executed or not. 

But I'm not sure why you need to check the mbr_params_page. It's for the MBR to use internally and application, or bootloader should not write to it. 

If the bootloader start address is correct, the MBR supposed to forward the PC and vector table to the new bootloader address. Could you check where the PC is forwarded to after your download ? 

[naveenj]

mbr_params_page caught my attention because it is completely blank when I compare it with a working version. So nothing related to the start is present in that region?

I already commented the part which protects the flash.

Immediately, after the new bootloader is downloaded and reset, the PC reads 0x20010000.

[naveenj]

Oh man, I figured out what's happening. It was not because of the bootloader address, but it's the reset handler present in my hex file.

Somehow I missed verifying this in the beginning and overlooked it.

Very much appreciate your time and efforts. Thanks.

[Hung Bui]

Glad that you found the issue :D So you have a reset handler in your new bootloader ( or application ?) and it was doing something wrong ? 

[naveenj]

The first two words of bootloader's hex file are SP and Reset handler and the reset handler of the new bootloader was pointing to an undesired address, (while I was building the hex file, missed a step to update the address). And it is jumping to that undesired address.

So it jumps to the new address set in the UICR register, but due to the incorrect reset handler address, it crashes.