Struggling to isolate custom nRF52840 board from DK on-board debugger

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

Simon D-M — Fri, 03 Jul 2026 08:31:02 GMT

Hi,

[quote user="lassey0"]

The marking on the IC is:

N52840

QIAAD0

Could you confirm whether QIAAD0 corresponds to Revision 2 or Revision 3 silicon?

[/quote]

This is Revision 2. You can see it in the compatibility matrix documentation (link).

[quote user="lassey0"]Also, based on the schematic and these symptoms, do you see anything that could explain why the device appears protected before it has ever been programmed? Or does this behavior suggest a hardware issue with the board or the MCU itself rather than the missing nRESET connection?[/quote]

I am not too sure about what is happening here... After further checking of the hardware, I can indeed see some issues with the schematic. I am not sure if they are the root of your problem, but they definitely need to be fixed.

The main errors that I could see are:

DEC4 <---> DEC6: They should be connected together (link).
DEC5: currently connected to GND, but should be left floating (link).
(minor) Leave the unused GPIO pin floating, and it is a good practice to still expose them if you have the space on your PCB.

But please remember that I am not a hardware engineer, so please take it with a grain of salt.

Also, have you made some voltage measurements on your board? Can you please check if the power supply is managing to output a stable voltage?

And are the decoupling capacitors close enough to the nRF52840?

Best regards,

Simon

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

lassey0 — Wed, 01 Jul 2026 16:49:03 GMT

Hi Simon,

Thanks for taking over the case.

Unfortunately, I cannot use another GPIO as a reset pin because this PCB revision is already manufactured. The nRESET pin (P0.18) is not routed anywhere, and since this is the QFN73 package, there is no practical way to probe or wire directly to the pad under the package.

Regarding programming:

The chip has never been successfully programmed.
SWD communication is present. J-Link consistently detects the SW-DP (ID 0x2BA01477) and the CTRL-AP.
However, the AHB-AP/core is never accessible. J-Link reports “Could not find core in Coresight setup,” and both nrfutil device recover and nrfjprog --recover fail because the access port remains protected after erase and reset.
I have tested with both an nRF52840-DK (PCA10056) and an nRF51-DK (PCA10040) as external debuggers, with identical results.

The marking on the IC is:

N52840

QIAAD0

Could you confirm whether QIAAD0 corresponds to Revision 2 or Revision 3 silicon?

Also, based on the schematic and these symptoms, do you see anything that could explain why the device appears protected before it has ever been programmed? Or does this behavior suggest a hardware issue with the board or the MCU itself rather than the missing nRESET connection?

And can you confirm if these gnd connections are critical errors that are keeping the access to the chip impossible (photo):

For example DEC5, P0.30, P0.10 exc.

Thank you for your help.

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

Simon D-M — Wed, 01 Jul 2026 15:00:17 GMT

Hi,

Sorry, Simon is not available for the moment, so I'm taking over this case. If you feel like I am missing some context, please feel free to give me the context that I missed.

[quote user="lassey0"]Can you confirm that the schema is alright and it should work without the reset pin access[/quote]

I'm not a hardware engineer, but it looks OK to me.

Have you tried to use another GPIO pin as a substitute reset pin like Simon proposed in one of his previous message?

Or is it that you can't program your chip at all ?

Best regards,

Simon D-M

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

lassey0 — Fri, 26 Jun 2026 13:17:11 GMT

Hi,

In the chip it says N52840 and QIAAD0 below. Can you confirm that the schema is alright and it should work without the reset pin access

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

Simonr — Thu, 25 Jun 2026 09:05:41 GMT

How have you confirmed the revision of your board? I don't see anything obvious to do from a schematic level that will enable you to do a reset on your boards.

Best regards,

Simon

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

lassey0 — Wed, 24 Jun 2026 19:34:28 GMT

i'm still confuse because i have the rev2 version of nrf52840. Can you maybe take a look schema if there is something i can change or add. But the reset pin has no outs so its fully out of the play.

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

Simonr — Thu, 11 Jun 2026 11:42:14 GMT

Hi Lasse

In that case I'm afraid there isn't a good way to rewrite the UICR. If you can, it is possible to route the reset pin through an unused GPIO to get it "out" as long as that GPIO isn't used for anything and left unconnected/floating in software.

Best regards,

Simon

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

lassey0 — Wed, 10 Jun 2026 08:41:33 GMT

i think no because the chip is nRF52840-QIAA-R which has aQFN73 package and the reset pin is in inside column. Also i think jlbpcb souldered every pin for more firm grip but there is no reset trace outside the chip.

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

Simonr — Wed, 10 Jun 2026 08:13:54 GMT

Okay, yes that checks out. Unfortunately that isn't good news for your design as the APPROTECT (UICR) will indeed require a reset in order to be written/erased.

Is there no way to get the RESET button at all on your end or to trigger a reset on your custom boards?

Best regards,

Simon

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

lassey0 — Tue, 09 Jun 2026 13:16:52 GMT

To double-check, we also tried the latest nrfutil (v8.1.1) with nrfutil-device (v2.17.5). The behavior confirms the hardware limitation:

> nrfutil device erase

x Failed to erase: The Application core access port is protected

> nrfutil device recover x Failed to recover: Device error: Access port is still protected after Erase and Reset (Generic)

This logs perfectly match the Revision 3 behavior where the lack of an nRESET connection prevents the chip from latching the open state after a mass erase.

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

lassey0 — Tue, 09 Jun 2026 13:10:58 GMT

Hi Simon,

Thanks for the suggestions. We did some lower-level register and connection analysis using the standalone J-Link Commander in both device-specific and generic Cortex-M4 modes to avoid J-Link automatic unsecuring interference. Here are the clear results:

Physical SWD connectivity is 100% functional. J-Link successfully reads the DP ID and scans the AP map every time:

text

Found SW-DP with ID 0x2BA01477
Scanning AP map to find all available APs
AP[0]: JTAG-AP (IDR: 0x23000000, ADDR: 0x00000000)
AP[1]: JTAG-AP (IDR: 0x02880000, ADDR: 0x01000000)

The AHB-AP is completely hidden/skipped: As seen in the log, J-Link iterates through the AP map but the main AHB-AP is missing/invisible. It only discovers the Nordic CTRL-AP (0x02880000).
CTRL-AP Erase & Soft-Reset sequence fails to unsecure: We successfully forced a mass erase via the CTRL-AP registers (SWDWriteAP 0 0x00000001) followed by a CTRL-AP soft-reset (SWDWriteAP 4 0x00000001 -> 0x00000000) and a manual power cycle (pulling both VDD and VTG to prevent parasitic power).
However, upon the next connection attempt, the chip immediately blocks AHB-AP access again with Could not find core in Coresight setup.

This behavior strongly indicates the Revision 3 APPROTECT mechanism. Because our custom PCB completely lacks a connection to the nRESET (P0.18) pin, the chip is unable to latch the unsecured state during a proper hardware reset cycle, rendering the power cycle ineffective for recovery. So there isnt no way to get past to the APPROTECT mechanism?

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

Simonr — Tue, 09 Jun 2026 12:37:50 GMT

Hi Lasse

If you could reupload the image you shared in the initial ticket I think that would help. The nrfjprog --recover command shouldn't require a connection to the RESET pin from what I can tell, but please make sure that the target device is powered at 3.0V as well so it is detected correctly by the debugger. Also you can try running the nrfjprog --eraseall command to see if that makes a difference.

It's also worth mentioning that nrfjprog is archived and replaced by nrfutil now. This doesn't mean it shouldn't work, but it won't be getting any more updates in the future.

Best regards,

Simon

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

lassey0 — Tue, 09 Jun 2026 10:35:26 GMT

Sidenote:

We performed direct CTRL-AP register reads via J-Link Commander (CTRL-AP.png):

SWDWriteDP 2 0x01000000

SWDReadAP 0x00 = 0x00000000 (RESET)

SWDReadAP 0x04 = 0x00000000 (ERASEALL)

SWDReadAP 0x08 = 0x00000000 (ERASEALLSTATUS)

SWDReadAP 0x0C = 0x00000000 (APPROTECTSTATUS)

All CTRL-AP registers return 0x00000000. This means the chip acknowledges the SWD connection at DP level (DPIDR = 0x2BA01477) and J-Link detects CTRL-AP, but all AP-level register reads return zero. Is this nRF52840 v2 APPROTECT behavior where the chip is locked and blocks all AP access including CTRL-AP register reads and recovery requires a mandatory hardware reset via nRESET pin which is not accessible on this PCB design so pcb is bricked

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

lassey0 — Mon, 08 Jun 2026 09:54:47 GMT

What I observe in J-Link Commander:

SWDReadDP 0 returns 0x2BA01477 consistently every time, so the DP level is clearly working. However all AP level reads return zeros or garbage:

SWDReadAP 0x00 = 0x00000000
SWDReadAP 0x08 = 0x00000000
CTRL-AP registers = 0x00000000

connect result always:

CTRL-AP indicates that the device is secured.
Found SW-DP with ID 0x2BA01477
AP[0]: JTAG-AP (IDR: 0x23000000)
AP[1]: JTAG-AP (IDR: 0x02880000)
Could not find core in Coresight setup
Cannot connect to target.

nrfjprog --recover --family nrf52 result:

Recovering device. This operation might take 30s.
error -21: Command recover executed for 3124 milliseconds
error -90: Access protection is enabled, can't read device version.
ERROR: Recover failed.

I have tried both PCA10056 and PCA10040 as debugger with identical results. The schematic has been verified — VDD, all decoupling capacitors, 32MHz and 32.768kHz crystals are all correct.

Is the missing nRESET the root cause of the recovery failure? And is there any way to recover the device without a nRESET connection?

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

Szabolcs — Mon, 08 Jun 2026 09:45:14 GMT

Hi,

I cannot see the picture you attached, can you please attach it again?

Please see the image below on how to connect your custom board to the DK:

Please note that SWD_SEL must be connected to nRF_VDD. See more info on this page. If all the connections are correct, the debugger should recognize your board.

While it is possible to flash the chip without connecting reset, it is recommended to have a reset line available, especially in the development phase. (It is needed for recovery, for example.)

RE: Struggling to isolate custom nRF52840 board from DK on-board debugger

Turbo J — Mon, 08 Jun 2026 07:35:18 GMT

There are pretty images in the manual how to connect to external targets. Google may not find them currently due to website restructure but they should not be too difficult to locate (hence why I don't provide link here either).

Missing RESET is a redesign.

Any minor mistake in clock/dcdc/bootloader config likely requires a recovery operation - that is timed to RESET.