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.
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
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.
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).
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
Can you share exact details of which application you build and flash and every single command you use between recovering the first time and when this fails with the second application? For this to fail, there must be some point where either the UICR.APPROTECT is modified to no longer contain the magic word, or you program an application which does not enable debugging. We just need to find out which step you do that cases one of these things to happen.
It is basically the zigbee coordinator CLI example with CONFIG_NVS=y and CONFIG_SHELL=y. The only command that is used between recovery and flash is "west flash" with the nrfjprog runner.
It is basically the zigbee coordinator CLI example with CONFIG_NVS=y and CONFIG_SHELL=y. The only command that is used between recovery and flash is "west flash" with the nrfjprog runner.
Isee. But please provide exact steps to increase my chances of reproducing. From starting fresh, then changing to this directory, then calling this command, so this command, etc, until the issue is seen (by for instance not being able to read flash using nrfjprog --memrd).
Please also include which nRF Connect SDK version you are using, which nrfjprog version, etc. Please elaborate.
