Moving or removing the Nordic DFU bootloader seems impossible with approtect set

[BasvR]

For various reasons we need to remove the dfu bootloader to use our custom bootloader.  We replace the Nordic bootloader with a temporary one that does the clean-up for us.  On our bench in debug mode this works fine (clear the uicr, clear the mbr, and clear the last words in the softdevice).  HOWEVER, when we try to do this over the air on devices that are with customers and have APPROTECT set, we are never able to clear the uicr, or to clear the first page of the softdevice (the mbr), to remove the address of the bootloader.  If we do it over the air on devices without approtect set, it works fine.  Our procedures, fw etc are identical, the only difference is that in case we set read back protection it just does not work.  Are we doing something wrong?  Is there a protection that gets set in the SoftDevice we are not aware of?

We are seeing this problem on nrf52832 and nrf52840 with the sd332_6.1 and the sd340_7.0 respecitvely.  Both on the pca boards and in our production boards

[BasvR]

Hi,

I/we don't understand why APPROTECT would be made write once and/or coupled to the erasing of other parts of the memory.  I think the two are not related and it should be the programmer's responsibility to deal with security.  However, after reading more yesterday I came to the same conclusion that Nordic has implemented it this way, and it is what it is.

I would however recommend that you add a very big warning note to your manual about UICR, because the way the UICR is explained now it is portrayed as flash memory and not at all as OTP (except in non-secure settings, such as dev).  The same holds for the DFU: once you put it in, it is impossible to remove or move.  So that should be the first thing you should read if you are considering using it, I would think.

I have been working along the way you have suggested.  I don't understand your last remark: "The MBR will then jump to the new bootloader location. It's still not possible to remove the bootloader though but you can make a very small bootloader that does only one task to jump to the application."  Could you not just have the MBR jump to the application?  So you would not use a new bootloader at all?  Or will that cause problems with interrupt vectors?

Thanks,

Bas

[Hung Bui]

Hi Bas, 
I agree that we may need to have better warning about APPROTECT and UICR .  But if you have a look at the nRF52 specification you can find this: 

So it's pretty clear there that UICR won't be changed if you set the APPROTECT. 

It's most likely the reason why we move the start address of the bootloader from UICR to the MBR setting page inside the MBR. 

The reason I mentioned that "it's not possible to remove the bootloader" is that once you have something written in the bootloader start address in the UICR and if you can't remove that, the MBR will always think that there is a bootloader. Even if you can change the start address of the bootloader to the application start address, the process of booting up would no longer the same as you have no bootloader (bootloader start address = 0xFFFFFFFF in both MBR setting and in UICR ). When there is no bootloader the MBR will start the softdevice first and then softdevice jump to application. If there is a bootloader, the MBR will start the bootloader first and then it's the bootloader who decides to start the softdevice or not. 

So what you can do is to make a very small bootloader , change the start address of this bootloader to the very top of the flash. I guess saving space in flash is what you want to achieve by removing bootloader ? 

[Mark TK]

Hello,

I have been following this topic with great interest. I hope my followup question is appropriate here.

Hung Bui wrote:

> If there is a bootloader, the MBR will start the bootloader first and then it's the bootloader who decides to start the softdevice or not.

If I understand this correctly, then when I have a custom bootloader, a softdevice and an application, I can run the application by letting my bootloader start the softdevice, which will in turn invoke the application. How do I let my bootloader tell the softdevice the address of my application when it is not in the default place?

Thank you,

Mark

[Hung Bui]

Hi Mark, 
I would suggest to create a new case for your question, you can give a referral link to this case if you want. 

A quick answer your question, there are 2 options: 

1. Jump to the first address of the softdevice, just like what we do in nrf_bootloader_app_start() then the softdevice will be initialized and the softdevice will jump and forward the vector table to the first address after the softdevice (the application). This is the default behavior. You can't change the application address. 

2. Jump to the application address as you wish. From there you can initialize the softdevice and run, similar to the bootloader. Please look for nrf_dfu_mbr_init_sd() call in the bootloader.