Nachdem es mit der STM32CubeIDE kein Problem mehr ist, die USB Schnittstelle in Betrieb zu nehmen, ziehe ich das mittlerweile den lange Zeit üblichen FTDI Chips mit serieller Verbindung vor.Läuft ja auch so ganz gut... bis man seine Neonröhren-Leuchtlupe am Schreibtisch in Betrieb nimmt,dann steht die Kommunikation. Offenbar EM Störung. Was ich bisher herausgefunden habe: Steckt man USB aus und wieder an(ohne Controller Reset),ist alles wieder gut, d.h. der Controller läuft wohl "normal" weiter und die USB Schnittstelle verbindet wieder. Mit Debugger ist's auch schwierig was herauszufinden, weil meist ebenfalls gestört. Die Leitungslängen der USB Leitungen zum Controller sind gleich lang und relativ kurz (ca. 15mm) und verlaufen auf geschirmter Innenlage. Der Versuch die 47pF Kondensatoren auf die Controllerseite zu legen schlug fehl,das Gerät wurde dann nicht erkannt. Was ich im Netz gesehen habe, ist, dass oft auch noch Gleichtaktdrosseln im Signalweg verbaut werden. Hat das schon wer gemacht, bzw. Erfahrungen damit? Oder ist das womöglich ein Softwareproblem? Hmmm... Fragen über Fragen, vielleich weiss ja wer was... Grüsse
Ich dachte, die USB Schnittstelle ist störungsfest weil sie ggf. fehlerhafte Übertragungen wiederholt. Kann es sein, dass dein Mikrocontroller abstürzt? Lasse mal LED in der Hauptschleife blinken und beobachte, ob sie im Störfall zum Stillstand kommt. Wenn das der Fall ist, hast du vermutlich ein Problem mit der Stromversorgung oder du fängst dir starke Radiowellen über die Leitungen ein. Dagegen gibt es Spezielle Chips mit einer Hand voll Schutzdioden. https://www.electroschematics.com/esd-protection-for-usb/ Möglicherweise hast du das Problem gar nicht auf der USB Leitung sondern auf einer anderen.
Markus M. schrieb: > 47pF sind zu viel. > PESD5V0U2BT ist dein Freund. Das sind ESD Dioden, ESD ist, denke ich, nicht das Problem.
Stefan ⛄ F. schrieb: > Kann es sein, dass dein Mikrocontroller abstürzt? Nein, Stefan wie oben erwähnt, scheint das Ding weiterzulaufen und verbindet dann auch wieder.
Stefan ⛄ F. schrieb: > Ich dachte, die USB Schnittstelle ist störungsfest weil sie ggf. > fehlerhafte Übertragungen wiederholt. Ja, so würde ich auch denken, aber ob der Programmierer des CubeIDE Treibers auch so gedacht hat...
Gebhard R. schrieb: > wie oben erwähnt, scheint das Ding weiterzulaufen Ach so, ich hatte angenommen, dass die Stromversorgung womöglich vom USB Kabel kommt. >> Ich dachte, die USB Schnittstelle ist störungsfest weil sie ggf. >> fehlerhafte Übertragungen wiederholt. > Ja, so würde ich auch denken, aber ob der Programmierer des CubeIDE > Treibers auch so gedacht hat... kann man nicht so leicht erkennen. Klar, Softwarefehler muss man auch erwägen. Ich vermute allerdings, dass es der einfachere Weg ist, erstmal die Hardware durch zu checken.
Gebhard R. schrieb: > bis man seine Neonröhren-Leuchtlupe am Schreibtisch in > Betrieb nimmt,dann steht die Kommunikation. Offenbar EM Störung. Dann bräuchten wir aber auch das Layout und nicht nur den Schaltplan. Gebhard R. schrieb: > Mit Debugger ist's auch schwierig was herauszufinden, weil meist > ebenfalls gestört. Dann ist die Störung eventuell auf der Masse- oder Betriebspannungsschiene. Das mögen µCs auch eher nicht.
Update: Das USB Kabel war wohl nicht so toll. Mit einem neuen Kabel ging's bedeutend besser, noch besser mit Ferritring und Kabel 3x durchgezogen. Fast schon gut,aber EMV Prüfung wird man damit wohl nicht bestehen.
Update: Hab jetzt noch 22pF Controllerseitig auf die USB Leitungen gelötet. Das scheint nicht zu stören, bringt aber auch nix wie es scheint. Die Störung ist ziemlich sicher eine Gleichtaktstörung auf dem USB Kabel =>Ferritring hat sehr deutlich geholfen. Vlt. sollte ich doch noch so eine USB Gleichtaktdrossel auf der Platine routen.
Hast du eventuell ein Linux zur Hand und kannst mal schauen, was dmesg sagt, wenn der Fehler eintritt. Linux loggt da in der Regel schon einiges mehr. Da würde man dann sehen, wenn da irgendwas schiefgeht. Zumindest auf dem Niveau, dass der Host das mitbekommt. Im Zweifel verspult es aber nur das Gerät und der Host bekommt es nicht mit und enumeriert deswegen nur nach einem Ab- und Anstecken neu. Soweit ich es im Kopf habe, erkennt der Rechner nur am USB Pullup/Pulldown, dass das Gerät angeschlossen / abgesteckt ist. Während der Bus Idle Phasen, sendet der Host zwar die Keep alive messages, prüft aber nicht, ob die auch von was empfangen werden. Es kann laso gut sein, dass dein STM von der Firmware her Hopps geht und eine disconnect o.ä. erkennt und neu enumeriert werden will, aber der Host denkt, das Gerät ist noch da und ist enumeriert.
Stefan ⛄ F. schrieb: > Ich dachte, die USB Schnittstelle ist störungsfest weil sie ggf. > fehlerhafte Übertragungen wiederholt. Der war gut! :) Das ist garantiert ein Layout Problem. Die Kabel spielen natürlich auch wesentlich mit. Wenn ich mit meiner Automotive-ESD-Gun direkt neben dem PC bei 20kV Funken ziehe, dann dauert es nicht all zulange, bis sich nach und nach die USB-Geräte verziehen. Das ist völlig normal. (und auch gewaltiges overtesting!) Wenn die Masse vernünftig am Schirm anliegt, ist aber EMV nach den gängigen Normen für den Haushaltsbereich kein Problem. Würth hat für USB ganz gute Whitepaper was man tun kann. Nur soviel: CM-Drosseln können problematisch sein, da du im Signalling CM-Impulse hast. Cs verschleifen dir dein Signal.. Wenn du da was brauchst, bitte schau dir das Augendiagramm an. Wenn das nicht passt, wirst du sogar noch störanfälliger! Aber wie gesagt, wenn du ein sauberes Layout hast, sollte das keine große Hürde sein! 73
Ja, vermutlich ein gemischtes Problem. Bei den FTDI Chips waren Störungen eigentlich nie Thema, die liefen stabil auch ohne irgendwelche Beschaltungen im Signalzweig. Da muss wohl auch der virtuelle Comport Treiber von STM bzw. der Controller Treiber eher suboptimal programmiert sein. Fakt ist, der PC erkennt nicht, dass die Verbindung gestört ist. Hab jetz mal einige Gleichtaktdrosseln geordert, die dann statt der 33Ohm Serienwiderstände Platz haben.
Gebhard R. schrieb: > Fakt ist, der PC erkennt nicht, dass die Verbindung gestört ist. > Hab jetz mal einige Gleichtaktdrosseln geordert, die dann statt der > 33Ohm Serienwiderstände Platz haben. Hast du Ferrite (Klappferrit o.ä.) da? da könntest du das Kabel nahe am Gerät auch mal durchwickeln, um zu schauen, ob das was bringt. Edit: Gerade gesehen, dass du das schon mit Teilerfolg versucht hast. Blöd dran ist meist nur, dass man durch den Ferrit auch den Schirm mit durchwickelt, was eigentlich nicht unbedingt gewollt ist. Eine Gleichtaktdrossel im Signalzweig wird denke ich nochmal mehr bringen. Hans W. schrieb: > Wenn die Masse vernünftig am Schirm anliegt, ist aber EMV nach den > gängigen Normen für den Haushaltsbereich kein Problem. > > Würth hat für USB ganz gute Whitepaper was man tun kann. > Nur soviel: CM-Drosseln können problematisch sein, da du im Signalling > CM-Impulse hast. > Cs verschleifen dir dein Signal.. Wenn du da was brauchst, bitte schau > dir das Augendiagramm an. Wenn das nicht passt, wirst du sogar noch > störanfälliger! Ja. USB ist sowieso der letzte Sch... Es ist ist inherent schwierig das richtig EMV stabil zu machen. Mal wir der Schirm am Gerät hart auf Masse verbunden, was dann dafür sorgt, dass die Hälfte der GND Ströme im Schirm fließen und alles noch viel anfälliger wird. Ein anderes mal ist der Schirm im Gerät kapazitiv angekoppelt und regt sich beim Kabel in einer Schleife legen selbst zum Schwingen an. Habe da schon die wildesten Effekte gesehen. Ganz schlimm wird es teils, wenn auch das Gerät Bezug zur Erde hat und kein floatendes etwas ist. Dann hat man da noch die wildesten Groundloops. Wie wird die Schaltung versorgt? Über USB oder eigenes Netzteil? Gebhard R. schrieb: > Mit Debugger ist's auch schwierig was herauszufinden, weil meist > ebenfalls gestört. Ich habe mir auch schon ne schöne Schleife gebaut durch die Debugger Verbindung. Ich habe tagelang nach dem Rauschen im Analogteil gesucht, bis ich gemerkt habe, dass ich ja über den Debugger (über den ich das rauschen mittels AD gemessen habe) wieder eine Masseschleife eingebaut hatte und das Rauschen eigentlich gar nicht da war.
M. H. schrieb: > USB ist sowieso der letzte Sch... Übersetzung: useless serial bus Der Schrott taugt eigentlich nur für Spielzeug,aber was soll man machen... M. H. schrieb: > Wie wird die Schaltung versorgt? Über USB oder eigenes Netzteil? Eigenes Steckernetzteil,sogar medizinisches mit geringsten Strömen gegen Erde. M. H. schrieb: > Ich habe mir auch schon ne schöne Schleife gebaut durch die Debugger > Verbindung Ja, das ist dann gleich das nächste Problem
Die Wirkung der Gleichtaktdrossel war jetzt auch nicht so toll. Aber es scheint das Problem möglicherweise ganz woanders zu sein. Ich hab für den Controller SW geschrieben, die alle 0,5s an das virtuelle Comport des PC Messwerte sendet. Im Falle der Störung bricht das ab. Ich stecke USB am Controller ab (Controller läuft weiter weil extern versorgt)und wieder an und starte das Terminalprogramm neu. Siehe da, ohne weiteres zutun werden am Terminal wieder Messwerte ausgegeben. Könnte es sein, dass das Problem am VCP Treiber von ST liegt?
Gebhard R. schrieb: > Könnte es sein, dass das Problem am VCP Treiber von ST liegt? Wäre denkbar. Kannst du die Chose mit einem L0, F1 oder F3 wiederholen? ich frage, weil ich dir dafür eine gründlich geprüfte alternative USB Library geben könnte mit der du dann vergleichen kannst.
Stefan ⛄ F. schrieb: > Kannst du die Chose mit einem L0, F1 oder F3 wiederholen? Eine Steuerung mit F373 hätte ich auch da. Kann ich morgen testen. Grüsse
Gebhard R. schrieb: > Eine Steuerung mit F373 hätte ich auch da. Kann ich morgen testen. ich habs mit diesem Modell nicht getestet, solle aber gehen. Du brauchst die beiden Dateien usb.h und usb.c. Schau erstmal ob du mit dem F373 +HAL das Problem reproduzieren kannst. Wenn ja, benutzt du anstelle der HAL die beiden Dateien usb.h und usb.c. Betrachte die main.c als minimales Anwednungsbeispiel.
Bitte 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.