https://devzone.nordicsemi.com/f/nordic-q-a/35164/bootloader-update-bricked-device-due-to-different-start-addresses---how-to-preventHello, 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 awareen-USTelligent Community 13Fri, 08 Jun 2018 13:49:35 GMThttps://devzone.nordicsemi.com/thread/135381?ContentTypeID=1Fri, 08 Jun 2018 13:49:35 GMT137ad170-7792-4731-bb38-c0d22fbe4515:96beda02-0541-481f-8fcf-9a59c2103a66Andy<p>Thanks for your answer!</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/135141?ContentTypeID=1Thu, 07 Jun 2018 11:55:05 GMT137ad170-7792-4731-bb38-c0d22fbe4515:cbb1cdcb-8d8b-464e-8829-b56fb2081e11Einar Thorsrud<p>Hi,</p> <p>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.</p> <p>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 <em>untested </em>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.</p><div style="clear:both;"></div>