2019-11-25 08:16 AM
I'm using STM32CubeIDE 1.1.0 with a STEVAL-SPIN3204 board connected via the USB port and onboard ST-Link. About 2-5 minutes after I start a debug session The Console prints "Target is not responding, retrying..." 10 times and then prints "Debugger connection lost.
Shutting down...". At that point I can restart the debugger again sucessfully. Until the debugger starts printing Target is not responding, the debugger works normally. I can single step, run, stop on breakpoints, view and modify variables etc.
This problem occurs even if I merely initiate a debug session and never touch the keyboard so it seems rather unlikely it has anything to do with the program being debugged. And FWIW I did confirm that the watchdog is disabled by the fuse settings.
2019-11-25 08:54 AM
Using a DELL ?
2019-11-25 08:57 AM
Affirmative. Dell Precision 3430 with Intel i7-8700 3.2GHz running Windows 10 64 bit.
2019-11-25 09:06 AM
Does any energy saving daemon put the USB connections to sleep? Look at you energy saving options.
2019-11-25 09:06 AM
Remove the Remote Diagnostic tools, or any Intel tools probing the Mass Storage Controller stack.
There is something in the UpperFilter or LowerFilter causing issues.
2019-11-25 09:09 AM
Support Assistant
https://community.st.com/s/question/0D50X00009XkYEoSAN/stm32f4-resetting-itself-nucleo-64
2019-11-25 09:16 AM
@Imen DAHMEN @Amel NASRI @Nawres GHARBI
Your Installation tools should check for conflicting drivers in the stack.
When I was doing mass storage peripherals, we checked for Upper/Lower Filters, both ones known to conflict, those we needed, and situations where a prior install broke the registry MULTISZ records that prevented any of the drivers instantiating properly.
Given the proliferation of DELL systems this is a recurrent problem, and easy enough to identify.
#CliveFromTheYear2000
2019-11-25 09:21 AM
Yes, typically screen savers, HD power down and the like. With DELL's it's predominantly all the crapware they install, especially the remote diagnostic assistant thing. Some reports of Intel storage/speed test, and perhaps Daemon Tools.
TOSHIBA machines, especially laptop, were problematic with custom ASICs, but they failed/exited that business as I recall.
2019-11-25 09:32 AM
"USB selective suspend setting was enabled. I set that to disabled but the problem persisted. I then disabled every "sleep" related function and that had no effect. IICR selective suspend only applies to an idle port, I've used several other USB connected debuggers without any timeout or sleep issues on the same computer.
2019-11-25 10:02 AM
I'm not following this and don't know what installation tools you're talking about nor do I know what you mean by "Upper/Lower Filters" or how to check for conflicting drivers in the stack. I did open Device Manager and found two drivers that were flagged: "Jungo Connectivity->WinDriver" and "Sensors->Microsoft Visual Studio Location Simulator Sensor" which I then disabled. That didn't help either. What other steps should I take?