• State Not Answered
  • Replies 0 replies
  • Subscribers 94 subscribers
  • Views 28 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 362195
Options

nRF52840 DK recovery fails: invalid debug port ID and SWD connection failure

Kirolos Sedra

nRF52840 DK detected by J-Link, but recovery and SWD connection consistently fail

Hardware information

  • Board: nRF52840 DK

  • Board version: PCA10056

  • Failing board serial number: 1050246008

  • Known-good comparison board serial number: 1050227180

  • Host operating system: Windows x86-64

  • Connection: USB using the onboard J-Link debugger

  • Target voltage reported by J-Link: 3.300 V

Issue summary

The onboard J-Link debugger of an nRF52840 DK is detected normally over USB, and both virtual COM ports are available. However, the onboard nRF52840 target cannot be accessed through SWD.

The following operations consistently fail:

  • nrfutil device recover

  • nrfutil device device-info

  • Direct SWD connection using SEGGER J-Link Commander

Another nRF52840 DK of the same board version, PCA10056, successfully completed nrfutil device recover using the same computer and installed software environment.

The failure therefore appears to be specific to board 1050246008.

1. Device detection

Command:

nrfutil device list

Output:

1050246008
Product         J-Link
Board version   PCA10056
Ports           COM8, vcom: 0
                COM9, vcom: 1
Traits          jlink, usb, serialPorts, seggerUsb, devkit

Supported devices found: 1

The onboard J-Link debugger and both virtual COM ports are detected successfully.

2. Recovery failure

Command:

nrfutil device recover --serial-number 1050246008

The command was executed multiple times and consistently produced the same error:

x Failed to recover 1050246008, Device error: Setting the debug port SELECT register failed while powering up sys and debug regions

Error: One or more recover tasks failed:
 * 1050246008: Device error: Setting the debug port SELECT register failed while powering up sys and debug regions (Unknown Error in J-Link DLL (error code =-1)).

   This might indicate that the debug port is unavailable. Please double-check device power supply and SWD lines, and that SWD isn't disabled (Generic)

The error is reproducible and does not appear to be an intermittent single-command failure.

3. Device information failure

Command:

nrfutil device device-info --serial-number 1050246008

Output:

Error: One or more device info tasks failed:
 * 1050246008: Device error: The debug port identification register of this device has invalid values (bit 0 has value 0 instead of 1).

   The register might not have been read correctly due to issues with the SWD communication. Check the power supply and SWD lines. If you are using an external debugger, a voltage mismatch between the device and the debugger could cause this issue (Generic)

This suggests that the failure occurs during basic SWD debug-port communication, before recovery, erase, or device-information operations can proceed.

4. Direct J-Link Commander test

J-Link Commander was executed directly to bypass nrfutil.

The SWD speed was reduced to 100 kHz:

& "C:\Program Files\SEGGER\JLink_V922\JLink.exe" -USB 1050246008 -Device NRF52840_XXAA -If SWD -Speed 100 -AutoConnect 1

Output:

SEGGER J-Link Commander V9.22 (Compiled Feb 24 2026 12:24:28)
DLL version V9.22, compiled Feb 24 2026 12:23:25

Connecting to J-Link via USB...O.K.
Firmware: J-Link OB-nRF5340-NordicSemi compiled Jul  8 2025 10:15:34
Hardware version: V1.00
J-Link uptime (since boot): 0d 00h 07m 45s
S/N: 1050246008
License(s): RDI, FlashBP, FlashDL, JFlash, GDB
USB speed mode: Full speed (12 MBit/s)
VTref=3.300V
Device "NRF52840_XXAA" selected.

Connecting to target via SWD
InitTarget() start
InitTarget() end - Took 162ms
InitTarget() start
InitTarget() end - Took 162ms
Error occurred: Could not connect to the target device.
For troubleshooting steps visit: kb.segger.com/J-Link_Troubleshooting

The direct J-Link test was repeated and produced the same result.

This confirms the following:

  1. The onboard J-Link debugger connects successfully over USB.

  2. The correct J-Link serial number is selected.

  3. The target reference voltage is present at 3.300 V.

  4. Direct SWD communication fails even at 100 kHz.

  5. The failure also occurs outside nrfutil.

5. Software versions

nRF Util

Command:

nrfutil --version

Output:

nrfutil 8.1.1 (b6089d0 2025-08-21)
commit-hash: b6089d08a9cfdb292f8ab8d21e0908ded814cd11
commit-date: 2025-08-21
host: x86_64-pc-windows-msvc
build-timestamp: 2025-08-21T14:12:43.593658000Z
classification: nrf-external

nRF Util device command

Command:

nrfutil device --version

Output:

nrfutil-device 2.14.0 (fc03a3f 2025-09-16)
commit-hash: fc03a3f4e33bdcc94452363f8b42a464de48166a
commit-date: 2025-09-16
host: x86_64-pc-windows-msvc
build-timestamp: 2025-09-16T10:22:49.097602400Z
classification: nrf-external

Detected SEGGER J-Link version: JLink_V9.22

The command also displays this warning:

The device command version you are currently using was tested with a different J-Link version (JLink_V8.60) than the one you have installed (JLink_V9.22). The tested version is not required, and your J-Link version will most likely work fine. If you get issues related to J-Link with your devices, use the tested version.

Installed nRF Util commands

Command:

nrfutil list

Output:

Command            Version  Description
device             2.14.0   Device discovery, programming, and operations such as erase, reset, and recovery.
sdk-manager        1.10.0   Install and manage SDK and toolchain installations for the nRF Connect SDK.
toolchain-manager  0.15.0   Manage and use toolchains for nRF Connect SDK

Found 3 installed command(s)

SEGGER J-Link installation

SEGGER J-Link Commander V9.22
DLL version V9.22
Installation path:
C:\Program Files\SEGGER\JLink_V922\JLink.exe

Although the installed J-Link version differs from the version against which nrfutil-device 2.14.0 was tested, another identical PCA10056 board successfully completed recovery using the same installed environment.

6. Known-good comparison board

A second nRF52840 DK, also identified as PCA10056, was tested using the same computer and installed tools.

Known-good board serial number:

1050227180

Recovery command:

nrfutil device recover --serial-number 1050227180

Result:

v Recovered 1050227180

This indicates that the host-side nrfutil installation, USB connection, and installed J-Link environment can successfully recover another board of the same model.

The same recovery procedure also succeeded previously on other Nordic boards in this environment.

7. Current diagnostic findings

The following points have been confirmed:

  1. The failing board is detected as PCA10056.

  2. Its onboard J-Link debugger is detected over USB.

  3. Both virtual COM ports are detected.

  4. nrfutil device recover fails consistently.

  5. Repeating the recovery command produces the same error.

  6. nrfutil device device-info cannot read a valid debug-port identification register.

  7. J-Link Commander connects successfully to the onboard debugger.

  8. J-Link Commander reports VTref=3.300V.

  9. Direct SWD connection to the nRF52840 fails.

  10. The direct SWD test still fails at a reduced speed of 100 kHz.

  11. The issue occurs independently of the higher-level nrfutil recovery operation.

  12. Another PCA10056 board recovers successfully using the same host environment.

Based on these results, the issue appears to be located between the onboard J-Link debugger and the target nRF52840, or within the target MCU/debug interface itself.

8. Technical questions

  1. Does this evidence indicate a likely hardware failure in the onboard nRF52840, the onboard SWD path, or the connection between the onboard J-Link debugger and the target?

  2. Is there another recovery procedure that can access the target when the Debug Port Identification Register cannot be read?

  3. Could a switch position, solder bridge, debugger-routing configuration, or board setting on PCA10056 cause this behavior while J-Link still reports VTref=3.300V?

  4. Are there specific solder bridges or test points that should be inspected to verify the onboard SWD connection?

  5. Should J-Link V8.60 still be tested even though another PCA10056 board recovers successfully using J-Link V9.22?

  6. Are there resistance, continuity, or signal measurements that Nordic recommends for checking SWDIO, SWDCLK, RESET, target voltage, and ground?

  7. Can this condition be caused by firmware, access-port protection, APPROTECT configuration, an interrupted flash operation, or an interrupted recovery operation?

  8. Is there any recovery-under-reset or alternative low-level procedure that may still work in this condition?

  9. Based on the included evidence, should this board be considered defective and returned or replaced?

9. Return or replacement

If these diagnostics confirm that the board has a hardware fault and that no additional recovery procedure is available, the next step will be to return or replace the faulty board.

Please confirm whether the diagnostic results are sufficient to classify board 1050246008 as defective or whether another specific test should be completed before initiating the return.

10. Preventive guidance and safe daily operation

I would also appreciate guidance on preventing this type of failure during normal development.

In particular:

  1. What are the most likely causes of permanent or repeated SWD/debug-port failure on an nRF52840 DK?

  2. Can firmware, access-protection settings, incorrect flashing, interrupted recovery, or power loss during programming leave the board in this condition?

  3. Is there a recommended safe day-to-day sequence for:

    • connecting the board;

    • powering it;

    • connecting external peripherals;

    • building and flashing firmware;

    • resetting it;

    • recovering it;

    • disconnecting it?

  4. Should the board always be powered off before connecting or removing:

    • GPIO wires;

    • SWD connections;

    • debug connections;

    • external power;

    • UART connections;

    • other development boards or peripherals?

  5. Are there specific voltage, grounding, ESD, USB, or external-peripheral precautions that should be followed?

  6. Is it safe to power the DK through USB while another device is connected to its power or GPIO headers?

  7. What precautions are required when the connected external device has its own power source?

  8. Should grounds always be connected before signal wires and disconnected after signal wires?

  9. Are there recommended checks that should be performed before each flash or recovery operation?

  10. Are there operations or wiring practices that should be avoided because they could damage:

    • the onboard target MCU;

    • the onboard debugger;

    • the SWD lines;

    • the voltage-regulation circuitry;

    • the USB interface?

  11. Is there a recommended method for safely handling access-port protection and recovery during routine development?

  12. Would Nordic recommend any surge protection, ESD protection, current limiting, powered USB hub, or isolation when frequently connecting and disconnecting development hardware?

A recommended safe operating procedure for routine development would be especially helpful so that this issue can be proactively avoided on the remaining boards.

Related
Terms of service