USB-Endpoint-Halt-Recovery: CLEAR_FEATURE, STALL-Loops, Bulk-Fehler und Treiber-Reset-Verhalten

USB-Endpoint-Halts sind eine häufige Quelle für "läuft einmal, scheitert dann"-Device-Bugs. Ein Bulk-Transfer stallt, der Treiber cleart den Halt, das Gerät stallt erneut, und am Ende meldet die App Timeout, I/O-Fehler, Device-Reset oder Disconnected. Nutzer suchen nach "USB endpoint halt", "CLEAR_FEATURE ENDPOINT_HALT", "USB STALL loop", "bulk endpoint stalled" und "libusb clear halt", wenn das Gerät nicht einfach verschwindet, sondern auf einem bestimmten Endpoint keinen Traffic mehr annimmt.

Bus Scope hilft, weil Endpoint-Halt-Recovery eine Sequenz ist, kein einzelnes Ereignis. Sie müssen den ersten STALL, den Host-Recovery-Request, was das Gerät danach getan hat, und ob dasselbe Kommando den Halt erneut ausgelöst hat, sehen.

Was Endpoint-Halt bedeutet

Ein Endpoint-Halt bedeutet, dass der Endpoint gestallt ist und keine normalen Transfers mehr durchführen kann, bis die Halt-Bedingung gecleart wird. Der Host kann:

CLEAR_FEATURE(ENDPOINT_HALT)

an den betroffenen Endpoint ausgeben. Danach müssen Endpoint-Data-Toggle und Device-State konsistent sein, damit der Transfer korrekt resumed.

Cleart die Firmware nur das USB-Hardware-Flag, aber nicht ihren internen Protokoll-State, kann der nächste Transfer erneut fehlschlagen.

STALL vs. Timeout

STALL ist explizit. Timeout heißt, dass keine Completion innerhalb der erwarteten Zeit kam. Ein Timeout kann passieren, weil der Endpoint nie geantwortet hat, das Gerät weiter NAKt hat oder das Gerät disconnected ist.

Endpoint-Halt-Recovery startet mit einem STALL. Sieht der Host nie einen STALL und nur einen Timeout, ist der Recovery-Pfad anders.

Bulk-Endpoint-Halt

Bulk-Endpoints halte oft, wenn ein Kommando ungültig ist, eine Protokoll-Phase falsch ist oder die Firmware einen Fehler erkennt.

Beispiel:

Host -> Device bulk OUT command
Device -> Host STALL on bulk IN
Host -> Device CLEAR_FEATURE(ENDPOINT_HALT)
Host retries bulk IN
Device stalls again

Dieses Muster deutet darauf hin, dass der Endpoint-Halt ein Symptom des Device-Protokoll-States ist, nicht nur ein transienter Bus-Fehler.

Recovery muss zur Endpoint-Richtung passen

Endpoint-Adressen enthalten die Richtung. Endpoint 0x81 und Endpoint 0x01 sind verschiedene Richtungen. Den falschen Endpoint zu clearen, recoveret die gestallte Pipe nicht.

Prüfen Sie:

• Welcher Endpoint stalled?
• Richtung IN oder OUT?
• Hat der Host denselben Endpoint gecleart?
• Haben Transfers nach Clear resumed?
• Sind Data-Toggle/State korrekt recovered?

Das ist eine häufige Quelle irreführender "clear halt did not work"-Reports.

Wiederholte STALL-Loops

Wiederholte STALLs nach Clear bedeuten meist, dass die Ursache bleibt:

• Host sendet erneut ein nicht unterstütztes Kommando.
• Firmware-State-Machine bleibt im Fehler.
• Gerät erwartet Reset vor Retry.
• Host liest vom falschen Endpoint.
• Kommando-Länge oder Checksumme ist falsch.
• Endpoint-Data-Toggle/State ist inkonsistent.
• Firmware braucht Class/Vendor-Request vor Resume.

Der Trace sollte das Kommando vor dem ersten STALL enthalten, nicht nur die Recovery-Versuche.

Treiber-Reset-Verhalten

Scheitert Clear-Halt-Recovery, resettet der Treiber möglicherweise das Gerät. Das kann den ursprünglichen Endpoint-Fehler verdecken. Der Nutzer sieht einen Reconnect oder Device-Verschwinden, aber die Bus-Evidence zeigt, dass der echte erste Fehler ein STALL-Loop war.

Timeline bewahren:

1. Letztes erfolgreiches Kommando.
2. Erster STALL.
3. Clear-Halt-Versuch.
4. Retry.
5. Wiederholter STALL oder Timeout.
6. Device-Reset oder Disconnect.

Debug-Checkliste

Nutzen Sie diesen Workflow:

1. Den gestallten Endpoint identifizieren.
2. Endpoint-Richtung und Transfer-Typ aufzeichnen.
3. Das Kommando oder den Transfer direkt vor dem STALL inspizieren.
4. Prüfen, ob der Host CLEAR_FEATURE(ENDPOINT_HALT) sendet.
5. Bestätigen, dass es den richtigen Endpoint adressiert.
6. Prüfen, ob der Transfer resumed.
7. Bei wiederholtem STALL den Firmware-Protokoll-State inspizieren.
8. Auf Device-Reset nach fehlgeschlagener Recovery achten.
9. Mit bekannter-guter Kommando-Sequenz vergleichen.
10. Genug Kontext vor dem STALL bewahren.

Enddiagnose

USB-Endpoint-Halt-Recovery ist ein State-Machine-Problem. CLEAR_FEATURE(ENDPOINT_HALT) kann die USB-Endpoint-Bedingung clearen, aber es fixt nicht automatisch den Firmware-Protokoll-State, ungültige Kommandos, falsche Endpoints oder Treiber-Retry-Logik.

Bus Scope hilft, die volle Halt- und Recovery-Sequenz offenzulegen, sodass Endpoint-Fehler aus tatsächlichem USB-Verhalten diagnostiziert werden können.