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

[lassey0]

Hi,

I am developing a custom PCB based on the nRF52840 and am currently trying to flash/debug it using an nRF52840-DK (PCA10056) as an external debugger. 

connected devices like this without the custom board: 

So how do I connect the custom board when I have made testpads for vdd, gnd, swdio, swdclk. No testpad for nReset and no way to get to it anymore.

im seeing in the pca10056 3.0.3 p20 where are connections to 

pin 1: VDD_nRF

pin 2: VDD_nRF

pin 3: SWD SEL

pin 4: SWD IO

pin 5: SWD CLK

pin 6: SWO

pin 7: RESET

pin 8: empty

pin 9: VIN 3-5V

pin 10: VDD nRF_HV

pin 11: VDD nRF_HV

pin 12: VIO REF

pin 13: empty

And which way the all switches needs to be?

[Simonr]

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

[lassey0]

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:

1. 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)
   
2. 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).
3. 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?

[lassey0]

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.