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

[Vidar Berg]

Hello Antoine,

It's not only important to update the MDK to support the approtect handling mechanism, but also to ensure the necessary errata workarounds are applied on startup. The old startup files will not recognize the new silicon revision. However, regardless of the FW you have running on the device, you should still be able to recover the chip by performing the ERASEALL through the CTRL-AP port. It's best to do this through the command line using nRF Util:

# Recover procedure include the following steps: 
# - Perform ERASEALL through CTRL-AP port
# - Write unlock value to UICR.APPROTECT to unlock approtect in HW.
# - Øoad a small FW binary to disable SW APPROTECT.
# 
nrfutil device recover

Best regards,

Vidar

[Tonio]

Hi Vidar,

Thank you for your reply. 

In the meantime i have found the tip about the nrfutil tool. 

I have tried it on my custom board with the jlink probe (base version) and i get this error : 

C:\Users\antoine\Downloads\Installer>nrfutil.exe device recover --serial-number 51007305
x Failed to recover 51007305, Device error: A timeout occured while handling debug power: Timed out trying to p
Error: One or more recover tasks failed:
 * 51007305: Device error: A timeout occured while handling debug power: Timed out trying to power sys and debug region (Generic)

Also, the led on the jlink probe is always in orange color, which means that the reset signal is always active. 

Does It look like an HW failure? 

[Vidar Berg]

Hi,

The error we are seeing is a generic one indicating that the debug probe is unable to communicate with the target chip. There can be many potential reasons for this, but it is not caused by the fw running on the chip. 

Tonio said:

Since the nrfutil tool  recover command doesn't work, is there an additionnal HW / FW way i can try to recover the chip? 

When recover does not work it indicates that the chip is not operating normally due to a HW problem, or connectivity issue between the debug probe and chip. Could you try measuring the voltage on the SWDIO line just to confirm it matches the exepcted VDD voltage?

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

[Tonio]

Hi Vidar,

I have tried to read back the PIN_CNF[18] register when the CONFIG_GPIO_AS_PINRESET macro is defined in my Keil project. It shows me that pin is configured in input but with no pull (register value = 0x02). Since there is no pullup, device is always in reset. 

Due to the macro definition, the following code is executed in the system_nrf52840.c : 

#if defined (CONFIG_GPIO_AS_PINRESET)
        if (((NRF_UICR->PSELRESET[0] & UICR_PSELRESET_CONNECT_Msk) != (UICR_PSELRESET_CONNECT_Connected << UICR_PSELRESET_CONNECT_Pos)) ||
            ((NRF_UICR->PSELRESET[1] & UICR_PSELRESET_CONNECT_Msk) != (UICR_PSELRESET_CONNECT_Connected << UICR_PSELRESET_CONNECT_Pos))){
            NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NRF_UICR->PSELRESET[0] = 18;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NRF_UICR->PSELRESET[1] = 18;
            NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
													
            NVIC_SystemReset();
        }
    #endif

To my understanding, it maps reset function to a pin number. However, I don't see any code which define this pin configuration? 

If i deactivate the CONFIG_GPIO_AS_PINRESET, the reset mechanism is disabled and i have no problem.

Is there any change on this part with the revision 3. We usually use nrf52840 parts in older revision in our product and we never have been worried about it.

[Vidar Berg]

Hi,

Tonio said:

I have tried to read back the PIN_CNF[18] register when the CONFIG_GPIO_AS_PINRESET macro is defined in my Keil project. It shows me that pin is configured in input but with no pull (register value = 0x02). Since there is no pullup, device is always in reset. 

0x2 (input, disconnect) is the reset value for the pin config. register and is correct setting for when PINRESET is enabled. 

Tonio said:

To my understanding, it maps reset function to a pin number. However, I don't see any code which define this pin configuration? 

The GPIO peripheral does not control and should not attempt to control the pin when it is assigned to be a reset pin.

Tonio said:

Is there any change on this part with the revision 3.

The pinreset behavior did not change between these 2 revisions.

Have you tried to measure if the reset line is pulled low externally? For instance by measuring the resistance between the pad and ground? 

[Tonio]

Hi Vidar,

I'm sorry for my late answer. I have measured the resistance between pad/ground. I got 1Mohm approximatively. 

I have disabled the CONFIG_GPIO_AS_PINRESET macro in order to develop my application but it will be interesting to understant what's going on.

[Vidar Berg]

Hi,

I agree, it would be good to understand what's causing this. I haven’t been able to find any other reports that match this, and I also can’t think of anything that would explain why it suddenly started occurring or why the issue is occurring intermittently. Perhaps it would make sense to try and see if you can reproduce this with one of the original SDK examples as well? Also, probe the reset signal with an oscilloscope to see when the signal is driven low.