Disable access port protection and debug access port

[Tonio]

Hi, 

I'm using nrf52840 in revision 3, which has protection access port enabled by default. 

My application is built with SDK15.0.0 / SDS S140 6.0.0

In order to get debug session, i have added in my code the following sequence at the beginning of the main function : 

	NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
	while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
				
	NRF_UICR->APPROTECT = UICR_APPROTECT_PALL_HwDisabled;
		
	*(volatile uint32_t *)0x40000558 = 0x0000005A; // SwDisable registre APPROTECT.DISABLE 

	NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
	while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

It had worked few times (i was able to do 10 debug sessions approximatively) and now i can't start debug session. Since i try to start a debug session, i have the following Jlink error : 

JLink info:
------------
DLL: V8.42 , compiled Jun 11 2025 12:15:45
Firmware: J-Link V11 compiled Apr  1 2025 10:02:30
Hardware: V11.00
S/N : 51007305 
Feature(s) : GDB 
 
* JLink Info: ConfigTargetSettings() start
* JLink Info: ConfigTargetSettings(): Enable Monitor Mode Debugging
* JLink Info: ConfigTargetSettings() end - Took 2.72ms
* JLink Info: InitTarget() start
* JLink Info: InitTarget() end - Took 4.74ms
* JLink Info: Found SW-DP with ID 0x2BA01477
* JLink Info: Failed to power up DAP
* JLink Info: ConfigTargetSettings() start
* JLink Info: ConfigTargetSettings(): Enable Monitor Mode Debugging
* JLink Info: ConfigTargetSettings() end - Took 3.92ms
* JLink Info: InitTarget() start
* JLink Info: InitTarget() end - Took 3.19ms
* JLink Info: Found SW-DP with ID 0x2BA01477
* JLink Info: Failed to power up DAP
Error: Flash Download failed  -  Target DLL has been cancelled
Flash Load finished at 09:43:07

After several google researchs, i have found the IN141 v1.1, where it's advised to upgrade the MDK to the lastest version (MDK 8.40.2 or later). In my case, i'm using MDK in 8.16.0 version.

Due to this older version, It seems i have breaked my chip. 

In the information notice, there are steps to recover debug port where the first step is to perform  a CTRL-AP ERASEALL operation.

I have tried to do it with the nrfConnect programmer tool, however it can't to access to the chip (see log above) : 

11:26:42.580	Selected device with the serial number 000051007305
11:26:42.581	Using nrfutil device to communicate with target via JLink
11:26:53.024	Reading readback protection status for Application core
11:26:53.026	Reading readback protection status for Application core 0%
11:27:03.071	Failed "reading readback protection status for application core". Error: code: 1, description: Generic, message: Batch task protection-get failed, Device error: A timeout occured while handling debug power: Timed out trying to power sys and debug region
11:27:03.079	Error: Failed with exit code 1. One or more batch tasks failed: * 51007305: Device error: A timeout occured while handling debug power: Timed out trying to power sys and debug region (Generic) Message: Batch task protection-get failed, Device error: A timeout occured while handling debug power: Timed out trying to power sys and debug region.
11:27:03.079	Error: Failed with exit code 1. One or more batch tasks failed: * 51007305: Device error: A timeout occured while handling debug power: Timed out trying to power sys and debug region (Generic) Message: Batch task protection-get failed, Device error: A timeout occured while handling debug power: Timed out trying to power sys and debug region.

Is there any way to recover the nrf chip and the debug access port? 

Thanks in advance,

Antoine

[Tonio]

Hi Vidar,

Thank you for your reply. 

I have measured the SWD signals. They are in the expected range (3V3) and respected the idle state (SWDCLK is low due to pull down / SWDIO is high due to pull up) when the jlink probe is disconnected or connected. 

When i try to start a debug session, signals also match the expected voltage. However, the nReset signal is stuck to GND, whatever i have tried. 

Thanks to this thread : https://devzone.nordicsemi.com/f/nordic-q-a/30538/nrf52832-custom-board---reset-stuck-low i am able to success the recovery the chip from the nrfutil tool, by connecting directly to VDD the nReset signal during the command execution.

Now i'm able to flash the SoftDevice from the programmer tool and start a debug session from Keil... However, it seems that the application code doesn't run (breakpoint is never reachable) and the nReset is going to low immediatly.

I'm precising that the macro CONFIG_GPIO_AS_PINRESET is defined in my keil project and there is no application code which redefines this gpio.

What is the expected behavior of the nReset signal? 

[Vidar Berg]

Hi,

OK, this is a case where the FW can "brick" the device. Are you only testing with your application now, or is there also a bootloader which may access this pin?

Things you can do to troubleshoot this:

1. Read out the GPIO configuration register after reaching main() in your app (PIN_CNF[18]) to confirm it's configured with its reset value

2. Disable the pinreset functionality by removing the CONFIG_GPIO_AS_PINRESET symbol and erase the current UICR configuration followed by a power cycle, then configure the pin in your FW to output high or input with pull up enabled to see if you are able to drive the pad high.

[Tonio]

Hi all,

i'm continuing my investigations. I have tried several manipulations in order to do some debug sessions, I finally succeed. Here the list of the most judicious operations i have done : 

• i have sent the nrfutil cmd 'Device pinreset-enable'
• I have disconnected the reset signal from the jlink probe
• I have added in my code the nReset pin initialization as input with pullup
• I have added an external 10k pullup resistor

This is better but i had always debug interruption.

In order to have others informations, i have added two leds. The first is activated when application code is running. The second is used to determine the reason of reset (through the nrf_power_resetreas_get() function). After debug interruption, the second led is activated indicating a hard reset.

i have also tried with only the internal pullup, and after only with the external pull resistor, it doesn't change the behavior (debug session can be done but it's erratic).

[Tonio]

Hi vidar, 

our posts crossed paths. I don't use a bootloader.

It looks like nReset signal is floating and it occurs involuntary reset. It's really surprising since i'm using pullup on the reset pin. Is a10k resistor enough to pull up the signal? 

[Vidar Berg]

With nRESET enabled on the pin (CONFIG_GPIO_AS_PINRESET), the internal pull up will be enabled so it should not be floating, even if you didnt have an external pull up.