Hi, ich habe seit Wochen ein Problem das mich in den Wahnsinn treibt. Ich habe verschiedene STM32 Nucleo Boards an meinem DELL Windows 10 Notebook angeschlossen und nutze die USB Virtual COM Port Funktion, die der ST Link anbietet, um Daten vom Nucleo an den PC zu übertragen. Problem: Ca. alle 10-14 Minuten bricht die Verbindung ab. Die serielle Console hängt und muss neu gestartet werden, der Mikrocontroller wird vom ST Link neu gestartet (Reset). Ich habe so ziemlich alles probiert und kann das Nucleo Board inkl. Software darauf ausschließen, da es an einem anderen Windows 10 Notebook einwandfrei Stunden lang durchläuft. Auch der Debugger schmiert ab. Bei Energieeinstellung für Windows 10 USB Gerät hab ich das abschalten deaktiviert. Verschiedenste ST Treiber probiert, Windows 10 ist auf neusten Stand, keine Fehler im Geräte Manager. Man findet hier und da etwas im Internet aber ich hab alles pprobiert. Kennt jemand das Problem?
Bietet das Nucleo Board ein USB mass storage device? Vielleicht versucht Win ein reparieren des Laufwerks, oder einen Index zu erstellen?
Das Verhalten kann ich bestätigen, habe da aber noch nicht weiter nach gesucht. Ein Disco F469NI hat bei mir auch ständig neu gestartet. Um auszuschließen das es ein Programmierfehler ist habe ich das Board mit einer Powerbank versorgt- lieg mehrere Stunden durch. Aktuell habe ich mir eine LED Matrix mit ESP8266 gebaut und nutze einen FTDI232 als Prog Adapter, der ist mit DTR an Reset verbunden. Und rate mal was passiert... Win10 fummelt also offensichtlich am DTR rum und löst auch da regelmäßig Reset aus. Wenn es also daran liegt hilft eventuell dieser Tip: https://www.uhlenbrock.de/de_DE/service/faq/software/I23A3243-001.htm!ArcEntryInfo=0004.18.I23A3243&NewServerName=zeta kleine Korrektur: Reset liegt beim ESP Progadapter an RTS.
pegel schrieb: > Bietet das Nucleo Board ein USB mass storage device? > Vielleicht versucht Win ein reparieren des Laufwerks, oder einen Index > zu erstellen? USB Mass storage kann sich auch Geräte-seitig aufhängen. Hatte ich mal hier, Windows resetet dann das komplette USB Device inklusive aller sonstigen Interfaces. Abhilfe: ST-Link Firmware aktualisieren oder auf J-Link umstellen. Diagnose ist mit wachem Auge und USB Packet Capture Tool möglich. Man sieht dass die regelmäßigen Abfragen des USB Mass storage nicht mehr beantwortet werden, und dann nach einigen Sekunden der Reset erfolgt. Je nach Tool sieht man den Reset eventuell nicht direkt, sondern nur der nachfolgende Traffic auf EP0.
Johannes S. schrieb: > Win10 fummelt also offensichtlich am DTR rum und > löst auch da regelmäßig Reset aus. Checke alle laufenden Programme. Bei mir war mal ein Mobilfon Tool, das wahllos alle Com Ports regelmäßig geöffnet hat. ->Uninstall
Ich hatte da etwas weiter gesucht, es scheint die Enumeration der Schnittstellen zu sein wenn sich irgendwas tut. Schon das starten des Br@y Terminalprogramms löst das aus. Der Ftdi Treiber hat eine Option das abzuschalten aber ob es hilft ist fraglich, probiere ich später aus. Das ist aber wohl ein anderes Problem als beim Nucleo bzw. STLink. Bei Windows 7 hatte ich das bisher nicht beobachtet, kann ich mit dem Discoboard aber auch nochmal testen.
Jim M. schrieb: > USB Mass storage kann sich auch Geräte-seitig aufhängen. Hatte ich mal > hier, ich habe gestern abend das USB MSD vom STLink auf dem Disco deaktiviert, über Nacht hat es keinen Reset gegeben. Mit USB MSD nach spätestens 1h, auch wenn ich nix am Rechner gemacht habe. Die Theorie von Jim kann stimmen, das Problem ist aber wie ich vermute erst mit Windows 10 gekommen. Wenn der Windows Rechner neu gestartet wird dann wird das Disco auch neu gestartet, das lässt sich wohl nicht verhindern. Wobei das MSD deaktivieren ein blöder Workaround ist weil ich das gerne nutze, ein richtiger Fix wäre mir auch lieber. In dem anderen Fall mit dem virtuellen COM Port hilt es in den erweiterten Einstellungen das 'Plug & Play' abzuschalten und keine Modemsteuerung einzuschalten. Dann wird das Target auch beim Windows Rechner starten in Ruhe gelassen. Nur Br@y Terminal starten löst noch einen Reset aus, das macht wohl ein open/close oder irgendwelche Tests beim Scan der verfügbaren Schnittstellen.
Vorab vielen Dank für den Input. Johannes S. schrieb: > Wenn es also daran liegt hilft eventuell dieser Tip: > https://www.uhlenbrock.de/de_DE/service/faq/software/I23A3243-001.htm!ArcEntryInfo=0004.18.I23A3243&NewServerName=zeta Kannte ich schon, hat keine Verbesserung gebracht... pegel schrieb: > Bietet das Nucleo Board ein USB mass storage device? > Vielleicht versucht Win ein reparieren des Laufwerks, oder einen Index > zu erstellen? Habe keine Möglichkeit gefunden die Index Erstellung zu verhindern ... wo kann man das deaktivieren? Jim M. schrieb: > bhilfe: ST-Link Firmware aktualisieren War das erste was ich gemacht hatte, ist mit der neusten Version eher schlimmer als besser im Vergleich mit den alten Versionen... Jim M. schrieb: > Checke alle laufenden Programme. Bei mir war mal ein Mobilfon Tool, das > wahllos alle Com Ports regelmäßig geöffnet hat. ->Uninstall Halte ich auch für möglich, hab schon ähnliche Anwendungen deinstalliert und / oder im Task Manager beendet. Johannes S. schrieb: > Ich hatte da etwas weiter gesucht, es scheint die Enumeration der > Schnittstellen zu sein wenn sich irgendwas tut. FTDIs laufen ohne Probleme bei mir. Johannes S. schrieb: > ich habe gestern abend das USB MSD vom STLink auf dem Disco deaktiviert Wie genau hast du das gemacht? Rechtsklick auf MSD und auswerfen drücken? Ach ich glaube ich hab das deaktivieren gefunden, werds gleich mal testen. Johannes S. schrieb: > n dem anderen Fall mit dem virtuellen COM Port hilt es in den > erweiterten Einstellungen das 'Plug & Play' abzuschalten und keine > Modemsteuerung einzuschalten Wie genau geht das? Problem besteht weiterhin, wenn noch jemand Lösungsvorschläge hat, immer her damit. Beruhigt mich aber das ich nicht der einzige mit dem Problem bin.
:
Bearbeitet durch User
Max P. schrieb: > Wie genau geht das? Systemsteuerung (die alte) aufrufen, 'Geräte und Drucker anzeigen' von 'STM32 STLink' die Eigenschaften aufrufen, Tab Hardware und das 'USB Massenspeichergerät' auswählen. Eigenschaften, Button 'Einstellungen ändern', Tab Treiber, 'Gerät deaktivieren' auswählen. Dann möchte Windows neu gestartet werden. Alternativ über den Gerätemanager, in USB Controller das USB Massenspeichergerät finden und genauso in Eigenschaften deaktivieren. Wenn das MSD deaktiviert ist wird es hier auch mit gelbem Warndreieck dargestellt, da kann man es leicht wieder aktivieren. Der FTDI oder virtuelle COM Port war nicht das Problem beim STLink, das hatte ich erst vermutet. Der Fix hilft wenn Reset vom Target mit RTS verbunden ist.
Tausend Dank Johannes S.!!! Das Deaktivieren des Massenspeichergerätes, gemäß deiner Anleitung, hat bei mir das Problem mit den ständigen Resets scheinbar gelöst. Läuft jetzt schon 40 Minuten ohne Probleme (sonst war nach spätestens 14 min ein Neustart). Ich werde das mal weiter laufen lassen. VCP und Debug Session funktionieren jetzt ebenfalls stabil. Ich hab die ganze Zeit den Fehler beim VCP Treiber gesucht und dort alles probiert (Windows 10 scheint ja bei Serial Treibern in der Vergangenheit etwas Probleme gehabt zu haben). Bei dem MST gab es ja nicht viel einzustellen wie z.B. Energiesparen etc., deshalb hatte ich das nicht weiter beachtet. Für mich ist das schon eine vertretbare Lösung des Problems. Natürlich würde mich trotzdem interessieren warum bei einem meiner Notebooks das von Haus aus keine Probleme hervor ruft und bei dem anderen schon. (beide Windows 10 x64, gleiches Nucleo Board, gleiche MSC Treiber Version 10.0.17134.1 Datum 21.06.2006 von Microsoft) Bei dem Windows wo es nicht ohne den Fix ging, ist Windows Home installiert, bei dem anderen Prof. ...
Max P. schrieb: > Natürlich > würde mich trotzdem interessieren warum bei einem meiner Notebooks das > von Haus aus keine Probleme hervor ruft und bei dem anderen schon. Weil das USB Timng subtil anders ist. Der Aufhänger entsteht wenn der PC eine Anfrage beantwortet und der µC im ST-Link noch nicht mitbekomment hat das die Anfrage überhaupt (fertig) gesendet wurde. Hat mitunter auch was mit der Reihenfolge anstehender (USB-) Interrupts zu tun, und trat (zumindest hier) nur bei realtiv hoher Interrupt Last auf. Ein paar µs(!) eines PC machen da eine Menge aus...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.