nRF5340 NVS and readback_protection

[mnvcsUDT]

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 

[Einar Thorsrud]

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.

[mnvcsUDT]

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. 

[Einar Thorsrud]

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

[mnvcsUDT]

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.

[Einar Thorsrud]

I do not see this on my side using nRF Connect SDK 1.7.0 (which uses v2.6.99-ncs1 tag of the NCS zephyr fork). Are you using NCS or are you using Zephyr stand-alone? If using NCS, then please let me know the details of how you work so that perhaps I can spot the issue (if you for instance do a full chip erase without subsequently recovering or similar).

CONFIG_NRF_SECURE_APPROTECT_LOCK does not exist in the current nRF Connect SDK release (1.7.0).

[mnvcsUDT]

Yes, I am using the exact same version. From the ncs master branch. 
After running --recover all works fine for the first flashing, the second one fails due to read protection.

ERROR: The operation attempted is unavailable due to readback protection in
ERROR: your device. Please use --recover to unlock the device.
ERROR: runners.nrfjprog: Flashing failed because the target must be recovered.
  To fix, run "west flash --recover" instead.
  Note: your target is an nRF53; all flash memory for both the network and application cores will be erased prior to reflashing.
FATAL ERROR: command exited with status 16: nrfjprog --program .../build/zephyr/GENERATED_CP_NETWORK_merged_domains.hex --sectorerase -f NRF53 --snr 960180710 --coprocessor CP_NETWORK