One of the most frustrating part developing embedded applications is if the debug connection fails somehow: with all the different factors like operating system, virtual machines, USB ports and hubs, debug probe and firmware a ‘connection failed’ is my nightmare. And this is probably the most frustrating parts for my students (and myself!)
I do have a growing list of tips & tricks in “Debugging Failure: Check List and Hints“, so check this list. What I just have added is an entry for
java.net.SocketException: Connection reset
It occurred for a few students when they wanted to use the on-board CMSIS-DAP LinkServer debug connection on the NXP LPC845-BRK.
NXP LPC845-BRK Board
What I have added to that (growing) list is to check for any pending Windows updates, and do the updates. It is not 100% clear to me why a ‘pending’ update can have an impact on the debug probe. My thinking is that if Microsoft has found a vulnerability they disable right away some functions in the OS. As likely this is around networking (sockets, etc), this can affect debug probe connections because they use networking and socket functions.
In that case here, it throws the following exception:
java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:210) at java.net.SocketInputStream.read(SocketInputStream.java:141) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) at sun.nio.cs.StreamDecoder.read0(StreamDecoder.java:127) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:112) at java.io.InputStreamReader.read(InputStreamReader.java:168) at com.nxp.mcuxpresso.core.debug.support.linkserver.redlink.client.RedlinkServerClient.receive(RedlinkServerClient.java:928) at com.nxp.mcuxpresso.core.debug.support.linkserver.redlink.client.RedlinkServerClient.sendReceive(RedlinkServerClient.java:1031) at com.nxp.mcuxpresso.core.debug.support.linkserver.redlink.client.RedlinkServerClient.sendReceive(RedlinkServerClient.java:1016) at com.nxp.mcuxpresso.core.debug.support.linkserver.redlink.client.RedlinkServerClient.sendReceive(RedlinkServerClient.java:1003) at com.nxp.mcuxpresso.core.debug.support.linkserver.redlink.client.RedlinkServerClient.probeList(RedlinkServerClient.java:913) at com.nxp.mcuxpresso.core.debug.support.linkserver.emulators.common.RedlinkServerEmuHandler.discoverEmulators(RedlinkServerEmuHandler.java:196) at com.nxp.mcuxpresso.core.debug.support.linkserver.emulators.win.AbstractWinServerProbe.discoverEmulators(AbstractWinServerProbe.java:72) at com.nxp.mcuxpresso.core.debug.support.linkserver.emulators.EmulatorsDB.getEmus(EmulatorsDB.java:259) at com.nxp.mcuxpresso.core.debug.support.linkserver.emulators.EmulatorsDB.getEmulatorInfo(EmulatorsDB.java:199) at com.nxp.mcuxpresso.core.debug.support.linkserver.emulators.EmulatorsDB.getAvailableEmulators(EmulatorsDB.java:128) at com.nxp.mcuxpresso.core.debug.support.linkserver.emulators.TargetDiscovery.getAvailableEmulators(TargetDiscovery.java:498) at com.nxp.mcuxpresso.core.debug.support.linkserver.launch.LinkServerLaunchConfigHandler.probeDiscovery(LinkServerLaunchConfigHandler.java:612) at com.nxp.mcuxpresso.core.debug.launch.ProbeDiscoveryJob.run(ProbeDiscoveryJob.java:60) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Bottom line is: check your updates and perform the update, and the hope is that the problem goes away. As for the trigger point(s) for this article: this indeed solved the problem and the LinkServer debug connection was working again :-).
On a side note: my experience is that some debug probe connections do better, some worse, but not always in the same order. What I really (really!) highly recommend is to have another (external!) debug probe at hand, best from more than one vendor as a backup solution: that saved my day many times.
Happy updating & connecting 🙂
MCU on Eclipse 
Tricky subject this.. On the one hand, “wasting” class time debugging what should be unrelated things is frustrating at best. I’m not sure that it’s a bad thing in the end.
One of the problems that I find in green people that we’re attempting to hire is debugging. No one teaches classes in debugging and yet that is one of the most important aspects of engineering. Not only do you need to figure out why things aren’t working but you often find hidden problems (and solutions!) while in the act of debugging.
So I view this sort of thing with mixed feelings. Maybe there should be formal education in debugging where a person can banish this sort of problem to. No idea how you’d run such a thing, but it would help students considerably.
In a related note: back in the days of sliderules, there used to be a class at the big university here in Wisconsin that taught estimation. The problem with sliderules is that they don’t give scaled answers so you have to know what neck of the woods you’re in: are we talking femto, nano or kilo here? With a calculator you don’t have to do that and I have found people who don’t sanity check the answers because of it.
LikeLike
Hi Randy,
yes, such things are frustrating and can cost a lot of time running the labs and classes. The challenge is that each semester software and tools environment gradually changes, and even labs working in the previous semester might not work because of some issues or regressions in the tools.
As for debugging: good point, and I teach this more ‘on the fly’ and have not prepared something specific about ‘how to debug’. On one hand it is about experience and training, on the other hand it can be very specific to the problem too. I have to keep this in mind, at least https://mcuoneclipse.com/2014/11/03/debugging-failure-check-list-and-hints/ gives some ideas where to start.
Good thought about the topic ‘estimation’: I believe a good engineer always should have a sense of the time/dimension domain, just for a sanity check too.
LikeLike
Very wise advice. A couple of years ago, I had an issue with a customer where they rented 30 Windows 10 PCs to teach kids programming only to find that none of them worked until they were all updated. Very frustrating experience for them as updating each laptop took between two and three hours. The first day was a disaster, that evening & night was sleepless and the second day went perfectly.
I’ve had issues not only with debug but other interfaces not working while the OS is waiting for an update. I’m saying “OS” because as well as on Windows, I’ve also seen the same problems on on Mac OSX and ChromeOS – not on Linux, however.
The simple answer is to keep your systems updated. When a customer calls to report problems with our Jade Robot programming, the first thing we do is tell them update their system.
LikeLike
Yes, very frustrating. I occasionally get reports from students that debug somehow is not working. Usually it is related to some sort of virtual machines running which are not updated or very old. The other common issue is Avast: this is usually the first thing I ask about. The University IT recommends an installation of Avast, but in most cases it only creates issues with engineering tools: such firewalls are built for an office environment but not for a developer machine which does lots of networking, calls lots of executables (compiler, linker, gdb) in a fast pace: for Avast it looks like something unusual is going on an blocks things which results in strange error messages. I’m banning Avast for this.
LikeLiked by 1 person
This is why I now program in MicroPython. Just need a terminal program and and editor. Even Microsoft can’t screw that one up (or can they?)
LikeLike
You stated “Even Microsoft can’t screw that one up” in regards to uPython.
The short answer is “yes” but it’s more complex than that. As Erich notes, when the system is ready for update installation, Windows and other OS’s end up having issues that affect the operation of different drivers. I’ve seen USB CDC and Bluetooth SPP (both running with Putty or Tera Term) as well as PE Micro and Segger Debuggers and other devices (typically connected through USB) refuse to work properly until the system was updated.
it’s a frustrating error because it seems like the *last* thing you should do is to check for any pending updates but in actuality it’s the first thing that you should do.
LikeLike
Hi Brad,
MicroPython or anything else won’t protect you from things like this, as Myke states: they all go through the OS (Windows, Linux, …) layer to get for example networking working. This is intentionally otherwise they would need to access the hardware directly and the OS for good reasons won’t allow this. The only chance is that they use a different function or functionality which might not be affected by that pending update, so chances are that indeed it won’t be affected by that specific pending update, but might be by the next one.
And this is not only related to sockets, but as well to other low level drivers like USB. For example I had a similar issue in the past where OpenOCD did not work any more, but of P&E and SEGGER still did work. A reboot with updates did fix that one too.
LikeLiked by 1 person