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]

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

[dario.sortino]

Thanks Vidar.

I'm quite sad to say that thanks to your example I realized that I completely miss the cpunet subfolder in the build, so my problem is that I cannot even build for the network core, so I think that's why I cannot access the RTT streaming.

And that's a whole another problem. I'll find a solution for that. Thank you again!

[rockerderek]

Hi Vidar,

I tried your 1651.multicore build and flashed our custom 5340 board's net and app cores with the GENERATED_CP_APPLICATION_merged_domains.hex and GENERATED_CP_NETWORK_merged_domains.hex files, but every time I launch the RTT Viewer, I get the "CTRL-AP indicates that the device is secured" which causes the device to be re-flashed so the RTT can connect. I've attempted flashing with west flash --recover, JFlashLite, and NRF Programmer for Windows 10, but none have worked. I've attempted doing "nrfjprog --recover --coprocessor CP_NETWORK" and "nrfjprog --recover" but no matter how I reset or recover the device, the CTRL-AP is always secured. What can I do to get around this? I'm just using the latest DTM sample for the 5340 and adding CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y to each core's .conf file.

Thanks,

Brad

Fullscreen RTT-Viewer-Logs.txt Download

LOG: J-Link RTT Viewer V7.88m: Logging started.
LOG: Connecting to J-Link via USB...
LOG: Device "NRF5340_XXAA_NET" selected.
LOG: ConfigTargetSettings() start
LOG: ConfigTargetSettings() end - Took 10us
LOG: InitTarget() start
LOG: 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.


LOG: Executing default behavior previously saved in the registry.
LOG: Device will be unsecured now.
LOG: InitTarget() end - Took 766ms
LOG: Found SW-DP with ID 0x6BA02477
LOG: DPIDR: 0x6BA02477
LOG: CoreSight SoC-400 or earlier
LOG: AP map detection skipped. Manually configured AP map found.
LOG: AP[0]: AHB-AP (IDR: Not set)
LOG: AP[1]: AHB-AP (IDR: Not set)
LOG: AP[2]: MEM-AP (IDR: Not set)
LOG: AP[3]: MEM-AP (IDR: Not set)
LOG: AP[1]: Core found
LOG: AP[1]: AHB-AP ROM base: 0xE00FE000
LOG: CPUID register: 0x410FD214. Implementer code: 0x41 (ARM)
LOG: Feature set: Mainline
LOG: Cache: No cache

LOG: Found Cortex-M33 r0p4, Little endian.
LOG: FPUnit: 8 code (BP) slots and 0 literal slots
LOG: Security extension: not implemented
LOG: CoreSight components:
LOG: ROMTbl[0] @ E00FE000
LOG: [0][0]: E00FF000 CID B105100D PID 000BB4C9 ROM Table
LOG: ROMTbl[1] @ E00FF000
LOG: [1][0]: E000E000 CID B105900D PID 000BBD21 DEVARCH 47702A04 DEVTYPE 00 Cortex-M33
LOG: [1][1]: E0001000 CID B105900D PID 000BBD21 DEVARCH 47701A02 DEVTYPE 00 DWT
LOG: [1][2]: E0002000 CID B105900D PID 000BBD21 DEVARCH 47701A03 DEVTYPE 00 FPB
LOG: [1][6]: E0042000 CID B105900D PID 000BBD21 DEVARCH 47701A14 DEVTYPE 14 CSS600-CTI
LOG: RTT Viewer connected.

[Vidar Berg]

Hi,

Please try using the attached hex files and see if you get the same result. This time, I built the sample with CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y, and the DCDC regulators are disabled in case your board does not have the optional DCDC inductors mounted.

Symbols to disable the DCDC regulators (must be applied to the app core build)

CONFIG_BOARD_ENABLE_DCDC_APP=n
CONFIG_BOARD_ENABLE_DCDC_NET=n
CONFIG_BOARD_ENABLE_DCDC_HV=n

nrfjprog commands to program the hex files

$ nrfjprog --coprocessor CP_NETWORK --program net.hex --recover --verify
$ nrfjprog --program app.hex --recover --verify -r

hex files

4370.app.hex

net.hex