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.

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