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]

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.