USB-Endpoint-STALL und Bulk-Transfer-Timeout: Den Capture lesen, bevor Sie die Firmware ändern

So debuggen Sie USB-Endpoint-STALLs, Bulk-Transfer-Timeouts und Firmware-seitige Data-Path-Fehler mit Transfer-Evidence.

USB, Endpoint, STALL, Bulk-Transfer, Firmware

Nach erfolgreicher Enumeration können USB-Geräte trotzdem auf Weisen scheitern, die für App-Entwickler mysteriös wirken: "Bulk-Reads timen out, Writes werden nie fertig, HID-Reports hören auf zu kommen, oder der Host meldet einen Endpoint-STALL. Diese Fehler werden oft als Treiber-Bugs oder zufällige Firmware-Hangs behandelt. Ein Capture kann das Problem meist deutlich schneller eingrenzen." Endpoint-Fehler sind Data-Path-Evidence. Sie passieren, nachdem der Host die Device-Form gelernt hat. Das heißt, Deskriptoren können korrekt sein, während das Endpoint-Verhalten trotzdem falsch ist.

STALL ist ein Signal, nicht nur ein Fehler

Ein USB-Endpoint kann STALL zurückgeben, um zu signalisieren, dass er einen Request nicht verarbeiten kann oder dass ein Class/Vendor-Kommando nicht unterstützt wird. Control-Endpoint-Stalls während Klassen-Requests können legitim sein, wenn der Request ungültig ist. Data-Endpoint-Stalls während normalem Transfer-Flow brauchen meist genauere Inspektion.

Capture-Fragen:

  • welcher Endpoint stalled?
  • war es Control, Bulk, Interrupt oder Isochronous?
  • welcher Request oder Transfer ging dem Stall voraus?
  • hat der Host die Halt-Bedingung gecleart?
  • ist der Traffic nach CLEAR_FEATURE(ENDPOINT_HALT) weitergelaufen?
  • hat die Firmware nicht unterstützte Kommandos absichtlich gestallt?

Ohne diesen Kontext ist "endpoint stalled" zu vage zum Handeln.

Bulk-Timeouts brauchen Richtungs- und Queue-Kontext

Bulk-Transfer-Timeout kann vieles bedeuten:

  • Host erwartete IN-Daten, aber Gerät hatte keine bereit
  • Gerät erwartete OUT-Daten, aber App hat aufgehört zu schreiben
  • Firmware-Endpoint-Buffer war nicht primed
  • Host-Treiber hat einen größeren Read submittet als die Firmware unterstützt
  • Gerät hat bis zum Timeout NAKt
  • Endpoint-Adresse oder -Richtung war falsch
  • vorheriger Stall wurde nie gecleart

Das Erste, was Sie prüfen, ist die Richtung. Ein Bulk-IN-Timeout und ein Bulk-OUT-Timeout sind verschiedene Fälle. Für IN fragen Sie, ob das Gerät jemals Daten zurückgegeben hat. Für OUT fragen Sie, ob der Host Daten gesendet hat und ob das Gerät sie acknowledged hat.

Deskriptor-Korrektheit ist notwendig, aber nicht hinreichend

Ein Deskriptor kann einen Bulk-IN-Endpoint korrekt deklarieren, und das Gerät kann trotzdem keine nützlichen Daten senden. Ein CDC-Gerät kann als Serial-Port enumerieren und trotzdem Line Coding oder Control Line State ignorieren. Ein herstellerspezifisches Interface kann Endpoints exponieren, aber ein Initialisierungs-Kommando vor der Datenbewegung brauchen.

Endpoint-Debugging muss also kombinieren:

  • Deskriptor-Evidence
  • Class- oder Vendor-Setup-Requests
  • Transfer-Richtung
  • Payload-Länge
  • Status-Ergebnis
  • Timing und wiederholte Versuche

Der Capture sollte zeigen, ob der Host etwas Unvernünftiges anfragt oder die Firmware einen validen Request nicht erfüllt.

Firmware-Teams sollten vor und nach dem Fix capturen

Für Endpoint-Bugs sind Vorher-Nachher-Captures wertvoll. Der erste Capture belegt den Fehler. Der zweite Capture belegt den Fix. Ein guter Vergleich zeigt:

  • dasselbe Gerät und Konfiguration
  • dieselben Endpoint-Adressen
  • dasselbe Host-Request-Muster
  • alter Capture stalled oder timed out
  • neuer Capture completed und trägt erwartete Payload

Das macht Firmware-Regression-Review deutlich einfacher. Es gibt Support-Teams auch ein wiederholbares Artefakt, wenn Kunden melden, dass "USB zufällig einfriert".

Wo Bus Scope passt

Bus Scope zielt auf USB-Evidence statt auf generischen Protokoll-Sprawl. Für Endpoint-STALL- und Timeout-Fälle hält es Paket-Detail, Endpoint-Metadaten, Rohbytes, Transfer-Typ und Klassen-Interpretation nahe zusammen.

Der nützliche Output:

  • Endpoint und Richtung
  • Transfer-Typ
  • Request oder Transfer vor dem Fehler
  • Status-Evidence
  • Roh-Payload rund um den Fehler
  • ob das Issue Enumeration, Klassen-Setup oder App-Traffic folgt

Das ist die Information, die Firmware-Engineers brauchen, bevor sie Endpoint-Buffer-Logik oder Host-seitiges Retry-Verhalten anfassen.

Lautet Ihre Suche "USB bulk transfer timeout" oder "USB endpoint stalled", fangen Sie nicht an, den gesamten Device-Stack neu zu schreiben. Capturen Sie zuerst die Endpoint-Evidence.