Why does USB/Debugger Time out when running Overnight?

[paulrbryson]

I am running code overnight using the STVD debugger and an STM8S discovery board as the interface. After many hours the debugger loses connection to the target. "Stop Program" is grayed out under the "Debug" menu. The "watch" variables are not being updated. The first time I click on one of the "watch" variables it says something about a "USB timeout". But subsequent tries show me the variable contents. However; I still cannot "Stop Program" and the debugger seams to be in some indeterminate state.

I need to be able to run long term tests and use the debugger to find errors. What is going on?

[Tesla DeLorean]

Perhaps try a different approach?

Use a serial port to output diagnostic, debug, or telemetry data. If need be provide a monitor, or method, to allow user interaction and inspection of variables/memory.

Understand the flow of your code, paths to failure, and things like heap and stack integrity, which you can check programmatically.

For critical failure dump out execution context information so you can root-cause failures.

[Uwe Bonnes]

Could it be that your PC goes to sleep or puts USB to sleep?

[paulrbryson]

It could be something like that... I disabled the computer sleep before the first overnight test. And before last night's test I disabled power down for the "USB Root Hub" - that did not work either. It is so inconvenient that it takes a whole day for each experiment. I was hoping this was a known problem with a known solution. I simply will have to work around this.

Btw.. the actual message from STVD when I refreshed the watched variable was something like:

"SWIM Error .... comms timeout". I know... I should have captured it; but, I was too eager to see the data.

[paulrbryson]

Problem Resolved:

It turns out that the problem was a cold solder joint on the SWIM header. I am guessing that at night when the temperature in the office dropped, the connection opened up; but, then reconnected before I came in.