mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik USB Firmwarefehler führt zu Code10 in Windows7 x64


Autor: Robert S. (lpc)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bert 0. (maschinist)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Robert S. (lpc)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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):
excerpt of related section in Setupapi.dev.log:

     dvi:                          Install Device: Restarting device. 12:00:30.334
     dvi:                          Install Device: Restarting device completed. 12:00:44.677
!!!  dvi:                          Device not started: Device has problem: 0x0a: CM_PROB_FAILED_START.
     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

Autor: Robert S. (lpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Robert S. (lpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Robert S. (lpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Mars (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Robert S. (lpc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
>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

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.