Bootloader update bricked device due to different start addresses - How to prevent?

[Andy]

Hello,

Today I had a case where I tried to perform a bootloader-only DFU on a device with a debug version of the bootloader, but instead of trying to replace it with another debug version, I tried to replace it with a release version. I was not aware that the device had a debug version of the bootloader and bricked it.

As I understand it, the device got bricked because the start address of the new bootloader didn't match with the old one, i.e. vector table is in the wrong place and it just doesn't work (correct me if I'm wrong please).

My question is, how can I prevent this situation? I want the bootloader to reject any bootloader updates that could brick the device like this. I know that a bigger bootloader would be rejected (e.g. trying to flash a debug version on a release version), but a smaller version has no problems and can still potentially brick the device if the start addresses are different.

Is there anything I can do to prevent this?

Thanks for your advice!

[Einar Thorsrud]

Hi,

The bootloader is always copied so that it starts at the address given in UICR.NRFFW[0]. The problem is if the bootloader (release variant in this case) has linker settings that specifies a different start address. To avoid this, make sure that you set the same start address for both the debug and release version.

The bootloader does not have any mechanism to prevent this from occurring. It would not be straight forward, and it has not been seen as a practical issue. The reason for this is that the image must be signed in any case, so the only risk of bricking devices in the field is if you ship untested signed upgrade images. In this case, there are also a number of other ways to brick the device that has nothing to do with the bootloader.

[Andy]

Thanks for your answer!