ST-Link disconnects frequently

[John Griswold]

Posted on November 04, 2017 at 15:33

I am debugging on a couple of Nucleo boards, one a F767ZI, the other a L433RC. Both have had the ST-Link boards removed, with a wiring harness to connect the ST-Link board to the boards under test.

Very frequently the debugger link will drop unexpectedly, and I am unable to continue with my session. I need to stop the debug session, restart the debug session, and then try to get back to where I was debugging, always with completely different data (live samples are coming in). I doubt I can have a debug session last for more than ten minutes.

Is this an artifact of separating the ST-Link board from the main board? Is there something else I'm doing wrong? Or is my currently-low opinion of the STM boards warranted? I'd like to think I was doing something that can be remedied by a bit of behavior modification.

Any words of wisdom? I know there's wisdom out there.

Best regards,

John

#st-link-disconnect #st-link-error

[S.Ma]

Posted on November 04, 2017 at 16:04

Signal integrity and USB power budget to check out.

Signal integrity: Ground reference through an inductive wire is degrading performance, so group your wires with cable tie to keep the ground wire close to signal, reduce wire length if you can. Then you may be able to reduce the SWD signal frequency in your IDE debugger ST Link settings to compensate for degraded signal integrity.

Otherwise, if your board is powered by ST Link USB connection, remember the USB has a current limiting HW on the PC side. A workaround is to add juice to USB through a Y cable (like old hard disk drives) to try to improve things.

[John Griswold]

Posted on November 04, 2017 at 16:40

Power is supplied elsewhere, and the cable is about 6' (15cm) long, and made of ribbon cable segment, so there probably isn't a lot of inductance. 

Thanks

[Tesla DeLorean]

Posted on November 04, 2017 at 17:02

I've found them very solid under Keil. Sort of thing that will run for days on end. That said I don't break them off and hack together again. Have solid ground connectivity.

Not sure if you are using low power modes, or have WFI loops, these are classic disconnection reasons. Look for patterns to the failures.

DELL machines? Do you have random filter drivers probing USB MSC devices periodically?

Knocked/loose cables? Tape stuff down, don't lean across or move devices under test. I have a bad habit of cluttering boards around my keyboard/mouse, often disturbing things.

[John Griswold]

Posted on November 04, 2017 at 19:38

Glad to hear you find them solid. Next time I won't let them design a box too small to fit the debugger board! It is a Dell machine, though. Random filter drivers? New term to me. Can you define and/or advise on how to check and/or disable? 

Certainly there isn't enough tape holding things down. No lab. I'm doing this in my office, which is kind of lame.

[Tesla DeLorean]

Posted on November 04, 2017 at 21:07

You can add filter drivers into the USB or Mass Storage stack (function of Windows Async Driver Stack), if you use REGEDIT you can search on 'UpperFilters' and 'LowerFilters'.

DELL was giving me headaches decades ago breaking my Kernel and Port Drivers, basically the filters can fiddle with commands and data as it traverse up and down the driver chain. Basically meddling with things they had no place to be doing, and violating Microsoft's rules. Peoples CD drives would stop accessing data, you'd get 'IRQL NOT LESS THAN OR EQUAL' type Blue Screens of Death.

Most recently Support tools that cause support issues, you can't make this stuff up...

https://community.st.com/0D50X00009XkYEoSAN

They have also been known to add Intel Storage related filters. As I recall the ST-LINK uses USBSTOR, the filters are too stupid to leave things alone they don't understand.