USB-Control-Transfer- und Setup-Packet-Debugging: Lesen von bmRequestType, bRequest, wValue und wIndex

USB-Control-Transfers sind das erste ernsthafte Gespräch zwischen Host und Device. Die Enumeration hängt davon ab. Das Klassen-Setup hängt davon ab. Herstellerspezifische Initialisierung hängt oft davon ab. Wenn Control-Transfers scheitern, sieht der Nutzer vielleicht nur "device not recognized" oder "driver failed", aber die Evidence liegt meist im Setup-Packet.

Für Firmware-Engineers ist das Lesen von bmRequestType, bRequest, wValue, wIndex und wLength einer der schnellsten Wege, von Rätselraten zu einem präzisen Fix zu kommen.

Das Setup-Packet ist der Request-Contract

Ein USB-Setup-Packet sagt dem Gerät:

• Richtung des Transfers
• Request-Typ: Standard, Class, Vendor oder Reserved
• Empfänger: Device, Interface, Endpoint oder Other
• Request-Code
• Value-Feld
• Index-Feld
• erwartete Datenlänge

Decodiert die Firmware diese Felder falsch, gibt sie möglicherweise den falschen Deskriptor zurück, stalled einen validen Request oder akzeptiert ein ungültiges Kommando. Sendet der Host einen unerwarteten Request, zeigt das auch der Capture.

GET_DESCRIPTOR ist der erste Blickpunkt

Während der Enumeration sendet der Host Standard-Deskriptor-Requests. Ein häufiges Muster umfasst:

• Device-Deskriptor-Request
• Configuration-Deskriptor-Request
• String-Deskriptor-Request
• HID-Report-Deskriptor-Request für HID-Geräte
• BOS-Deskriptor-Request auf neueren Hosts

Im Setup-Paket identifiziert bRequest GET_DESCRIPTOR, während wValue Deskriptor-Typ und Deskriptor-Index enthält. wIndex kann die Language-ID für String-Deskriptoren oder das Interface für klassenspezifische Deskriptoren identifizieren. wLength sagt, wie viele Bytes der Host erwartet.

Ist die Antwortlänge eines Deskriptors falsch oder gibt die Firmware weniger Bytes zurück als der Host braucht, kann die Enumeration später auf eine Weise fehlschlagen, die unverwandt wirkt.

Richtungsfehler sind teuer

Control-Transfers haben eine Richtung. Device-to-Host-Requests geben Daten zurück. Host-to-Device-Requests übertragen Daten oder konfigurieren State. Behandelt die Firmware einen Read als Write oder gibt Daten bei einem Write-Request zurück, rät der Host die Intention nicht höflich.

Achten Sie auf:

• IN-Richtung, aber keine Data-Stage
• OUT-Richtung, aber Firmware wartet auf Daten
• fehlende Zero-Length-Status-Stage
• STALL auf einem validen Standard-Request
• Klassen-Request, der vom falschen Interface behandelt wird

Der Capture sollte Request, Data-Stage und Status-Stage zeigen.

Class- und Vendor-Requests brauchen Interface-Kontext

Nach der Enumeration senden Klassentreiber klassenspezifische Requests. CDC kann Line-Coding-Requests senden. HID kann Report-Deskriptoren oder Feature-Reports anfragen. Vendor-Tools können Initialisierungs-Kommandos senden. Derselbe bRequest-Wert kann je nach Request-Typ und Empfänger Unterschiedliches bedeuten.

Prüfen Sie:

• Request-Typ
• Empfänger
• Interface-Nummer in wIndex
• Endpoint-Nummer, wenn der Empfänger Endpoint ist
• Payload-Bytes
• Antwort oder Stall

Hat ein Composite-Device mehrere Interfaces, ist das Routen des Requests an das falsche Interface ein häufiger Bug.

Wie Bus Scope helfen sollte

Bus Scope ist für USB-Evidence gebaut. Control-Transfer-Debugging braucht dekodierte Setup-Felder und Rohbytes zusammen. Die beste Sicht lässt Firmware-Engineers die semantischen Felder lesen und gleichzeitig die exakten Paket-Bytes validieren.

Eine nützliche Bus-Scope-Session für Control-Transfer-Debugging beantwortet:

• welches Setup-Paket ist fehlgeschlagen?
• war es Standard, Class oder Vendor?
• welcher Deskriptor oder welches Interface wurde angefragt?
• hat das Gerät die erwartete Länge zurückgegeben?
• hat die Firmware absichtlich oder falsch gestallt?
• hing der nächste Enumeration-Schritt von dieser Antwort ab?

Das Problem mag als "USB control transfer failed" beschrieben sein, aber der Fix liegt meist in einem fünf-Felder-Setup-Paket.