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?

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

[Simonr]

Hi

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

[lassey0]

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.

[Simonr]

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