LibUSB Composite Device kackt ab

[Der A. (der-albi)]

Hallo
Ich habe Probleme mit LibUSB. Mein Mp3-Player ist in der Regel ein 
MassStorageDevice. Für Debugzwecke habe ich ein weiteres Interface 
definiert, mit Classcode 0xff und 2 weiteren Endpoints.

Mit Hilfe von LibUSB für Winsdows wollte ich nun auf meine Endpoints 
zugreifen. Das funktioniert jedoch absolut nicht zuverlässig. Das Gerät 
hängt sich auf (Host-Seitig).

Auf dem Mp3-PLayer läuft das Atmel MSD mit angepassten DeviceDescriptor 
und zusätzlicher Abfrage der 2 weiteren Debug-Endpoints.

Was ich bissher festgestellt habe: Der Mp3-Player läuft mit LibUSB nur 
zuverlässig, wenn das MSD deaktiviert ist und der treiber explizit für 
die PID und VID des Players installiert ist.

Wird der Player als "Verbundgerät" angemeldet kann ich NUR für dieses 
LibUSB installieren. Obwohl der Gerätemanager das MSD als auch das 
DebugInterface (bei "Unbekannte Geräte") anzeigt.
Liegt das unstabile verhalten an dieser tatsache? Kommen sich eventuell 
die Treiber in die Quere? Es ist ja so, dass für das verbundgerät im 
ganzen LibUSB als Treiber genommen wird und das MSD ja für sich seinen 
eigenen Treiber lädt.


Des weiteren habe ich auf dem Device Softwareseitig ein Problem:
Ich bekomme eine Anfrage die ich ohne CompositeDevice nicht bekomme.
Und zwar bekommt der Control-Endpoint die Anfrage "CLEAR FEATURE" mit 
dem RequestType 0x81 (129). Ohne CompostiteDevice (Also NUR MSD) wird da 
NUR RequestType 0, 1, oder 2 gesendet.

Ich poste mal den Code:

void usb_process_request(void)
{
  ...
  bmRequest = ...
  bmRequestType = ...
  ...
  switch (bmRequest)
  {
  ...
  case CLEAR_FEATURE:
    /*if (bmRequestType <= 0x02)*/ usb_clear_feature();
    //else { /*asm volatile ("breakpoint"); */goto unsupported_request; }
    break;
  ...
  }
}

Zugegebener maßen weiß ich zur Zeit nicht was ich mit diesem RequestType 
anfangen soll und ob das eventuell mein Fehler ist.

Es kann ja auch sein, dass der Host abkackt, weil das Device noch unfug 
macht.

Kann mir da jemand bitte Helfen? :-)

Zur Ergänzung: LibUSB rennt hauptsächlich in (2.5sec-)Timeouts, kann 
Interfaces nicht "release"n oder "claim"en, und Folgefehler die sich 
daraus ergeben, da Windows das Gerät dann einfach abmeldet ohne den 
Treiber zu entladen.

Verwendet wird Simpler Bulk-Transport.

Ich bitte um Antworten :-)
MFG

[Martin F. (martinf)]

Der Albi schrieb:
> Und zwar bekommt der Control-Endpoint die Anfrage "CLEAR FEATURE" mit
> dem RequestType 0x81 (129).

Ein CLEAR_FEATURE Request überträgt keine Nutzdaten zum Host. Und da du 
es geschafft hast, die relevanten Codeteile aus usb_process_request() zu 
entfernen, kann dir keiner sagen wo der Fehler liegt. Wofür soll der 
Codeauszug überhaupt gut sein? Zumindest das auskommentierte goto 
hättest du entfernen können ...

[Der A. (der-albi)]

Die ganze Funktion ist im Anhang.
Die Breakpoints habe ich hingemacht, damit ich sehe, wenn etwas kommt, 
was nicht behandelt wird. Der eine ist auskommentiert weil ich nun weiß, 
dass dort was schief läuft, und wenn der dort anhalten würde kommt die 
Enumeration in ein Timeout.
Das ist sozusagen der OriginalCode von Atmel + Breakpoints.

Noch mehr Informationen:
Es reicht schon, wenn ich das MSD im Gerätemanager deinstalliere. Sofort 
funktioniert mein Debugprogramm mit LibUSB perfekt.
Warum?

[Martin F. (martinf)]

Wenn dieses CLEAR_FEARTURE Request kommt, was befindet sich dann noch im 
Endpoint Puffer? Hat bmRequest auch sicher den Wert 0x01?
bmRequestType 0x81 würde einem GET_* Request für Interfaces entsprechen, 
falls sich nicht irgendwelcher Datenmüll im Puffer befindet.

> Es reicht schon, wenn ich das MSD im Gerätemanager deinstalliere. Sofort
> funktioniert mein Debugprogramm mit LibUSB perfekt.
Eventuell kann LibUSB die Interfaces nicht für sich beanspruchen, wenn 
das MSD vom Betriebssystem verwendet wird.

[Der A. (der-albi)]

Was noch im FIFO steckt lese ich nachher nochmal aus. Ich wollte es 
eigentlich mal mitsniffen, aber so richtig tut das grade nicht ;-)

Ich habe aber im Sniffer gesehen, dass das MSD scheinbar "bleib 
Wach"-Daten sendet - auf jeden fall gehen sehr sehr viele Pakete raus, 
die keinen Nutzen haben.

Dennoch MUSS es irgendwie gehen! Das kann doch nicht sein, das beides 
auf einmal nicht funktoiniert..
Ich schaue mir jetzt erst nocheinmal Atmels CompositeDevices an und 
schaue mal dort auf den Inhalt der Funktionen. Irgendwo muss die 
Interfaceunterscheidung ja vollzogen werden. das Fehlt bei mir ja noch 
komplett.
Ich bezweifle aber, dass das wirklich der Fehlergrund sein kann (?)

MFG

[DerAlbi (Gast)]

Un die Frage zu beantworten: wenn ClearFeature mit 0x81 aufgerufen wird, 
dann steht im ControlEndpoint NICHTS mehr drin. Mehr scheint da nicht 
anzukommen.
MFG

[Martin F. (martinf)]

Wird wohl eines der vorhergehenden Requests falsch verarbeitet wodurch 
noch 2 Bytes in der FIFO verbleiben.

[DerAlbi (Gast)]

Also ich habe jetzt nochmal die Interface reihenfolge im Descriptor 
vertauscht. Wäre es wirklich ein Requestproblem, sodass die interfaces 
sich in die quere kommen, sollte ja nun das MSD (weil es nun numm 1 
statt 0 ist) nicht mehr gehen.
Tatsache ist, dass das MSD einwandfrei funktioniert. Auch auf 
Interfaceummer 1.

Wenn man ein wenig bei google recherchiert, ließt man auch häufig, dass 
LibUSB probleme mit CompositeDevices hat.. andere wiederum sagen es das 
funktionioert.

Gibt es denn noch andere freiel USB-Bibliotheken? Vielleicht ist es 
sinnvoll mal in diese Richtung zu denken.

[Christian R. (supachris)]

DerAlbi schrieb:

> Gibt es denn noch andere freiel USB-Bibliotheken? Vielleicht ist es
> sinnvoll mal in diese Richtung zu denken.

Auf WinUSB basierend: Beitrag "Generischer USB Treiber für Windows mit C++ API"

[Der A. (der-albi)]

Vielen Dank für den Hinweis!
Ich arbeite mit Borland C++ und bekomme bei der Vererb ungsstruktur der 
ErrorKlassen ständig fehler geschmissen. Die Lib fällt für mich wolh 
flach.
Entweder BCB ist dumm oder der Code nutzt inkompatible erweiterungen.
LibUSB war da einfacher.. :-(
Ich werde nachher erstmal untersuchen welche der standardRequest 
überhaupt empfangen werden.
Kann jemand sagen, welche unbedingt kommen müssen (bei einem 
Compositedevice)?

MFG

[DerAlbi (Gast)]

Auferufen wird:
GET_DESCRIPTOR
SET_ADDRESS
SET_CONFIGURATION
CLEAR_FEATURE

Nicht aufgerufen:
GET_CONFIGURATION
SET_FEATURE
GET_STATUS
GET_INTERFACE
SET_INTERFACE

Ist daran was komisch?