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

nRF5340 NVS and readback_protection

Hi Everybody,

We found little or no literature about readback_protection on the nRF5340 SOC. Our issue is that for development and debugging it is not practical to use nrfjprog -recover in order to re-flash as that completely erases the storage partition too. What is the right way to retain NVS data?

Thank you.

Regards,

Milan 

  • Hi Milan,

    You can find documentation about access port protection in the CTRL-AP - Control access port chapter in the product specification.

    If I understand you correctly, then this question is about how you handle this during development. And in that case it typically does not make sense to prevent debugging, so then you simply disable access port protection. If you program an application that has been built without ENABLE_APPROTECT defined then you should be good to go (as nrfjprog --recover will have written to UICR.APPROTECT allready, and as long as you do not do a full chip erase or write more to that register, it retains its value and debugging will continue to be enabled as long as you do not program firmware built with ENABLE_APPROTECT defined.

  • Thank you Einar for the help and explanation. Exactly that, we wanted to make sure to do this right so development is easier.

    All clear now!

    Regards,

    Milan

  • Almost all clear.

    Except, it is still totally unclear how this is done in practice. There are mentions of using a 32-bit key (?) for both the 

    NRF_CTRLAP_S->APPROTECT.DISABLE register and the debugger. But again this is just speculation. Can you please point me to a guide how to disable this? And re-enable in case. 
  • Hi,

    The chapter in the product specification I linked to shows the specific details, including that the magic word is 0x50FA50FA.

    In practice this is handled by the tools. When you get a new device or a locked device that you want to debug, you can recover using nrfjprog --recover. This will write to UICR.APPROTECT, and also flash a very simple temporary application that enables debugging. When you subsequently build your firmware the MDK is included and ENABLE_APPROTECT is not defined by default. So any new firmware you build and program will disable AP protection, i.e. keep enabling debugging.

    Note that west has a --recover option which lets you recover (including write to UICR.APPROTECT) and program in a single operation: west flash --recover

  • Hi Einar,

    Thank you. That seems to be clear. The problem is that in Zephyr 2.6.99-ncs it is re-enabled all the time. I cannot exactly locate where this happens.  And that makes development work impossible as I have to recover the SOC between every flashing. Loosing NVS storage as well.

    CONFIG_NRF_SECURE_APPROTECT_LOCK=n does not seem to be supported yet. I assume this will solve the issue for Zephyr 2.7.0.
Related