USB-Bulk-Transfer-Timeout: Debugging von High-Speed, Full-Speed, STALL, NAK und Device-Firmware-Verzögerungen

USB-Bulk-Transfers kommen zum Einsatz, wenn Korrektheit wichtiger ist als fixes Timing. Storage-Devices, Serial-Adapter, Debug-Probes, Firmware-Updater, Scanner, herstellerspezifische Geräte und viele Datenerfassungs-Produkte nutzen Bulk-Endpoints. Wenn sie ausfallen, suchen Nutzer nach "USB bulk transfer timeout", "bulk endpoint stalled", "USB read timeout", "USB write timeout", "libusb bulk transfer failed" und "USB device stops responding during bulk transfer".

Die Anwendung sieht meist einen Timeout oder I/O-Fehler. Der Bus erzählt vielleicht eine reichere Geschichte: das Gerät hat zu lange NAKt, der Endpoint stalled, der Host hat retried, das Gerät hat resettet, die Transfer-Größe war falsch, die Device-Speed war niedriger als erwartet, oder die Firmware blockierte beim Vorbereiten der Daten.

Bus Scope hilft, weil Bulk-Transfer-Ausfälle Endpoint-Level-Evidence brauchen – nicht nur einen Stack-Trace aus der App.

Wofür Bulk-Transfers gut sind

Bulk-Transfers sind auf USB-Protokoll-Ebene zuverlässig. Sie nutzen verfügbare Bandbreite und können retryen. Sie sind gut für große Datenmengen, bei denen Latency weniger streng ist als Korrektheit.

Häufige Bulk-Geräte:

• USB-Mass-Storage
• CDC-Serial-Adapter
• herstellerspezifische Firmware-Tools
• Debug-Probes
• Messgeräte
• Drucker und Scanner
• einige Capture-Devices
• FPGA- oder Mikrocontroller-Daten-Pipes

Weil Bulk-Transfers übriggebliebene Bus-Bandbreite nutzen, kann die Performance je nach anderem USB-Traffic und Host-Scheduling variieren.

Timeout heißt nicht immer Paketverlust

Ein Bulk-Transfer-Timeout heißt meist, dass der host-seitige Request nicht innerhalb des App-Timeouts abgeschlossen wurde. Das kann passieren, selbst wenn sich der USB-Bus protokollkonform verhält.

Mögliche Ursachen:

• Gerät hat keine Daten bereit und NAKt weiter.
• Firmware ist busy und verzögert die Antwort.
• Endpoint ist nach STALL halted.
• Host hat Request an falschen Endpoint geschickt.
• Transfer-Größe passt nicht zur Protokoll-Erwartung.
• Gerät wurde resettet oder disconnected.
• Treiber hat den Transfer nicht korrekt submitted.
• Full-Speed-Pfad ist für erwarteten Throughput zu langsam.
• Anderes Gerät verbraucht Bus-Bandbreite.
• App-Timeout ist zu aggressiv.

Der Trace sollte zeigen, was davon plausibel ist.

NAK-Verhalten

USB-Geräte können mit NAK antworten, um zu signalisieren, dass sie temporär nicht bereit sind. NAK ist nicht zwingend ein Fehler. Es ist ein Flow-Control-Signal.

Für einen Bulk-IN-Endpoint können wiederholte NAKs bedeuten, dass das Gerät noch keine Daten hat. Für einen Bulk-OUT-Endpoint können NAKs bedeuten, dass das Gerät gerade keine weiteren Daten annehmen kann.

Das Problem ist Dauer und Kontext. Ein paar NAKs sind normal. Durchgehende NAKs bis zum App-Timeout bedeuten entweder, dass das Gerät nie bereit wurde oder dass der Host zur falschen Zeit Daten erwartet hat.

STALL und Endpoint-Halt

Ein STALL unterscheidet sich von NAK. Es heißt meist, dass der Endpoint gehaltet wurde oder der Request in dem Kontext nicht unterstützt wird. Recovery erfordert oft:

CLEAR_FEATURE(ENDPOINT_HALT)

Wenn der Host den Halt nicht cleart, können spätere Transfers weiter fehlschlagen. Stallt der Endpoint direkt nach dem Clearen erneut, lehnt die Geräte-Firmware möglicherweise die Kommando-Sequenz ab.

Achten Sie auf:

• Erster STALL vor Timeout.
• CLEAR_FEATURE(ENDPOINT_HALT).
• Ob der Transfer nach Clear weiterläuft.
• Gleiches Kommando, das jedes Mal STALLt.
• Reset nach wiederholtem STALL.

High-Speed vs. Full-Speed-Erwartungen

Die USB-Speed verändert, welcher Throughput realistisch ist. Ein Full-Speed-Gerät kann keinen High-Speed-Throughput liefern. Ein High-Speed-fähiges Gerät kann durch Kabel, Hub, Port, Signal-Integrität oder Geräte-Negotiation zurückfallen.

Nimmt die App High-Speed-Performance an, das Gerät enumerierte aber als Full-Speed, können Timeouts bei großen Transfers auftreten.

Prüfen Sie Deskriptoren, verhandelte Speed, Endpoint-Max-Packet-Size und tatsächliches Transfer-Pacing. Leiten Sie die Speed nicht aus Stecker-Form oder Marketing-Label ab.

Firmware-Kommando-Protokolle

Viele Bulk-Geräte implementieren ein Kommando/Response-Protokoll auf USB. Der Host schreibt ein Kommando auf Bulk-OUT und wartet auf Daten auf Bulk-IN.

Timeouts passieren, wenn:

• Kommando-Format falsch ist.
• Gerät vor dem Bulk-Transfer einen Control-Request erwartet.
• Gerät Status auf einem anderen Endpoint sendet.
• Host zu früh liest.
• Host zu viel liest.
• Firmware beim Verarbeiten des Kommandos blockiert.
• Gerät eine Zero-Length-Packet-Grenze braucht.
• Vorheriger Fehlerzustand nicht gecleart wurde.

Packet-Evidence zeigt, ob das Gerät das Kommando ignoriert, gestallt, angenommen aber nie beantwortet, oder auf einem anderen Endpoint geantwortet hat.

Bulk-Transfer-Größe und Short-Pakete

USB-Bulk-Protokolle nutzen oft Short-Pakete, um das Transfer-Ende zu signalisieren. Erwartet der Host eine feste Länge, sendet das Gerät aber ein Short-Paket, interpretiert die App das Ergebnis möglicherweise falsch. Wartet der Host nach dem Transfer-Ende weiter auf Daten, kann auf App-Layer ein Timeout auftreten.

Achten Sie auf:

• Angeforderte Transfer-Länge.
• Tatsächlich zurückgegebene Länge.
• Short-Paket.
• Zero-Length-Paket.
• Protokoll-Framing über USB hinweg.

Das ist besonders wichtig in Custom-Firmware- und libusb-basierten Tools.

Debug-Checkliste

Nutzen Sie diesen Ablauf:

1. Enumeration und Endpoint-Deskriptoren capturen.
2. Device-Speed und Endpoint-Max-Packet-Size bestätigen.
3. Bulk-IN- und Bulk-OUT-Endpoints identifizieren.
4. Das Kommando oder den Transfer capturen, das/ders timed out.
5. Prüfen, ob der Endpoint NAK, STALL, Daten oder Disconnect zurückgibt.
6. CLEAR_FEATURE(ENDPOINT_HALT)-Recovery inspizieren, falls STALL auftritt.
7. Angeforderte Länge und tatsächliche Länge vergleichen.
8. Prüfen, ob das Gerät ein Short-Paket oder Zero-Length-Paket sendet.
9. Direkter Port vs. Hub und High-Speed- vs. Full-Speed-Pfad vergleichen.
10. Mit Firmware-Logs korrelieren, falls verfügbar.

Enddiagnose

USB-Bulk-Transfer-Timeout ist nicht ein Bug. Es kann normales NAK-Verhalten sein, das einen App-Timeout überschritt, nicht wiederhergestellter Endpoint-STALL, fehlende Firmware-Antwort, niedrigere Speed als erwartet, falsches Protokoll-Framing oder ein Geräte-Reset.

Bus Scope hilft, indem es die Endpoint-Level-Sequenz offenlegt – so wird ein Timeout zu diagnostizierbarer USB-Evidence statt zu einem generischen I/O-Fehler.