Bootloader not copying the new updated bootloader to the correct location.

[rhaguiuda]

We have a running project with nRF52840 + S140 7.2.0 - SDK: 17.0.2 + Bootloader.

I need to change the size of our bootloader in a production environment. This update must be done OTA (no option for SWD).

After reading some post on Nordic support, it's clear that this needs to be a 3 step process:

Step 1: Write OTA a custom bootloader that changes the UICR->NRFFW[0] address to the new location of the incoming bootloader and enter into DFU waiting for the image. This bootloader should save the other registers and restore back, since we will issue an eraseuic command.

Step 2: Receive the new bootloader with increased size.

Step 3: Receive the new application (kinda optional since the app start address did not change).

The current bootloader uses the default Nordic start address 0x000F8000 and size of 0x6000 (24kB). This bootloader does not have enough memory to future updates, whence we need to increase it's size.

The new bootloader was increased in size to 0xB000 (45kB) and start address of 0x000F3000.

I was able to create the step 1 bootloader and enter into DFU and receive the second bootloader with no errors (had to fix an image size check that was giving error 4 - insufficient resources).

After the nRFConnect finished the update, the second bootloader does not run, and the device is bricked.

Reading back the memory of the device, I can see that the UICR->NRFFW[0] is correctly set to 0x000F3000, indicating that the first bootloader did fix the start address for the incoming bootloader.

However, when I read the 0x000F3000 address it is blank, and data only starts at the old bootloader address of 0x000F8000.

It seems that when the firmware is running the bootloader activation procedure (bl_activate), the function nrf_dfu_mbr_copy_bl is copying the bootloader to the wrong destination.

After long hours of research, I confirmed on the SD documentation, that the sd_mbr_command SD_MBR_COMMAND_COPY_BL should use as the destination address of the copy, the value written in UICR->NRFFW[0], which in my case is correct. So I was expecting the copy to be done in the correct destination address.

Can you please help me to understand what might be wrong?

 

[Amanda Hsieh]

Hi, 

In Master boot record section:

The MBRPARAMADDR address can be provided either at the MBR_PARAM_ADDR flash memory location, which is defined in nrf_mbr.h, or in the UICR.NRFFW[1] register. Using the flash memory location is the safest because it can be read/write protected. This is also the location that will be checked first by the MBR. UICR.NRFFW[1] is checked only if MBR_PARAM_ADDR has the
default value, which is 0xFFFFFFFF.

So the MBR is ignoring the address in UICR because the BL start address has been written to MBR_BOOTLOADER_ADDR. You can try to write 0xf000 to MBR_BOOTLOADER_ADDR to flip the LSB in your current address. 0xf3000 will not be possible as that would require erasing the whole flash page between 0x0 - 0x1000 first, and you must do so before the bootloader has protected the MBR with the ACL.

Regards, 
Amanda

[rhaguiuda]

Hi Amanda, thank you for your reply.

I was able to figure out the issue.

The problem is that I did not understand the whole DFU process.

After the bootloader image is received, it is saved in bank1 and the postvalidation process validates the image and store information on the DFU page that an valid image is available to be activated on next reset (activation is just a nice name for copying it from bank1 to the final destination).

After the postvalidation, the device is reset. 

When the bootloader starts, it checks for a pending activation process, than it does the activation.

My mistake was that I was setting the new bootloader address at UICR->NRFFW[0] at the beginning of the bootloader, and you can only do that just before the activation, otherwise, when the system resets, it will reset to an invalid bootloader location.

After applying this changes, the bootloader worked perfectly.

Thank you for your support.