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

[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.

[Vidar Berg]

Hi,

I was able to replicate the same here with another example. That is, I could not get any logs from the netcore. I will need some more time to investigate. Will keep you posted on the progress.

[dario.sortino]

That's great! Thank you vidar!

[Vidar Berg]

I asked internally about this. It turns out you can only read RTT messages from one core at a time, unfortunately. So, in your case, it may be best to use RTT for fast logging on the network core (assuming you are still running ESB there) and UART for logging on the application core.

[dario.sortino]

Thank you Vidar, that's really helpful.

I guess this translates in just setting 

CONFIG_UART_CONSOLE=n

CONFIG_USE_SEGGER_RTT=y

CONFIG_RTT_CONSOLE=y

as mutually exclusive in both core (depending on what I want to debug with RTT)

Edit: unfortunately I still see the error if I set as above in the network core, and 

CONFIG_UART_CONSOLE=y

CONFIG_USE_SEGGER_RTT=n

CONFIG_RTT_CONSOLE=n

in the application core

[Vidar Berg]

I verified here by having RTT logging enabled on both cores, but only opening one instance of the RTT Viever with the *_NET device selected.

Does your RTT viewer configuration look like this when you try to get logs from the netcore?

Here is the project I used for testing in case you want to give it a try:

1651.multicore.zip