RTT viewer or Segger message: CTRL-AP indicates that the device is secured (J-Link V6.88a Info)

[Bruno Saraiva]

Working in a Windows 64 environment with nRF Connect SDK v1.5.0. Target is a custom nRF5340 board connected through a nRF5340-PDK as a debugger, via USB.

I can no longer use RTT Viewer to connect to our target: any attempt to connect pops up a message saying CTRL-AP indicates that the device is secured... Do you want to unsecure the device?

Answering YES fully erases the target. Answering NO results in denied connection.

 

The same message is popping up when trying to run the debugger directly via Segger (the debugger works, but only after it fully erased the target and reuploaded the code).

This was not happening before, but we are unsure of what was changed to cause it and how to get around.

Regards

Bruno

[Vidar Berg]

Hello,

This was not happening before, but we are unsure of what was changed to cause it and how to get around.

Have you changed the silicion revision since then, and are you building the project for the new revision? As you may know, revision eng. D/1 of the nrf5340 include an updated implementation of the readback protection mechanism compared to eng. revision A used on the nRF5340 PDK board. What's different is that this new mechanism  require the FW to unlock the chip on startup (taken care of by the MDK startup files if you build for the new chip) . 

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_nrf5340.html#readback-protection

Regards,

Vidar

 

[rookie]

Hello, 

I hit similar problems on the network core. I can confirm that the function `nrf53_handle_approtect` is being compiled in and the following branch is taken: 

/* Load APPROTECT soft branch from UICR.
If UICR->APPROTECT is disabled, CTRLAP->APPROTECT will be disabled. */
NRF_CTRLAP_NS->APPROTECT.DISABLE = NRF_UICR_NS->APPROTECT;

However when I try to load a new binary in the network core, I am greeted with this message on JLink 7.50a (similar behavior with older JLink like 7.22):

Selecting SWD as current target interface.

Selecting 4000 kHz as target interface speed

Device "NRF5340_XXAA_NET" selected.


Connecting to target via SWD
ConfigTargetSettings() start
ConfigTargetSettings() end
InitTarget() start
CTRL-AP indicates that the device is secured.
For debugger connection the device needs to be unsecured.
Note: Unsecuring will trigger a mass erase of the internal flash, SRAM and UICR of both the application and the network core.

Any ideas to work around this? It's rough to keep reprogramming with a full erase every time

[Vidar Berg]

Hello,

It shouldn't be necessary to perform a full erase for subsequent re-programming of the network core as longs as both the app and network core are executing the 'nrf53_handle_approtect' code on startup. Could please try with nrfjprog as instructed here (link) and see if you encounter the same problem?

[dario.sortino]

I'm experiencing the same issue. I tried to recover the network core before the appcore as suggested in the link above, but nothing changed. Right now I cannot access RTT of the Network core (APPcore is fine)

[Vidar Berg]

Does it work if you open a logging session with RTT viewer first for the app core, then the netcore? 

[dario.sortino]

Unfortunately not

I also tried to use CONFIG_NRF_APPROTECT_USE_UICR = n (both application and network core image), but I'm not entirely sure if it's related.

[Vidar Berg]

I see. If readback protection is indeed enabled, you should get a connection error when you try to start the RTT session. Is that what you are seeing, or are you able to connect, but not see any logs?

[dario.sortino]

If I try to start the RTT for the NETCORE session it appears the error shown in the original post:

If I press yes, the whole board doesn't function anymore, but I can access to both RTT sessions (they show nothing except that they start); if I press no I can go back to the RTT session for the APPCORE without any issue, the board still works.

Maybe, since I'm using a custom board, I'm missing something in the devicetree? 

/dts-v1/;
#include <nordic/nrf5340_cpuapp_qkaa.dtsi>

/ {
	model = "boardname";
	compatible = "nordic,boardname";

	chosen {
		zephyr,sram = &sram0;
		
		...
		...
		...

My dts starts like this.