Hallo Forum, ich habe Fragen zu denen ich im Internet und im STM Forum leider nicht fündig geworden bin. Ich habe in der Vergangenheit mit Beispielen und viel Rat aus dem Web erfolgreich einen eigenen virtuellen Com Port für STM32LXX MD und HD Geräte erstellt. Dieser funktionierte in eigenen Applikationen unter XP, Win7, Win 8, Win 8.1 x32 und x86 ohne Probleme. Senden und empfangen, HotPlug, ordentliche Datenraten, es gab praktisch keine Probleme. Windowsseitig konnte ich bislang die STM Treiber 1.3.1 bzw. 1.4.0 ebenso problemfrei verwenden. Nun erfolgte kürzlich das Upgrade auf Windows 10... Das resultierende Problem: Unter Windows 10 funktioniert mein VCP für die STM32LXX-Geräte nicht mehr korrekt. Etwas verwirrend ist, dass ich andere virtuelle Com Ports (z.B. aus der Basis von CP210 Geräten und AVR Controllern) auch weiterhin unter Windows 10 mit meiner Software problemfrei ansprechen kann.(Meine Windows Programme verwenden intern GetDefaultCommConfig, CreateFile, SetCommState, GetCommState, WaitForSingleObject... zur Verwaltung von COMs.) Die STM Treiber lassen sich auch unter Windows 10 gut und fehlerfrei installieren, der Status-Kode lautet OK = 0x0. Angeschlossene Geräte werden sofort erkannt und ordnungsgemäß als COM-Gerät COMXX eingebunden. Alles sieht normal und gut aus. Das resultierende Problem nun etwas genauer: Ich kann vom PC auch unter Windows 10 Zeichen senden und empfange diese auf dem STM-Mikrokontroller. A B E R, zurück gesendete Zeichen kommen aber nicht mehr am PC an. Kein Zeichen kommt zurück. Nur unter Windows 10 (x86). Hat jemand von Ihnen ähnliche Erfahrungen gemacht? Hat jemand von Ihnen je ein STM-CDC Beispiel unter Windows 10 zum Laufen gebracht? Natürlich könnte z.B. eine geänderte Windows 10 Funktionalität schuld sein. (Ein Hinweis wäre, dass z.B. auch FTDI am 28.07.2015 neue Treiber heraus gebracht hat.) Klar, auch die eigene VCP-Software könnte ebenso irgendwo nicht Standard-Konform sein. Kennt jemand STM-VCP Beispiele die unter Windows 10 laufen? Kennt jemand Hinweise was sich geändert haben könnte? Vielen Dank für jede Information, die ich zu diesem Problem erhalten kann. Gruß Gerald
Gerald L. schrieb: > Kennt jemand STM-VCP Beispiele die unter Windows 10 laufen? Kennt jemand > Hinweise was sich geändert haben könnte? Das liegt nicht am VCP auf dem STM sondern an dem Treiber der wahrscheinlich einfach nicht für Windows 10 geeignet ist. Oder gibt ST den Treiber für Windows 10 frei? Wenn man so die Infos zum Treiber liest, dann steht da nichts von Windows 10. Last version *************** - V1.4.0 - 10/20/2014 Supported OS *************** + Windows 98SE, 2000, XP, Vista, Seven, 8.x (x86 & x64 Windows platforms) Da würde ich mich nicht wundern, wenn das nicht geht.
Ja das stimmt schon. Aber sollten nicht alle Geräte welche unter Win8.1 laufen auch unter Win10 laufen? Ich denke ich hätte dies schon mehrfach so gelesen. Zumindest sollte es funktionieren, wenn man die Kompatibilitätseinstellungen entsprechend setzt. Ich wundere mich, dass so gar nichts im Web darüber zu finden ist. Wenn der VCP auf der Basis von STM-CDC Beispielen generell unter Windows 10 nicht laufen würde, müssten doch auch andere Probleme melden. Kann jemand bestätigen ob sein "Virtueller Com Port" unter Win10 funktioniert?
"Virtueller Com-Port" ist nicht gleich "Virtueller Com-Port". Es gibt Geräte, die die USB-Standardgeräteklasse CDC verwenden, für die ist der Treiber Bestandteil von Windows, zur Installation wird lediglich eine *.inf-Datei benötigt. Es gibt aber auch Geräte, die ein komplett eigenes Protokoll verwenden und deswegen eigene Devicetreiber benötigen -- das ist bei den USB-Seriell-Bridges von FTDI, Prolific und auch SiLabs der Fall. Der Name "STM-CDC" lässt vermuten, daß hier die Standardgeräteklasse verwendet wird, das sollte unter Windows 10 genauso funktionieren wie unter den Vorgängerversionen, es sei denn, dort wird explizit ein Treiber installiert (also ein Paket aus *.sys, *.inf und *.cat).
bei mir ist es so das ich lustigerweise undter windows 10 2 cdc vcom geräte angezeigt bekommen. ich frag mich was da nich stimmt und wann st einen win10 treiber rausbringt
Inzwischen habe ich folgendes herausbekommen. Windows 10 unterstützt nun z.B. erstmals automatisch CDC Devices, ohne dass man eine eigene Inf bräuchte. Teilzitate von MSDN: In Windows 10, a new INF, Usbser.inf, has been added to %Systemroot%\Inf that loads Usbser.sys as the function device object (FDO) in the device stack. If your device belongs to the Communications and CDC Control device class, Usbser.sys is loaded automatically. The driver is loaded based on a compatible ID match similar to other USB device class drivers included in Windows. USB\Class_02, USB\Class_02&SubClass_02 •If you want to load Usbser.sys automatically, set the class code to 02 and subclass code to 02 in the Device Descriptor.... (Genau die sind bei mir implementiert. Lösche ich alle "STM-Treiberleichen-Infs" durch das Upgrade, bekomme ich auch sauber einen virtuellen Comport via neuem Standard-Windows-Treiber. Leider funktioniert dieser mit genau dem gleichen Fehlerbild...) (Anmerkung/Erfahrung: Will man die alten Coms vollständig löschen, sollte man Administrativ ein "set devmgr_show_nonpresent_devices=1" absetzen und erst dann die ausgeblendeten Coms anzeigen/löschen.) •If your device specifies class code 02 but a subclass code value other than 02, Usbser.sys does not load automatically. Pnp Manager tries to find a driver... (Genau dies kann ich unter Windows 10 auch tun, ich bekomme dann eben wieder die STM-Treiber. Mit dem gleichen Fehlerbild...) Bezüglich "Virtueller Com-Port" ist nicht gleich "Virtueller Com-Port": Ja, STM schiebt bislang Windows nur eine Inf unter, verwendet also die schon länger existierenden Standardgeräteklassen. Also eigentlich sollte es also immer noch funktionieren. Ich vermute aber, dass sich etwas in Windows 10 an den "Standardgeräteklassen" geändert hat, die nun auch in beiden Fällen (Windows-Inf oder STM-Inf) gleichermaßen verwendet werden. Das Microsoft da Fehler gemacht hat, halte ich erst einmal für eher unwahrscheinlich. Die auf dem Controller implementierte Funktionalität wird irgendetwas nicht richtig tun, was sie standardmäßig aber besser tun sollte. Z.B. etwas nicht beantworten, was zumindest bislang auch noch nicht nötig war. Es ist aber auch gut möglich, dass ich in der Vergangenheit etwas im ursprünglichen Beispiel geändert habe, was ich besser nicht ändern hätte sollen... Bezüglich "Nun tauchen 2 auf", das kenne ich so noch nicht. Mir ist aber bekannt, das eine Geräteinstance gleich mehrere Endpoints zur schnelleren Kommunikation aufbauen könnte. Gut möglich das diese 2 Comports wieder verschwinden und in einem Comport enden, wenn erst der richtige Treiber gefunden und installiert ist. Gibt es weitere positive oder negative "STM"-"CDC"-"Windows 10" Erfahrungen ?
Ich habe das Problem vorerst gelöst. Unter Windows 10 (und nur unter Windows 10) schlägt bei mir PC-seitig die Microsoft-Funktion ReadFile fehl, sie liefert permanent den "GetLastWin32Error" "ErrorIOPending". Tatsächlich funktioniert diese Funktion, bis auf diese Fehlermeldung. Die Zeichen, welche man laut ClearCommError/ComStat.InQue (d.h. der ReadCount) lesen darf, werden trotz Fehlermeldung dennoch erfolgreich in den Buffer übertragen. Wenn ich die Fehlermeldung ignoriere, kann ich wieder via VCP kommunizieren. Verwendet man die Klasse SerialPort (.NET System.IO.Ports), scheint die Kommunikation auch zu klappen. (Dies habe ich nur mit ein paar Bytes getestet). Von dieser Klasse hatte ich in der Vergangenheit abgesehen, da diese bei gleicher Funktionalität deutlich mehr Rechnerlast als die "Filesystemlösung" generierte. Ob der Fehler nun den "Standardgeräteklassen" oder "meiner Controllerfunktionalität" zuzuschreiben ist, wird wohl die Zukunft zeigen...
gerald_loh schrieb: > Ich wundere mich, dass so gar nichts im Web darüber zu finden ist. > > Wenn der VCP auf der Basis von STM-CDC Beispielen generell unter Windows > 10 nicht laufen würde, müssten doch auch andere Probleme melden. die anderen sind halt klug genug das Windows 10 erst in etwa nem Jahr zu installieren, dann sind die gröbsten Bugs gefixt (von Microsoft und Fremdherstellern) und es lassen sich genug Anleitungen finden wie man die restlichen umschiffen kann.
Hallo Gerald, vielen Dank für Deine Informationen. Bis jetzt habe ich von meinen Kunden noch keine negativen Rückmeldungen bezüglich des STM32 VCP unter Win10, aber es ist gut zu wissen, dass da ggf. was im Busch ist. Frage: hast Du Tests mit bekannten Terminalprogrammen gemacht? ich denke da so an Hyperterm, TeraTerm, HTerm? Grüße, marcus
Hallo Marcus, RealTerm und HTerm antworten korrekt. Andere habe ich nicht getestet...
Hallo Gerald, ich denke ich habe das gleiche Problem. Ich möchte unter Windows 10 (64bit) für die STM32F407 einen COM-Port einrichten. Ziel ist es einige Beispiele von Matlab/Simulink zu testen. Gibt es inzwischen hierfür eine Lösung bzw. einen workaround. Vielen Dank schon an dieser Stelle. Reinhard
Hallo Reinhard, mit Matlab/Simulink kenne ich mich leider nicht aus. Wenn diese PC-seitig scheitern hilft vermutlich nur einen CP210 oder einen anderen funktionierenden USB/Serial Konverter vor den STM zu hängen und dann rein seriell zu kommunizieren. Mit dem STM32F407 habe ich mich auch noch nicht beschäftigt, eher mit der STM32LXX Familie. Der ComPort seitens STM war aber auch nicht mein Problem, vielmehr die geänderte Funktionalität in Win10 gegenüber den vorhergehenden Windows-Versionen. Wenn Dein ComPort z.B. unter Win8 mit Matlab/Simulink läuft, hilft es nur auf eine entsprechende Win10 Unterstützung zu warten, oder auf die Lösung "funktionierender USB/Serial Konverter"+"seriell kommunizieren" umzusteigen...
Gerald L. schrieb: > A B E R, zurück gesendete Zeichen kommen aber nicht mehr am PC an. Kein > Zeichen kommt zurück. Nur unter Windows 10 (x86). Kann es sein, daß dein µC-seitiger Treiber die Probleme macht und die Daten zwar an selbigen abgegeben werden, aber nicht gesendet werden? Da hättest du (vermutlich) nen logischen Bug, der bloß bisher nicht zum Tragen gekommen ist. Also: WIE sendest du denn nun ganz genau deine Daten zum PC? Immerhin kommen die ja völlig asynchron von allen Teilen deiner sonstigen Firmware, müssen dann im CDC-Treiber zwischengespeichert werden, dann gepackt, dann zum Senden bereitgestellt werden. Nochwas: warum benutzt du überhaupt einen Treiber von ST auf der PC Seite? Ich hab ja schon diverse µC von Nuvoton, NXP, ST per CDC an den PC angeschlossen und benutze immer nur ein und dieselbe .inf (natürlich dazu passend die Deskriptoren im µC). W.S.
Hallo W.S. 1. nein, Controller-seitig habe ich sehr wohl korrekt gesendet, nur die Win32-API Microsoft-Funktion ReadFile schlug unter Win10 in so fern fehl, dass diese zusätzlich zum korrekten Ergebnis den "GetLastWin32Error" "ErrorIOPending" lieferte. Vorhergehende Windows-Versionen taten dies bei gleicher Controller Firmware nicht. Gründlich wie ich war (und wie man es wohl auch tun sollte), hatte ich den Fehler ausgewertet und damit die gleichzeitig korrekt empfangenen Daten PC-seitig wieder verworfen. Für mich sah das dann in erster Instanz so aus, als würden die Zeichen gar nicht gesendet. Tatsächlich wurden diese aber gesendet und "inclusive Fehlermeldung" auch empfangen. 2. Ja, viele schieben Windows nur eine Inf unter, verwenden damit also die schon länger existierenden Standardgeräteklassen mit passenden Deskriptoren. Auch wenn man den Treiber von ST installiert, passiert offenbar nichts anderes. Warum kann ich bei gleicher Controller und Windows-Software unter WinXP, Vista, 7, 8, 8.1 x32 und x86 ohne einen "ErrorIOPending" empfangen und unter Win10 bekomme ich einen "ErrorIOPending"? => Variante 1: Die Controller Firmware ist fehlerhaft. => Variante 2: Es hat sich seit Win10 an der "CDC Standardgeräteklasse" etwas geändert. Variante 1 ist gut möglich, bislang hat Windows z.B. bestimmte Timing-Fehler einfach ohne Fehlermeldung toleriert. Variante 2 ist in jedem Fall richtig, sonst würde es ja unter Win10 auch keine Fehlermeldungen geben. Vielleicht ist Variante 2 fehlerhaft, vielleicht wurde Variante 2 auch korrekt eingeführt, um Fehler die bislang toleriert werden konnten, zukünftig etwas einzugrenzen...
Gibt's inzwischen eine Lösung für das Problem? Bei Google ist ja nicht wirklich viel dazu zu finden. Bin gerade dabei, mich mit dem STM32F103 vertraut zu machen, und bin auf genau das beschriebene Problem mit mehreren VCP-Beispielen gestoßen. Unter Windows XP/Server 2003 läuft der VCP einwandfrei. Unter Windows 10 hakt es auch bei mir: Bei einem meiner Testprogramme schlägt gleich der CreateFile-Aufruf fehl und gibt INVALID_HANDLE_VALUE zurück. Bei einem alten Visual Basic 6 Programm mit dem Comm-Steuerelement lässt sich der Port öffnen, aber sobald Daten ankommen und gelesen werden sollen gibt's einen Fehler. Mit PuTTY lässt sich der Port fehlerfrei zugreifen. Anscheinend hängt's also auch von den verwendeten APIs ab. Das Problem habe ich sowohl mit dem USB-CDC-Beispiel aus STM32Cube, als auch mit älteren USB-VCP-Beispielen.
So, ich bin der Sache nochmal ein bisschen nachgegangen: Es liegt definitiv an dem usbser.sys-Treiber von Windows 10. Ich habe kurzerhand die usbser.sys von Windows 7 x64 genommen, mit einem selbst erstellten Zertifikat signiert (ohne das akzeptiert Win10 sie nicht), und die originale usbser.sys von Win10 in System32\drivers und System32\DriverStore\FileRepository\usbser.inf_... durch diese Datei ersetzt. Dann den COM-Port im Geräte-Manager deinstalliert, das Gerät neu angeschlossen, und es läuft :) Ich persönlich kann mit dieser Lösung leben, für den kommerziellen Einsatz taugt sie aber definitiv nicht.
Stimmy schrieb: > So, ich bin der Sache nochmal ein bisschen nachgegangen: > Es liegt definitiv an dem usbser.sys-Treiber von Windows 10. > > Ich habe kurzerhand die usbser.sys von Windows 7 x64 genommen, mit einem > selbst erstellten Zertifikat signiert (ohne das akzeptiert Win10 sie > nicht), und die originale usbser.sys von Win10 in System32\drivers und > System32\DriverStore\FileRepository\usbser.inf_... durch diese Datei > ersetzt. > Dann den COM-Port im Geräte-Manager deinstalliert, das Gerät neu > angeschlossen, und es läuft :) > > Ich persönlich kann mit dieser Lösung leben, für den kommerziellen > Einsatz taugt sie aber definitiv nicht. Wurde mal getestet, ob es am Selective Suspend liegt? Einstellungen (entweder über Registry am PC oder erweiterte Deskriptoren auf dem Gerät), siehe: https://msdn.microsoft.com/en-us/library/windows/hardware/dn707976(v=vs.85).aspx Auch wenn es laut MS im Default nicht aktiviert ist...
Wenn Ihr das neuest Update 1607 für Windows 10 einspielt, hat sich dieses Problem automatisch behoben. Anscheinend hat man bei Microsoft endlich reagiert und die usbser.sys auf den "alten" Stand vor Windows 10 zurückgebracht.
STM32 Experte schrieb im Beitrag #4706025: > Wenn Ihr das neuest Update 1607 für Windows 10 einspielt, hat sich > dieses Problem automatisch behoben. Anscheinend hat man bei Microsoft > endlich reagiert und die usbser.sys auf den "alten" Stand vor Windows 10 > zurückgebracht. Kann noch jemand diese Info bestätigen? Im Web habe ich noch keine positive Abschlussinfo gefunden. Die relavantesten Infos, die ich finden konnte: https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex%5fmx%5fstm32%2fWindows%2010%2c%20STM32L15X%20%2d%20VIRTUAL%20COM%20PORT%20%2d%20Problems&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=1393 https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex%5fmx%5fstm32%2fSTM32%20VCP%20vs%20Windows%2010&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=2370 http://answers.microsoft.com/en-us/windows/forum/windows_10-hardware/stm32-bootloader-shows-up-in-windows-7-computer/dba1f70d-c416-42a1-ba24-d05c06dd7649?auth=1 http://answers.microsoft.com/en-us/windows/forum/windows8_1-hardware/windows-81-encountered-an-error-attempting-to/320c8b1f-0d89-477b-9fd3-f9f255bccc39
Ich habe die SUBCLASS im Programm für den STM32F4 auf 0x02 geändert damit Windows 10 das Board/den VCP automtisch erkennen kann. Ältere ST VCP Treiber habe ich versucht zu deinstllieren, zumindest alles was ich finden konnte. Wenn ich das Board jetzt mit dem Computer verbinde tauchen 2 Geräte im Geräte-Manager auf. Einmal unter "Anschlüsse (COM & LPT)" ein "Serielles USB-Gerät (COM3)" und unter "Andere Geräte" ein "STM32 Virtual ComPort in FS Mode" Beide funtionieren aber nicht / haben das gelbe Ausrufezeichen/Warnschild am Symbol im Geräte-Manager. Unter Windows 7 mit dem ST Treiber taucht der VCP unter "Anschlüsse (COM & LPT)" als "STMicroelectronics Virtual COM Port (COM18)" auf, und funktioniert auch Problemlos. Ich würde das nur gerne unter Windos 10 ohne extra Treiber zum laufen bringen, und es scheint ja bei einigen hier auch zu funktionieren. Hat jemand evtl. eine Idee was bei mir da schief läuft?
Ich renne gerade ebenfalls in dieses Problematik. Ein STM32-Gerät das unter Windows 7 via VCOM läuft bekommt keine Verbindung unter Windows 10. Drauf gestoßen bin ich, nachdem ich via hterm: "Error in OpenPort: Internal error when initializing 'COMx'" als Meldung nach Klick auf "Connect" erhielt. Ich hatte mir die VCP_V1.4.0_Setup.exe von der ST Website gezogen (schlimm das man sich da jetzt auch schon registrieren muss), aber ich bekomme, egal aus welchem Programm heraus, keine Verbindung. Hat hier jemand eine Lösung, die verständlich und nachvollziehbar ist?
Hat niemand anderes das Problem und keiner eine Lösung finden können?
Hallo zusammen, inzwischen habe ich eine funktionierende Lösung. Ich habe eine ältere Treiberversion bekommen, da die aktuelle von der STM Website (1.4.0.0 vom 20.10.2014) unter Windows 10 64bit nicht funktioniert. Diese ältere Version enthält einen Windows 7 Treiber 64bit (1.3.1.0 vom 25.04.2010) und einen Windows 8 Treiber 64bit (1.4.0.0 vom 02.08.2013). Beide Treiber laufen unter Windows 10 bisher problemlos. Die Boards werden erkannt und ich empfange wie erwartet meine Daten. Damit auch anderen geholfen ist hänge ich diese Treiberversionen mal an, in der Hoffnung das auch andere, die hier auf Probleme stoßen einen Lösungsansatz haben. branadic
branadic, vielen Dank, Du hast mir sehr geholfen, es funktioniert tadellos!
:
Bearbeitet durch User
Nach dem großen Creators Update laufe ich erneut in das Problem, nur das diesmal kein Treiber mehr funktioniert. Hat jemand das gleiche Problem und kann evenuell mit einer Lösung aufwarten? Ich bekomme von HTerm die Rückmeldung: Error in OpenPort: Internal error when initializing 'COM3 Meine Versuche mich via Matlab oder Octave mit dem Gerät zu verbinden scheitern ebenfalls. Matlab: Error using serial/fopen (line 72) Open failed: Cannot connect to the COM3 port. Possible reasons are another application is connected to the port or the port does not exist. Octave: Error opening the interface: Zugriff verweigert Der Geräte Manager zeigt das Gerät jedoch korrekt an. -branadic-
Treiber im Geräte Manager deinstallieren und neu installieren schon versucht? Ansonnsten hilft vielleicht das hier: http://www.dronetrest.com/t/zadig-drivers-for-cleanflight-betaflight-stm32-flight-controllers-dfu-mode/2719
Mark R. schrieb: > Treiber im Geräte Manager deinstallieren und neu installieren schon > versucht? Ja klar, das Problem existiert ausschließlich auf win 10 Rechnern, unter win7 habe ich dagegen keine Probleme dieser Art.
Ich habe mich auch an ST gewandt und denen mein Problem geschildert. Bisherige Antwort sinngemäß: Wir benutzen Windows 7 im Büro, wir sind uns daher nicht sicher ob wir ihnen helfen können. Auf meinem privaten Windows 10 PC ohne Creators Update läuft der VCP. Sie müssen nicht einmal den ST VCP Treiber installieren, der generische Windows Treiber reicht aus. Hab den ST Treiber also deinstalliert und den generischen Treiber versucht, aber auch das funktioniert als Lösung nicht. :(
Ich kann mich noch daran erinnern, ich hatte mal ein ähnliches Problem. Das hatte als Ursache ein zu spätes Aufruf der Serial.begin() Funktion in setup(). Ich hab dadurch gelöst hab, dass der Serial.bgin() als erster Befehl im Arduino sketch setup() Funktion ausgeführt wurde.
STM32GENERIC Bei mir laufen alle Boards ( versch. NUCLEOS, DISCOVERYS ) problemlos unter Win 10. Was oefters ein Problem bei den Boards mit Stlink war: man muss mit dem STMutility updaten !
branadic schrieb: > Ich renne gerade ebenfalls in dieses Problematik. Ein STM32-Gerät das > unter Windows 7 via VCOM läuft bekommt keine Verbindung unter Windows > 10. Hmm.. ich vermute mal, daß das ein Problem mit den Treibern von ST ist, was genau dadurch aufkommt, daß du und andere schön brav die USB-Funktionen von ST benutzt und auch die Deskriptoren so sind, daß eben bloß ein Treiber von ST in Frage kommt. Ich hab das anders gemacht, ich benutze das magere .inf File von Nuvoton, was nix anderes tut, als die zum jeweiligen Windows gehörigen Treiber mit der vorhandenen vid+pid verbindet - und habe die Deskriptoren entsprechend angepaßt. So laufen bei mir µC von Nuvoton, NXP und ST alle unter der gleichen Flagge und es wird eben KEIN Treiber von irgendeinem Hersteller gebraucht. Ich hatte den ganzen Kram hier schon mal gepostet. Ich vermute sehr stark, daß in den Quellen von ST einfach das Nachschauen nach Daten, die an den Host gehen sollen, im Usb-Timertick fehlt. So schläft dann die ganze Kommunikation nach dem allerersten Paket ein. W.S.
So, nachdem ich heute für ein Uniprojekt mal wieder ein USB CDC Device brauchte und die Standard USB Konfiguration die CubeMX generiert das Gerät zwar im Device Manager auftauchen lässt, allerdings mit "Code 10" als fehlerhaft anzeigt, durfte ich mich mal wieder damit rumschlagen. Ich arbeite mit einem STM32F4 Discovery und benutze das OTG_HS_USB Peripheral mit onboard FS Phy und der CDC Device Middleware. Ich wusste zwar noch, dass ich genau dieses Problem vor einem Jahr oder so schon einmal gedebuggt habe, allerdings kam ich einfach nicht mehr darauf, was ich damals geändert hatte. Also mal wieder ein paar Stunden Microsoft Message Analyzer + Debugger ausgepackt. Das Problem mit dem Code, den CubeMX generiert ist, dass er in der Device Enumeration ein größeres malloc hat, und zwar in
1 | static uint8_t USBD_CDC_Init (USBD_HandleTypeDef *pdev, |
2 | uint8_t cfgidx) |
3 | [...]
|
4 | pdev->pClassData = USBD_malloc(sizeof (USBD_CDC_HandleTypeDef)); |
5 | [...]
|
Wenn man also die Heapsize auf 0x2000 oder so setzt, dann funktioniert es. Ich hoffe mal, dieser Post erspart mir das dritte mal Debuggen in einem weiteren Jahr.
:
Bearbeitet durch User
Und wo wir gerade dabei sind: Wenn man nicht nur will, dass das Device korrekt enumeriert, sondern man es dann auch noch mit Terminalprogrammen korrekt öffnen kann, sollte man in der usbd_cdc_if.c das hier einfügen:
1 | static int8_t CDC_Control_HS (uint8_t cmd, uint8_t* pbuf, uint16_t length) |
2 | {
|
3 | [...]
|
4 | case CDC_GET_LINE_CODING: |
5 | // vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
|
6 | pbuf[0] = pbuf[3] = pbuf[4] = pbuf[5] = 0; |
7 | pbuf[1] = 0xc2; |
8 | pbuf[2] = 0x01; |
9 | pbuf[6] = 0x08; |
10 | // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
11 | break; |
12 | [...]
|
Das sind irgendwelche Konstanten für Baudrate und was weiß ich, kann man sich genauer anschauen wenn man es braucht. Aber damit funktioniert das USB dann wenigstens "out of the box" an Win10
Felix U. schrieb: > Das sind irgendwelche Konstanten für Baudrate und was weiß ich,.. Eben, du weißt es NICHT. Es gibt Setup-Pakete für unterschiedliche Instanzen innerhalb des Devicetreibers im µC. Darunter eben auch solche, wo Baudrate, Parität, Stopbits usw. übermittelt werden. Anstatt da irgendwelche Konstanten hinzuschreiben, wäre das korrekte Ausweren des Setup-Paketes anzuraten. W.S.
Unter Windows 7 Embedded läuft der VCP Treiber auch nicht, das ist schon etwas schwach von ST. Genau da könnte man die Anwendung in der Praxis ja brauchen, warum das nur auf Desktop-Betriebssystemen läuft ist mir ein Rätsel.
Felix U. schrieb: > Das sind irgendwelche Konstanten für Baudrate und was weiß ich, kann man > sich genauer anschauen wenn man es braucht. Aber damit funktioniert das > USB dann wenigstens "out of the box" an Win10 Gut zu wissen, Vielen Dank!
Der CDC Treiber von ST ist nur eine Konfigurationsdatei mit Installationsprogramm. Als Treiber wird eine DLL von Windows benutzt, die als bereits vorhanden vorausgesetzt wird. Was mir nicht in den Kopf geht: Warum stellen die nicht einfach nur die INF Datei zum Download bereit? Stattdessen verpacken sie das mehrfach in selbst extrahierende EXE Dateien und ZIP Dateien mit einem vollkommen überflüssigen Installationsprogramm. Als ob sie verbergen wollten, welch simple Technik in Wahrheit dahinter steckt. Um noch einen drauf zu setzen, schreiben Sie dann noch einen Lizenz-Dokument, bei dem ich auch nach 10x lesen nicht herausfinden konnte, ob ich diesen Pseudo-Treiber nun in kommerziellen Produkten benutzen darf oder nicht.
Stefan U. schrieb: > Was mir nicht in den Kopf geht: Warum stellen die nicht einfach nur die > INF Datei zum Download bereit? Weil sie alleine nix nützt. Ab Windows 8.1 muss auch die .inf signiert sein. Schau Dir lieber mal das neueste Zadig (http://zadig.akeo.ie/) an, dessen neueste 2.3 Version kann auch den CDC Treiber installieren.
Felix U. schrieb: > Und wo wir gerade dabei sind: Wenn man nicht nur will, dass das Device > korrekt enumeriert, sondern man es dann auch noch mit Terminalprogrammen > korrekt öffnen kann, sollte man in der usbd_cdc_if.c das hier einfügen: > >
1 | > static int8_t CDC_Control_HS (uint8_t cmd, uint8_t* pbuf, uint16_t |
2 | > length) |
3 | > { |
4 | > [...] |
5 | > case CDC_GET_LINE_CODING: |
6 | > // vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv |
7 | > pbuf[0] = pbuf[3] = pbuf[4] = pbuf[5] = 0; |
8 | > pbuf[1] = 0xc2; |
9 | > pbuf[2] = 0x01; |
10 | > pbuf[6] = 0x08; |
11 | > // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
12 | > break; |
13 | > [...] |
14 | >
|
> > Das sind irgendwelche Konstanten für Baudrate und was weiß ich, kann man > sich genauer anschauen wenn man es braucht. Aber damit funktioniert das > USB dann wenigstens "out of the box" an Win10 Ist ja schon ein alter Thread, aber. Danke noch einmal für diesen Hinweis. Hat bei mir funktioniert. Vorher konnte ich den Port nicht öffnen mit Win10 professionell 64 bit. Auf dem alten win10 (home) rechner gab es das Problem nicht. Wenn man an dieser Stelle keine Werte definiert, bekommt der PC irgendwelche undefinierten Werte für das line setting. Das scheint neuere Win10 Rechner zu stören. Ich übernehme Deinen Default Wert (115200,N,8,1) beim Start des Programms und ändere die 7 bytes, falls der PC in SET_LINE_CODING andere Werte verlangt. Klappt immer. Danke nochmal
Der Thread ist zwar ziemlich alt, ich hatte aber auf einem STM32F105VC das gleiche Problem und konnte es mit den hier genannten Methoden leider nicht lösen. Ich verwende die STM32CubeIDE, habe in dem CubeMX auch das Projekt konfiguriert (USB-Stack als USB-Device und Funktion als COM-Port). In meinem Fall konnte ich das Problem lösen, indem ich in der Funktion "int main()" in "main.c" vor dem Aufruf von "MX_USB_DEVICE_Init()" ein Delay von 2 Sekunden eingebaut habe. Danach hat Windows das Gerät einwandfrei erkannt. Der Controller braucht etwas Zeit für die Initialisierung. Außerdem MUSS das USB Kabel zum Controller VOR dem Start des Controllers verbunden werden (also der Controller darf nicht schon Initialisieren wenn er nicht über ein USB Kabel verbunden ist). Eine Mögliche Lösung für dieses Problem ist eine bedingte USB Initialisierung, also "MX_USB_DEVICE_Init()" erst aufrufen wenn tatsächlich ein USB Kabel in STM32 und Rechner eingesteckt ist. Da meine Platine keine Ausführung für den VBUS Pin hat, kann ich nicht testen ob unter dieser Option eine Verbindung auch im Betrieb möglich ist. Ansonsten könnte aber auch ein Spannungsteiler von VUSB auf einen Input gelegt werden und ausgehend von dem anliegenden Signal wird die USB Funktion initialisiert.
Leander P. schrieb: > ein Delay von 2 Sekunden > Außerdem MUSS das USB Kabel zum Controller VOR > dem Start des Controllers verbunden werden Beides sollte eigentlich nicht nötig sein. Ich frage mich, ob die HAL (mal wieder) fehlerhaft ist.
Hallo, ich hatte auch Probleme mit Win10 und hatte festgestellt, dass beim Enumerieren am Bus direkt die Baudrate vom PC gelesen wird. (Da steht bei den generierten Sourcen von CubeMX undefinierter Mist drin.) Dann wird auf ein default gesetzt und dann wird noch einmal gelesen. Das passiert wie gesagt beim Enumerieren automatisch ohne dass ich die serielle Schnittstelle öffne. Das führt dann bei Win10 zu einem enumerations fail. Ich habe nur entsprechenden code für set_linecoding und getlinecoding eingefügt und schon gab es keine Probleme. Die HAL hat keinen Fehler, aber der generierte CubeMX ist unvollständig. meine codestücke
1 | /* USER CODE BEGIN PRIVATE_VARIABLES */
|
2 | unsigned char myLineCoding[7] = {0x0,0xc2,0x1,0,0,0,8}; //115200 bps,n,8,1 |
3 | |
4 | /* USER CODE END PRIVATE_VARIABLES */
|
5 | ....
|
6 | case CDC_SET_LINE_CODING: |
7 | datarate = (unsigned)pbuf[0] |((unsigned)pbuf[1]<<8)|((unsigned)pbuf[2]<<16)|((unsigned)pbuf[3]<<24); |
8 | for(i=0;i<7;i++) myLineCoding[i]=pbuf[i]; |
9 | #if USE_ESP32
|
10 | LL_USART_SetBaudRate(USART3, HAL_RCC_GetSysClockFreq() , LL_USART_PRESCALER_DIV1, |
11 | LL_USART_OVERSAMPLING_16, |
12 | datarate); |
13 | #endif
|
14 | |
15 | break; |
16 | |
17 | case CDC_GET_LINE_CODING: |
18 | for(i=0;i<7;i++) pbuf[i] = myLineCoding[i]; |
19 | break; |
Martin B. schrieb: > Ich habe nur entsprechenden code für set_linecoding und getlinecoding > eingefügt und schon gab es keine Probleme. Hab deinen Code bei mir eingesetzt, allerdings taucht der Enumerations-Fehler bei mir immer noch auf. Ich denke ich werde bei dem Delay bleiben oder einen Workaround für die Verbindung im Betrieb schreiben (Bedingte Initialisierung). Trotzdem Danke für den Hinweis. Ich werde nochmal ein Update geben wenn ich auf anderen MCUs der STM32F1 Reihe getestet habe.
Ich habe hier noch einmal probiert das USB-Kabel erst später nach dem Powerup zu connecten. Klappte ohne Probleme auch mehrfach hintereinander. Die USB statemachine macht das problemlos mit. Habe allerdings auch keine F1 Serie, sondern STM32G474 am Start. Kann es sein, dass Du während der Enumeration eine starke Interruptlast hast? Da habe ich mal Probleme mit dem USB Stack von STM gesehen. Eventuell musst Du die Priority vom USB IRQ mal höher als den Rest der IRQs setzen, um das zu testen.
Ich hatte auf dem STM32F103 kein solches Problem. Details zum Setup: http://stefanfrings.de/stm32/stm32f1.html#vcphal
Martin B. schrieb: > Eventuell musst Du die Priority vom USB IRQ mal höher als den Rest der > IRQs setzen, um das zu testen. Grade eben getestet, hat sich wieder nix getan. Im reference manual (RM0008) für die STM32F Reihe (bis auf F4xx) wird im Unterpunkt "USB Device Configuration (29.17.3)" die Verwendung des VBUS Sensing Pins vorgeschrieben. Dadurch erkennt das STM32 dann das ein Kabel angeschlossen ist... Bei anderen Reihen kann das wohl intern zugeschaltet werden. Ich werde das jetzt mal auf meinem Evalboard testen, auf der Platine auf welcher das deployed werden soll ist dieser Pin aber schon belegt (heißt ich MUSS bedingt initialisieren wenn ein Kabel angeschlossen ist). Da ich noch keine TVS Diode hier hab muss ich mir aus dem was verfügbar ist etwas basteln. Ich gebe ein Update wenn sich dann was tut.
Stefan ⛄ F. schrieb: > Ich hatte auf dem STM32F103 kein solches Problem. > Details zum Setup: http://stefanfrings.de/stm32/stm32f1.html#vcphal Jop genau dieses Setup habe ich verfolgt aber die USB OTG Peripherie vom F105/107 scheint anders zu sein als die "simple" USB Peripherie des F103.
Leander P. schrieb: > Martin B. schrieb: >> Eventuell musst Du die Priority vom USB IRQ mal höher als den Rest der >> IRQs setzen, um das zu testen. > > Grade eben getestet, hat sich wieder nix getan. > > Im reference manual (RM0008) für die STM32F Reihe (bis auf F4xx) wird im > Unterpunkt "USB Device Configuration (29.17.3)" die Verwendung des VBUS > Sensing Pins vorgeschrieben. Dadurch erkennt das STM32 dann das ein > Kabel angeschlossen ist... > > Bei anderen Reihen kann das wohl intern zugeschaltet werden. > > Ich werde das jetzt mal auf meinem Evalboard testen, auf der Platine auf > welcher das deployed werden soll ist dieser Pin aber schon belegt (heißt > ich MUSS bedingt initialisieren wenn ein Kabel angeschlossen ist). Da > ich noch keine TVS Diode hier hab muss ich mir aus dem was verfügbar ist > etwas basteln. Ich gebe ein Update wenn sich dann was tut. Das Update kommt ein wenig spät, allerdings hatte ich auf einem STM32F103 "BluePill" Board keinerlei Probleme mit USB Hotplugging. Als ich letztlich die finale Platine zum Testen erhalten habe (mit STM32F105 drauf) hat letztlich auch alles funktioniert. Dort ist USB Hotplugging möglich. Auf dem billigen EvalBoard, auf welchem ich ursprünglich getestet habe, scheint wohl etwas nicht zu stimmen.
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.