Could not connect to target

[Helmut]

Hello,
I kindly ask for help regarding the repetedly upcoming "Could not connect to target" problem. This problem is not new - frustrating.
I am sure the problem is quite common and there should exist a more or less simple solution but I cannot find one, neither here in any NXP forum nor elswhere. I have seen [could-not-connect-to-target-Jlink-MCUXpresso/m-p/856208#M3486], but I could not see a solution for me in this post.

Software:
Windows 10 Pro, Version 2004, Build 19041.1052. But this doesn't seem to be relevant as the problem exists already several years on at least 2 different computers and several versions of Windows 8 and 10.
The problem came up with

• both, LPCXpresso and MCUXpresso, current version is "MCUXpresso IDE v11.3.0 [Build 5222] [2021-01-11]", all updates installed, 202106241228_SupportInfo.zip is available if necessary.
• LPC-Link (several samples, mostly working, sometimes not),
• a freshly acquired Link-2 (migration to MCUXpresso this year) never worked, but I was in a hurry and bought a...
• Segger J-Link EDU mini V1 which worked for some time. But now the problem seems to establish with this debugger and I'm getting tired of all this...

A part of the problem might be that I sometimes also use ST-Microsystem's CUBE IDE. But I'm 100% sure that I did NOT use CUBE for debugging before the problem occurred this time (I never debugged the my STM stuff on the new computer). But perhaps installing CUBE might contribute.

I use my own extremely simple LPC812-hardware, not much more than a controller breakout. As it mostly works I don't think that it contributes to the problem.

This is the log of the J-Link GDB Server:

-------BEGIN------------
[24-6-2021 10:59:26] Executing Server: "C:\Program Files (x86)\SEGGER\JLink\JLinkGDBServerCL.exe" -nosilent -swoport 2332 -select USB=801006574 -telnetport 2333 -singlerun -endian little -noir -speed auto -port 2331 -vd -device LPC812M101 -if SWD -halt -reportuseraction
SEGGER J-Link GDB Server V6.88c Command Line Version

JLinkARM.dll V6.88c (DLL compiled Dec 4 2020 18:05:56)

Command line: -nosilent -swoport 2332 -select USB=801006574 -telnetport 2333 -singlerun -endian little -noir -speed auto -port 2331 -vd -device LPC812M101 -if SWD -halt -reportuseraction
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: on
Init regs on start: off
Silent mode: off
Single run mode: on
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: LPC812M101
Target interface: SWD
Target interface speed: auto
Target endian: little

Connecting to J-Link...
$$UserActionStart$$: Terms of use
$$UserActionEnd$$: Terms of use
J-Link is connected.
Device "LPC812M101" selected.
Firmware: J-Link EDU Mini V1 compiled Feb 18 2021 11:25:23
Hardware: V1.00
S/N: 801006574
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 3.11 V
Listening on TCP/IP port 2331
Connecting to target...
ERROR: Could not connect to target.
Target connection failed. GDBServer will be closed...Restoring target state and closing J-Link connection...
Shutting down...
Could not connect to target.
Please check power, connection and settings.

Server has been shut down.
-------END-----------

There is another message from the IDE:

--BEGIN--
Failed to execute the MI command:
-target-select remote localhost:2331
Error message from debugger back end:
localhost:2331: Es konnte keine ... verweigerte.
--END--
repeated 3 times under "Details>>".

Note that the target voltage obviously was measured (3.11 V but sometimes 3.10 V - therefore this is not a setting but a measurement result) and there must have been some working connection.

Please:
- Is there an understandable explanation of what happens?
- Is there a way to solve this "FOREVER"? Or, at least,
- is there a simple way (checklist for connection and settings...) to quickly and reproducibly solve the problem when it comes up?

Kind regards,
Helmut

[phil_mexico]

I recommend checking if your USB cable also supports data transfer and is not only for charging.
If you connect to a Windows system and don't hear a sound, and don't see your device in the device manager, you are probably using a charger cable

[Helmut]

Hello,
thank you very much for your quick response and your help.

In short words: Today it works. Perhaps also tomorrow (:-)

I was surprised that most of your tips relate to hardware, not to installation or settings.

I went through the checklists and currently I think that a ground loop might be the cause of the problem.
I found this during studying point 4 of Prof. Styger's list.

What you could not know because I hadn't told: My target hardware is connected twice to the PC, via the Segger J-Link EDU mini debugger and via a serial-USB-converter (FTDI-232R-3V3) which also delivers power. Serial communication is not for "arduino-like debugging" but an integral part of the software functionality.

This did never affect the performance of the target hardware when it was not in debugging, regardless if the debugger was connected or (not connected and (powerd or not powered))      (precedence braces for clarity:-).
This explanation also fits to the observation: "3 weeks ago everything was ok and I did nothing but today it does not work at all" - some changes in the USB usage could have unpredictable influence.

I tried to disconnect the GND wire from the FTDI device, hoping that "the other" GND wire via the debugger would suffice, but of course nothing at all worked. I do not think that any of the 2 devices is "isolated" somehow (perhaps a more expensive debugger is), but there really are enough reasons that it doesn't work.

What helped was:

• to plug the 2 USB plugs into adhacent connectors of an USB-2.0-hub and having nothing else connected to this hub,
• using short USB cables <20cm (means: shorten the FTDI cable), and even
• holding the 2 USB cables in parallel by using a cable tie.

I am, of course, not sure, that this will be enough for all times. Perhaps the "coupling" of the two devices must be done even closer. I will see...

I was surprised that the list of available debuggers was not shown. Earlier it was shown even when only one debugger was available.

Again let me say "Thank You", I wouldn't have found all this without your effort!
Kind regards,
Helmut

[ErichStyger · Accepted solution]

Hi @Helmut ,

I was surprised that most of your tips relate to hardware, not to installation or settings.

Well, in my experience: if it is a software or installation thing, then it is mostly binary: either it works or it does not.

While if things are sometimes working, sometimes not it is mostly because of hardware problems. What I have not added to the list are things like ESD damage: I have lost weeks with devices somehow partially damaged by ESD. Compared to the 'old' days, these new micro-controllers are much more sensitive to ESD in my experience. And if ESD is involved, all kind of weird things will show up. The second big thing is around power, according to the first golden rule for every engineer: "check the power!"

Glad to hear you are making some progress, keeping fingers crossed.

Erich

[converse]

As this is your own board, it sounds to me as if there is a (possibly subtle) hardware issue in your debug circuit. Make sure you read this

https://community.nxp.com/t5/LPCXpresso-IDE-FAQs/Design-Considerations-for-Debug/m-p/469565

I can say that in all the time I have used NXP tools (over 10 years), that they are reliable, with reliable hardware...

[myke_predko]

@Helmut 

I think @ErichStyger did a good job of listing potential issues.  

If I can make a couple of suggestions as I've had similar problems with the J-Link EDU Mini - which, honestly is not a great tool.  I use the J-Link Plus which is a lot more reliable.  

In order of what I would recommend you check:

1. Make sure your PC doesn't have any updates pending.  Different Windows versions will shut off different services if it is ready to install something.  Very frustrating and hard to recognize and debug.  
2. If you're concerned about other devices/software in the PC that could be causing problems, then find a PC (and is up to date per the previous point) that doesn't have any other programming software on it and try that.  
3. Try a different, shorter USB cable.  I know this is weird, but I found with my J-Link EDU, it wouldn't work reliably with USB cables longer than six feet - I had to use cables shorter than 5 feet (150cm).  
4. Try programming with the J-Link EDU in a different position to see if there is an internal break in one of the leads or some other intermittant connection.  I've had that a number of times over the years with programming cables and it can be very frustrating - changing the position will probably reveal a hard fault that shows up earlier in the process rather than a position where the programmer works reliably/always.  
5. Check your reset.  Do you have an RC circuit on it that could be causing problems with the low-power open drain driver on the J-Link EDU?  
6. Check your power supply as Erich suggested.  

If these don't work, then maybe your can share your circuit and programming connections (in a graphic) with a photograph of how you are wiring it.  

Good luck!

myke

[ErichStyger]

Hi @Helmut ,

yes, this kind of stuff can be very, very frustrating. I keep a list of things to check on https://mcuoneclipse.com/2014/11/03/debugging-failure-check-list-and-hints/, just in case you have not seen that one: from basic things to the more complex check and test points.

There can be multiple things for what you see. Apart of the obvious ones (which prevent debugging permanently, like not powered target or wrong pins), there could be subtle things related to your setup. I have found broken wires in (USB/SWD/JTAG) cables several times, so swap out cables to be sure. The other thing is noise or not clean signals: I had cases with badly routed debug signals injecting so much noise that debugging was not reliable.

Stable/good power supply on all sides is critical too: seen bad board power supplies dropping the voltage too much as soon as debugger is engaged, up to bad ground loops causing issues.

You might hook up a scope to the SWD/JTAG signals to see if they are looking good or if there is lots of noise.

The other thing is as the communication between gdb server and client is a TCP connection: I have seen firewalls/virus scanners causing strange effects too, so try to disable them to see if there is an effect.

I know these are just throwing in ideas, but hopefully this gets you somewhere.

I hope this helps,

Erich