Hi,
I unsecured my device and running it with JLink RTT to observe logging. If I program uicr registers during this process, the devices gets secured and I have to redo programming all over again. I am using the following sample command -
nrfjprog --coprocessor CP_NETWORK --memwr 0x01FF8308 --val 0x00000009
Can you suggest how to avoid this?
Hi Rookie!
That is the nRF5340s APPROTECT feature. It is essentially writing protected by default.
Try recovering it first, (which should additionally write a small binary stopping it from locking up) using:
nrfjprog --recover --coprocessor CP_NETWORK
nrfjprog --recover
For more info about working with the '53 take a look here, and for more info about APPROTECT take a look here.
Best regards,
Elfving
Hello, yes I have already recovered the device and wrote my own image to it. I can see that the app-protect branch is handled in way to disable app-protect. `nrf53_handle_approtect` is called and `NRF_CTRLAP_NS->APPROTECT.DISABLE = NRF_UICR_NS->APPROTECT;` is compiled in.
Until this point my device was debggable. Then I used the memwr function in nrfjprog and the device got secured, since the next time I tried to JLink into the device, it complained that the device is secured.
My question is why/how would JLink find out that the APPROTECT is enabled AFTER this nrfjprog call is made? Something happens after this `memwr` call that is setting APPROTECT, isn't it?
Hmm that is a bit strange.
Could you try it once without JLink RTT? And could you try to read the value you wrote after memwr and see if it complains about SPU?
nrfjprog --coprocessor CP_NETWORK --memrd 0x01FF8308
Best regards,
Elfving
Hmm that is a bit strange.
Could you try it once without JLink RTT? And could you try to read the value you wrote after memwr and see if it complains about SPU?
nrfjprog --coprocessor CP_NETWORK --memrd 0x01FF8308
Best regards,
Elfving
I am unable to do the read when the device is locked. I'm a bit perplexed by this behavior. What this points to is that the value of APPROTECT in the UICR changes from 0x50FA50FA, to something else which locks me out. One thing to note that my debugger connected and gdb was running when I'd tried to do this. This wasn't a problem before, but may be it is on the latest revisions?
I'm also curious what this comment in the `nrf53_handle_approtect` function means:
Use this if you want to enable authenticated debug.
Can you point to some resources that talk about authenticated debugging?
Hey Rookie! Sorry for the late reply, I have been away for a while.
rookie said:I'm a bit perplexed by this behavior.
So am I. Your memwr command shouldn't enable approtect on its own, so I assume there is something with the image you've written to the chip that is making it happen. What is on this image of yours? Did you write/do anything to UICR?
Ands could you send it to me so that I can try it on my end?
rookie said:Use this if you want to enable authenticated debug.
Can you point to some resources that talk about authenticated debugging?
Ah, this is referring to some undocumented and unfinished functionality you don't have to worry about. Just never mind that option.
Best regards,
Elfving
