USB-Control-Transfer-STALL: Setup-Pakete, Endpoint Null und fehlgeschlagene Geräte-Requests debuggen

USB-Control-Transfers sind die Grundlage der Enumeration und Device-Verwaltung. Sie lesen Deskriptoren, setzen Adressen, wählen Konfigurationen, wechseln Interfaces, geben Klassen-Requests aus und senden herstellerspezifische Kommandos. Wenn ein Control-Transfer stallt, sehen Nutzer möglicherweise "USB device not recognized", "control transfer failed", "libusb control transfer error", "endpoint zero stalled" oder einen Firmware-Updater, der bei der Initialisierung stoppt.

Suchen wie "USB control transfer STALL", "USB setup packet debugging", "endpoint zero stall", "GET_DESCRIPTOR failed" und "vendor request stalled" bedeuten meist, dass der Fehler passiert ist, bevor normaler Bulk-, Interrupt- oder Isochronous-Traffic weiterlaufen konnte.

Bus Scope hilft, weil das Setup-Paket den Request erklärt. Ohne es ist ein STALL nur ein generischer Fehler.

Was ein Control-Transfer enthält

Ein USB-Control-Transfer hat Stages:

1. Setup-Stage
2. Optionale Data-Stage
3. Status-Stage

Das Setup-Paket enthält:

• bmRequestType
• bRequest
• wValue
• wIndex
• wLength

Diese Felder definieren Richtung, Request-Typ, Empfänger, Request-Code, Deskriptor-Typ, Interface, Endpoint und erwartete Datenlänge.

Stallt das Gerät, prüfen Sie zuerst das Setup-Paket.

Endpoint Null ist besonders

Endpoint Null existiert für jedes USB-Gerät. Er wird während der Enumeration und für Control-Operationen genutzt. Verhält sich Endpoint Null falsch, bindet der Host möglicherweise nie den normalen Treiber.

Endpoint-Null-Fehler können auftreten als:

• Device-Deskriptor-Request fehlgeschlagen.
• Configuration-Deskriptor-Read fehlgeschlagen.
• String-Deskriptor-Request gestallt.
• SET_CONFIGURATION fehlgeschlagen.
• Klassenspezifischer Request fehlgeschlagen.
• Vendor-Kommando fehlgeschlagen.

Für Custom-Firmware ist Endpoint-Null-Korrektheit nicht verhandelbar.

STALL kann valide sein

Nicht jeder STALL ist ein Bug. Ein Gerät darf einen nicht unterstützten Request legitimerweise stallen. Die Frage ist, ob der Host Support erwartet hat und ob der Device-State den Request erlaubt.

Beispiele:

• Nicht unterstützter Vendor-Request: STALL kann korrekt sein.
• Ungültiger Deskriptor-Index: STALL kann korrekt sein.
• Benötigter Klassen-Request während der Enumeration: STALL kann Treiberbindung zerstören.
• DFU-Request im falschen State: STALL kann State-Machine-Mismatch anzeigen.

Die Bedeutung hängt von Request-Typ und Timing ab.

Deskriptor-Request-Fehler

Deskriptor-STALLs sind in Custom-USB-Stacks häufig. Achten Sie auf:

• Falscher Deskriptor-Typ in wValue.
• Nicht unterstützter String-Index.
• Mismatch der Configuration-Gesamtlänge.
• Gerät gibt weniger Daten zurück als angefragt – falsch behandelt.
• Gerät behandelt kurze initiale Deskriptor-Reads nicht.
• Firmware nimmt ein Host-Request-Muster an.

Verschiedene Betriebssysteme fragen Deskriptoren in unterschiedlichen Reihenfolgen an. Ein Gerät, das unter Linux läuft, kann einen Request stallen, den Windows während der Enumeration sendet.

Klassen- und Vendor-Requests

Klassen-Requests werden von der USB-Klasse interpretiert. HID, CDC, DFU, Audio, Video, Mass Storage und herstellerspezifische Geräte haben alle Request-Erwartungen.

Häufige Beispiele:

• HID GET_REPORT
• HID SET_REPORT
• CDC SET_LINE_CODING
• CDC SET_CONTROL_LINE_STATE
• DFU GETSTATUS
• UVC-Probe/Commit-Controls
• Herstellerspezifische Bootloader-Kommandos

Stallt ein Klassen-Request, prüfen Sie, ob die Interface-Nummer in wIndex zum gedachten Interface passt. Composite-Devices scheitern häufig, weil der Host einen Request an ein Interface sendet und die Firmware ein anderes behandelt.

Debug-Checkliste

Nutzen Sie diesen Workflow:

1. Ab Anstecken capturen.
2. Den ersten Control-Transfer-STALL finden.
3. Die Setup-Paket-Felder dekodieren.
4. Bestimmen, ob der Request Standard, Class oder Vendor ist.
5. Empfänger bestimmen: Device, Interface, Endpoint oder Other.
6. wValue, wIndex und wLength prüfen.
7. Mit Deskriptoren und aktuellem Device-State vergleichen.
8. Prüfen, ob der STALL erwartet oder fatal ist.
9. Nach Recovery-Requests wie Clear-Feature oder Reset suchen.
10. Host-OS-Request-Reihenfolge vergleichen, wenn das Verhalten plattformübergreifend abweicht.

Enddiagnose

USB-Control-Transfer-STALL allein ist nicht genug Information. Das Setup-Paket ist der Diagnose-Anker. Es sagt, welcher Request fehlgeschlagen ist, welcher Empfänger adressiert wurde, wie viele Daten erwartet wurden und ob der Device-State den Request valide gemacht hat.

Bus Scope hilft, Endpoint-Null- und Setup-Paket-Evidence offenzulegen, sodass Firmware-, Treiber- und QA-Teams Control-Path-Fehler präzise debuggen können.