This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

Parents
  • Hi BasvR, 
    Could you give more information on how you did the task to erase the MBR (?) , and UICR etc ? 

    Are you doing it inside your temporary bootloader code or you doing the erase with a debugger/programmer ? 

    If you are doing it in your code I don't see why APPROTECT would affect the process. APPROTECT only block the access from the external programmer/debugger. When the BPROT protect the flash access from the code in different blocks.

    When you mentioned "we are neer able to clear" , what exact happened ? Did you receive any error code ? 

  • 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

Reply
  • 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

Children
  • 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. 

Related