Hallo an Alle, ich bin der Neue. Ich komme gleich zur Sache: Ich arbeite an einem Gerät mit USB-Schnittstelle mit. Beim Verbinden des Gerätes mit einem PC über die USB-Schnittstelle wird auf dem PC eine virtuelle COM-Schnittstelle (vCOM) installiert. Diese kann dann von einer PC-Anwendung zur Kommunikation mit dem Gerät genutzt werden. Die vCOM wurde schon auf PCs mit Windows2000 und Windows XP installiert und hat bisher funktioniert, d.h. eine PC-Anwendung (z.B. ein Terminalprogramm) konnte mit dem Gerät kommunizieren. Ein verfügbarer Referenz-PC auf dem die vCOM läuft, hat UHCI (eine PCI-Karte mit USB-Controller) bzw. OHCI (Onboard-USB-Controller). Als USB-Hardware im Gerät dient ein LPC2368 Mikrocontroller. Dieser hat natürlich noch andere Aufgaben. Als USB-Firmware dient das USBCDC-Beispiel zum Keil MCB2300 (MikrocontrollerBoard) aus MDK-ARM 3.23a in einer stark modifizierten Version. (Einige der Modifikationen wurden allerdings ohne Kenntnis ihrer Tragweite vorgenommen und könnten nun zu Problemen führen.) Nun zum Problem: Ich habe das Gerät an einen Laptop-PC mit Windows7 x64 (im Folgenden als "Problem-PC" bezeichnet) angeschlossen. Dort zeigt der Gerätemanager nach der Treiberinstallation (betriebssystemeigene usbser.sys über selbst erstellte INF-Datei) ein gelbes Ausrufezeichen und schreibt "Code10 - Das Gerät kann nicht gestartet werden.". Der Laptop hat einen Enhanced Host Controller. Ich habe auch nach langer Recherche (Internet über Suchmaschinen, Suche und eigener Thread im Keil-Forum, Kauf des "USB2.0 Handbuch für Entwickler" von Jan Axelson, Suche in diesem Forum, Lesen der USB-Spezifikationen) bisher keine Lösung für das Problem gefunden. Nach 2 Wochen hatte ich zumindest herausgefunden, dass es nicht an meiner INF-Datei liegt. Nach weiteren 2 Wochen bin ich jetzt relativ sicher, dass meine USB-Deskriptoren (nach kleinen Änderungen) Ok sind. Wobei es dort noch offene Fragen gibt... Inzwischen habe ich mittels USB-Analyzer-Software (SourceUSB 3.2.0) herausgefunden, dass während der Enumerationsphase am Problem-PC etwas schief läuft. Das Gerät scheint eine Anforderung (SELECT_CONFIGURATION) nicht korrekt oder zu spät zu quittieren. Ich füge mal einen Ausschnitt der von SourceUSB mitgeschnittenen Anforderungen an (Screenshot). Dort kann man sehen, dass die SELECT_CONFIGURATION-Anforderung nach über 20ms(!) mit dem Irp Status "INVALID_PARAMETER" beendet wird und gleich darauf das Gerät wieder automatisch entfernt wird. Manchmal waren es auch über 50ms. Ich habe leider keine Ahnung warum. Möglicherweise ist es ein Zeitproblem in Verbindung mit dem EHCI... Jedenfalls habe ich natürlich auch verschiedene Gegenproben mit SourceUSB gemacht: Ich habe mal die Enumeration auf dem Referenz-PC geloggt. Auch dort vergehen über 50ms nach dem Start der SELECT_CONFIGURATION-Anforderung, aber dann wird die Anforderung mit Irp Status "SUCCESSFUL" beendet und man kann die vCOM im Anschluss benutzen. Weiterhin habe ich mir das Keil MCB2300 genommen und 2 verschiedene USBCDC Beispielprogramme aufgespielt. Einmal aus MDK-ARM 3.23a und einmal aus MDK-ARM 4.01. Dann habe ich das MCB mit dem Problem-PC verbunden und mit SourceUSB die Enumeration geloggt. Mit beiden Beispielen lässt sich die vCOM installieren und wird sauber aktiviert (keine Fehlermeldungen im Gerätemanger oder in SourceUSB). Die SELECT_CONFIGURATION-Anforderung wird bereits nach weniger als 1ms(!) erfolgreich beendet. Der Fehler muss also in unserer modifizierten Firmware liegen... Allerdings habe ich nun keine Ahnung wonach ich suchen soll. Soll ich den Grund für die lange Zeitverzögerung beim Antworten auf die Anforderung suchen, oder nach etwas Anderem? Ich würde mich sehr über Hinweise und Hilfestellungen freuen! Bei Fragen stehe ich 7 - 16 Uhr zur Verfügung und versuche auf Rückfragen so schnell wie möglich zu antworten. Mit freundlichen Grüßen
Angehängte Dateien:
-
SourceUSB_Log_101109_01.jpg
470 KB
Hallo Hast du mal den Chapter 9 Test von USB.org über das device laufen lassen? ggf zeigt der schon auffälligkeiten oder mucken. Hast du zugriff auf nen USB Hardware analyser? software Analyser in allen eheren, nur was auf der Leitung läuft bekommt man damit sicher nicht mit. Macht W7 32 auch probleme? oder nur W7 64? Treiber signiert? Was sagen die log files von der PNP Treiber Installation bei der Treiberinstallation. gruss
Hallo Robert, ich betreue auch ein Produkt, das über USB einen VCOM erzeugt und habe ebenfalls sporadisch, in der letzten Zeit allerdings öfter, bei Kunden das Code 10 Problem. Auf anderen Rechnern läuft der Treiber einwandfrei, ist auch nicht der originale usbser.sys von M$, sondern von einem Dritthersteller aus Thüringen. Den verwendeten Treiber haben wir mittlerweile auch erfolgreich WHQL-zertifizieren lassen. Bisher waren immer PCs mit Intel ICH8 oder ICH9 Chipsatz betroffen. Der Workaround, der bisher immer gegriffen hat ist, alle USB-Controller im Gerätemanager zu deinstalieren und nach einem Neustart neu erkennen zu lassen. Danach kann dann wundersamerweise auch der CDC-ACM-Treiber problemlos installiert werden. Vorsiche Falle: Hat man Tastatur und Maus auch an USB, sperrt man sich natürlich beim Deinstallieren der USB-Controller zwangsläufig aus. Abhilfe: Wenn möglich, provisorisch mit PS/2-Tastatur arbeiten oder den Desktop über VNC ö.ä. für diese Aktion fernsteuern. Gruß...Bert
Angehängte Dateien:
-
USB_LOG01.png
77 KB
Guten Morgen. 123 schrieb: > Hallo > > Hast du mal den Chapter 9 Test von USB.org über das device laufen > lassen? > ggf zeigt der schon auffälligkeiten oder mucken. > Ich habe über Compliance Tests Tools gelesen, aber bisher keines genutzt. Ich habe mir USB20CV R1.4.2.4 jetzt direkt mal heruntergeladen. Mal sehen was da heraus kommt... 123 schrieb: > > Hast du zugriff auf nen USB Hardware analyser? software Analyser in > allen eheren, nur was auf der Leitung läuft bekommt man damit sicher > nicht mit. > Ich habe einen Hardware-Analyser zur Verfügung: USBee DX (http://www.usbee.com/). Allerdings hatte ich aufgehört den zu nutzen, weil ich an meinem PC (der Referenz-PC) keinen funktionierenden USB 2.0 - Anschluss mehr habe. Die Anforderungen für die Nutzung von 'USBee DX Data Extractor' (die Software zum USB Analyzer) besagen sinngemäß: USBee DX soll als einziges Gerät an einen USB 2.0 Controller angeschlossen werden, um die volle Bandbreite nutzen zu können und die geloggten Daten lückenlos auswerten / übertragen zu können. Data Extractor soll nicht auf dem Zielsystem laufen, sondern auf einem völlig unbelasteten System. Diesen Anforderungen kann ich nicht gerecht werden. Eine Log-Datei vom USBee DX Data Extractor hänge ich mal als Screenshot an. Es war der allererste Mitschnitt den ich von der USB-Kommunikation zwischen unserem Gerät und dem Windows7 x64 Laptop-PC gemacht habe. Im Keil-Forum kamen Hinweise, dass laut diesem Log bestimmte Anforderungen (GET_LINE_CODING und SET_CONTROL_LINE_STATE) nach GET_DESCRIPTOR_CONFIG fehlen oder die Konfigurationsdeskriptoren unvollständig vom Gerät gesendet werden: Die fehlenden Anforderungen sind bei der Enumeration jedoch kein MUSS (das Gerät sollte auch ohne diese Anforderungen ordnungsgemäß gestartet werden) und meiner Meinung nach wurden die Konfigurationsdaten von unserem Gerät vollständig geschickt. Dann gab es noch eine Vermutung bezüglich bMaxPacketSize0, allerdings habe ich die Größe testweise von 64 auf 8 Byte geändert ohne einen Erfolg. Die Übertragung war eben gestückelter, das Ergebnis jedoch daasselbe: Referenz-PC Ok, Problem-PC nicht Ok. 123 schrieb: > > Macht W7 32 auch probleme? oder nur W7 64? > Ich habe leider nur den Laptop-PC mit W7 x64. Ein anderer W7-PC steht mir momentan nicht zur Verfügung. Ich denke aber, dass die unterschiedlichen Controllertypen mit dem Problem zu tun haben. Von diesem Standpunkt aus sollte der W7 x64 Laptop-PC erstmal ausreichen, oder!? 123 schrieb: > > Treiber signiert? Was sagen die log files von der PNP Treiber > Installation bei der Treiberinstallation. > Nix digital signiert, wir haben leider noch nicht einmal eine eigene Vendor-ID... Aber darum kümmere ich mich gegebenenfalls später (wenn Alles läuft bespreche ich das mit meinem Projektleiter). Die log files der PnP Treiber Installation sagen (ich hab's mal aus meinem Keil-Thread kopiert):
1 | excerpt of related section in Setupapi.dev.log: |
2 | |
3 | dvi: Install Device: Restarting device. 12:00:30.334 |
4 | dvi: Install Device: Restarting device completed. 12:00:44.677 |
5 | !!! dvi: Device not started: Device has problem: 0x0a: CM_PROB_FAILED_START. |
6 | dvi: Class installer: Exit |
Mein Keil-Forum-Thread ist hier zu erreichen: http://www.keil.com/forum/17727/ @Bert: Der Workaround war mir bekant, hatte aber leider nicht gegriffen. Der Problem-PC hat laut Geräte-Manager folgenden Chipsatz: Intel® 5 Series / 3400 Series Chipset Family. Soweit Danke für die Feedbacks, ich melde mich sobald es Ergebnisse vom Compliance Test Tool oder Rückfragen eurerseits gibt! MfG
Ich habe das Compliance Test Tool auf dem Problem-PC installiert, nur leider wird unser Gerät von diesem Tool garnicht erkannt... Ich habe lange gebraucht um alle geforderten Rahmenbedingungen für das Tool zu prüfen und herzustellen und nun DAS: Das Gerät steht mit Code10 im Manager, aber das USB20CV bietet es nicht in der Liste zur Auswahl des zu testenden Gerätes an. :( Ich kann des Gerät auch auf meinem Referenz-PC nicht mit USB20CV testen, da ich keinen Enhanced Host Controller in diesem PC habe... Nun ist guter Rat teuer! Ich werde mal sehen, ob ich kurzfristig einen PC mit EHCI auftreiben kann...
Guten Morgen, Alles nicht so schlimm, USB20CV-Problem gelöst: Das USB 2.0 Hub braucht eine externe Stromversorgung, ich habe gestern noch geschafft das Gerät auf dem Problem-PC zu testen und tatsächlich einige Fehler angezeigt bekommen! Ich werde mich jetzt mal daran machen diese zu analysieren und zu beheben. Ich poste sie auch nachher noch... Bis dahin!
So, da bin ich wieder. Nach Nutzung des USB20CV zur Fehlersuche und nach Behebung der Fehler, wird das Gerät nun in Windows 7 x64 gestartet und kann benutzt werden. Die Fehler waren: * Im Standard Configuration Descriptor war Bit7 des bmAttributes-Feldes nicht auf 1 gesetzt, wie es die USB2.0-Spezifikation fordert. Das habe ich korrigiert. * Die Endpunkt-Paketgröße für die Bulk-Endpunkte war auf 512 Byte gesetzt. Für USB1.1-Geräte ist das nicht zulässig (maximal 64 Byte BulkEP-Paketgröße). Ich habe nun die maximale Paketgröße für die Bulk-Endpunkte auf 64Byte gesenkt. Das hätte wahrscheinlich schon gereicht, führt aber zu einem Folgeproblem, auf das ich gleich noch eingehe. Zusätzlich habe ich einen Device_Qualifier Descriptor und einen Other_Speed_Configuration Descriptor erstellt, um ein USB2.0-Gerät zu erhalten. In letzterem habe ich die BulkEP-Paketgröße auf 512 Byte gesetzt. Mit diesen Änderungen läuft der Chapter9-Test in USB20CV ohne Fehlermeldungen durch und unser Gerät wird ordnungsgemäß in Windows7 x64 gestartet. Zwar erst bei erneuter Verbindung nach dem Installieren des Treibers, aber das ist sicherlich ein Reset-Problem welches sich noch lösen lässt. Nun zum Folgeproblem: Sowohl in Win7, als auch in WinXP, versendet die Firmware keine Daten, sobald mit WriteEP() mehr als 64 Byte Daten versendet werden. Nun ist jedoch die Firmware auf bis zu 512 Byte Datenversand via WriteEP() ausgerichtet... Sicherlich könnte man das ändern, jedoch leidet die Performance darunter: Sobald einmal größere Datenmengen (bis zu 4MB) versendet werden, würde die (dann mehr gestückelte Bulk-) Übertragung spürbar langsamer. Ich verstehe nicht, warum selbst in Win7 keine Mengen größer 64 Byte versendet werden (dort müsste die Other_Speed-Konfiguration greifen, mit 512 Byte BulkEP-Paketgröße), wo ich ein USB2.0 EHCI habe. Kann mir das jemand erklären?
512 Bytes Paketgröße bei einem Bulk EP geht nur, wenn dein USB-Device High-Speed fähig ist. Und nicht nur USB 2.0 kann. Device Qualifier Descriptor und Other Speed Configuration brauchst du auch nur bei einem High-Speed USB-Device
Mars schrieb: > 512 Bytes Paketgröße bei einem Bulk EP geht nur, wenn dein USB-Device > High-Speed fähig ist. Und nicht nur USB 2.0 kann. Vielen Dank für die Info. Es war mir bisher nicht so deutlich bewusst, dass ein USB2.0-Gerät nicht zwangsläufig ein HighSpeed-Gerät sein muss. Die Überlegung ist auch hinfällig, da unser NXP LPC2368 nur FullSpeed kann: NXP schreibt auf http://www.nxp.com/#/pip/pip=[pip=LPC2364_65_66_67_68]|pp=[t=pip,i=LPC2364_65_66_67_68]: >The LPC2364/65/66/67/68 [...] incorporate a [...] USB full speed device >with 4 kB of endpoint RAM Damit hat sich das Thema HighSpeed wohl erledigt... Ich werde nun die WriteEP() in unserer Firmware etwas modifizieren, damit längere Pakete dort aufgeteilt werden und dann sollte es passen. Mars schrieb: > Device Qualifier Descriptor und Other Speed Configuration brauchst du > auch nur bei einem High-Speed USB-Device Ja, das ist mir bekannt. Allerdings war ich bis gestern der Meinung, dass unser Controller HighSpeed kann und hatte daher die Deskriptoren schonmal eingebaut... Nun nehm' ich sie wieder raus. Vielen Dank an 123, Bert Braun und Mars für die wirklich zielgerichteten Hinweise!!! MfG
Gern geschenen. Chapter 9 hat auch bei uns immer wieder ein paar kleine probleme aufgedeckt die im normalen betrieb so nicht erkennbar waren. USB HS ist so ein Problem mit ARM7 / Cortex M3 da gibts nicht so viele Bausteine / oder sollen erst nach 1 jähriger angkündigung erst nächstes jahr kommen. Wir sind da momentan auch grad auf der suche. gruss
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.