Unable to connect to nRF52840 via SWD

[Nopik]

Hello,

I'm playing with nRF52840 on a custom board, trying to connect to the chip via SWD. Segger Flasher is being used, on MacOS. Typically I was able to connect to the board via JLinkExe like this:

SEGGER J-Link Commander V6.20g (Compiled Oct 20 2017 17:09:21)
DLL version V6.20g, compiled Oct 20 2017 17:09:12

Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM / Flasher ARM V4 compiled Oct  6 2017 16:42:52
Hardware version: V4.00
S/N: <removed>
License(s): JFlash, GDB
IP-Addr: DHCP (no addr. received yet)
VTref = 3.320V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: NRF52840_XXAA
Type '?' for selection dialog
Device>
Please specify target interface:
  J) JTAG (Default)
  S) SWD
TIF>S
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "NRF52840_XXAA" selected.


Connecting to target via SWD
Cannot connect to target.
J-Link>connect
Device "NRF52840_XXAA" selected.


Connecting to target via SWD
Found SW-DP with ID 0x2BA01477
SWD speed too high. Reduced from 4000 kHz to 1518 kHz for stability
Found SW-DP with ID 0x2BA01477
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
AP[1]: JTAG-AP (IDR: 0x02880000)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS
ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
Cortex-M4 identified.
J-Link>

Apart of the 4000->1518 kHz SWD speed reduction, it looked normal. All JLink commands were working too, as far as I know. After a while when I loaded some .bin file:

J-Link>erase
Erasing device (nRF52840_xxAA)...
Comparing flash   [100%] Done.
Erasing flash     [100%] Done.
Verifying flash   [100%] Done.
J-Link: Flash download: Total time needed: 21.180s (Prepare: 0.031s, Compare: 0.000s, Erase: 21.144s, Program: 0.000s, Verify: 0.000s, Restore: 0.004s)
Erasing done.
J-Link>loadbin /.../nrf52840_xxaa.bin, 0
Downloading file [/.../nrf52840_xxaa.bin]...
Comparing flash   [100%] Done.
Erasing flash     [100%] Done.
Programming flash [100%] Done.
Verifying flash   [100%] Done.
J-Link: Flash download: Bank 0 @ 0x00000000: 1 range affected (40960 bytes)
J-Link: Flash download: Total time needed: 0.530s (Prepare: 0.067s, Compare: 0.007s, Erase: 0.000s, Program: 0.416s, Verify: 0.000s, Restore: 0.038s)
O.K.
J-Link>

the board basically went dead, or almost dead, I can't connect to it anymore. The bin file was supposedly innocent, it was working fine on reference board, just with few logs in main().

Now, when I do try to connect, this is being displayed (I did upgrade of JLinkExe from 6.20g to 6.22d in meantime, hoping for solution, that had apparently no effect):

SEGGER J-Link Commander V6.22d (Compiled Dec 14 2017 18:33:52)
DLL version V6.22d, compiled Dec 14 2017 18:33:43

Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM / Flasher ARM V4 compiled Oct  6 2017 16:42:52
Hardware version: V4.00
S/N: 164204911
License(s): JFlash, GDB
IP-Addr: DHCP (no addr. received yet)
VTref = 3.325V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: NRF52840_XXAA
Type '?' for selection dialog
Device>
Please specify target interface:
  J) JTAG (Default)
  S) SWD
TIF>S
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "NRF52840_XXAA" selected.


Connecting to target via SWD
Found SW-DP with ID 0x6BA01477
SWD speed too high. Reduced from 4000 kHz to 1518 kHz for stability
Found SW-DP with ID 0x2BA01477
Could not power-up debug power domain.
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map has been reached
Iterating through AP map to find AHB-AP to use
Found SW-DP with ID 0x2BA01477
Found SW-DP with ID 0x2BA01477
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map has been reached
Iterating through AP map to find AHB-AP to use

****** Error: Could not find core in Coresight setup
Found SW-DP with ID 0x2BA01477
Found SW-DP with ID 0x2BA01477
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map has been reached
Iterating through AP map to find AHB-AP to use
Found SW-DP with ID 0x2BA01477
CTRL-AP indicates that the device is secured.
For debugger connection the device needs to be unsecured.
Note: Unsecuring will trigger a mass erase of the internal flash.
Device will be unsecured now.

****** Error: InitTarget(): PCode returned with error code -1
Cannot connect to target.
J-Link>

So, SW-DP ID is apparently read, power leds on flasher are green (turn to red if I do power off on the board), but it can't connect. I tried nrfjprog -f NRF52 --recover --log but it did failed:

--------------------------------------------------------------------------------
nrfjprog -f NRF52 --recover --log
nrfjprog verion 9.7.1
--------------------------------------------------------------------------------
FUNCTION: open_dll.
FUNCTION: open_dll.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: connect_to_emu_with_snr.
FUNCTION: connect_to_emu_with_snr.
FUNCTION: connect_to_emu_without_snr.
FUNCTION: enum_emu_snr.
Device "NRF52832_XXAA" selected.
FUNCTION: recover.
FUNCTION: recover.
JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -1.
JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -102.
FUNCTION: close_dll.
FUNCTION: close_dll.

as many other nrfjprog commands (all erase commands I could find in help, resets, e.g. --pinreset, --eraseall, ----eraseuicr and so on). They all fail on that -1 and -102 errors.

Also, tried lots of different jlink commands, but virtually all of them return SWD connection errors like above. SWDReadAP and SWDReadDP counterparts seem to work somehow, they print some values (mostly zeroes, but not always):

J-Link>SWDReadAP 0
Read AP register 0 = 0x00000000
J-Link>SWDReadAP 1
Read AP register 1 = 0x00000000
J-Link>SWDReadAP 2
Read AP register 2 = 0x00000000
J-Link>SWDReadAP 3
Read AP register 3 = 0x00000000
J-Link>SWDReadAP 4
Read AP register 4 = ERROR
J-Link>SWDReadDP 0
Read DP register 0 = 0x2BA01477
J-Link>SWDReadDP 1
Read DP register 1 = 0xD0000040
J-Link>SWDReadDP 2
Read DP register 2 = 0x00000000
J-Link>SWDReadDP 3
Read DP register 3 = 0x00000000
J-Link>SWDReadDP 4
Read DP register 4 = 0x00000000

Any ideas what happened and how to recover this board?

[Matt]

Can you probe the SWD and SWDCLK lines to see if there's any activities at all there? I'm no h/w dude so I cannot tell you what to expect when you probe those lines, but hopefully there's something there!

[Vincent Belaïche]

Hello @Nopik & @Matt. Have you found any solution ? We have a similar issue: in our case the SWD seems to be OK before the board goes to some « Could not power-up debug power domain » (hereinafter ERROR) state. The ERROR seems to be caused by having flashed some FW. After the ERROR state occurring, not only we cannot connect any longer to the NRF52840 by JLinkExe, but as for Nopik's case « nrfjprog --recover » does not help…

[Nopik]

Vincent, I don't think this is the same issue. It happened for me only on one board, months ago (and I'm working with it constantly since then), and most likely was a faulty hardware problem.

[Vincent Belaïche]

Nopik said:

and I'm working with it constantly since then)

Do you mean that you had N boards, N >1, only one is broken, but you are working constantly with the N-1 others since then?

Or do you mean that you could repair the board for which the faulty case happened ?

[Nopik]

The faulty board was repaired, and all N boards are OK for long time. I'm not sure what was fixed there, probably one element was replaced (I think it could be either CPU itself or some DC/DC converter, we had problems with those at the beginning, purely due to faults in our design). Our early boards had a bug of not having VDD/VDDH connected properly, this issue happened on one of those boards, we've corrected the bug later on.