USB-Gerät trennt sich ständig: Reset-Loops, Power-Events und Enumeration-Fehler debuggen

Ein USB-Gerät, das sich ständig trennt, ist eines der frustrierendsten Hardware-Probleme, weil das Symptom laut und inkonsistent ist. Das Gerät erscheint, verschwindet, verbindet sich neu, wechselt den COM-Port, scheitert bei der Enumeration oder läuft ein paar Sekunden und resettet dann. Nutzer suchen nach "USB device keeps disconnecting", "USB reset loop", "USB device not recognized after reconnect" und "why does my USB device re-enumerate", weil die OS-Meldung selten erklärt, was tatsächlich passiert ist.

Die nützliche Evidence liegt unter der App-Layer. Sie müssen wissen, ob der Host den Port resettet hat, das Gerät nicht mehr geantwortet hat, der Deskriptor-Read fehlgeschlagen ist, das Power-Management das Gerät suspendiert hat, der Treiber einen Klassen-Request ausgegeben hat oder der Endpoint stalled.

Bus Scope ist für diesen USB-Troubleshooting-Stil gebaut. Statt USB als Black-Box zu behandeln, hilft es, die Control-Transfers, Deskriptor-Reads, Resets, Endpoint-Verhalten und das Timing rund um den Disconnect zu inspizieren.

Was "disconnecting" bedeuten kann

Der Ausdruck "USB disconnecting" kann mehrere unterschiedliche Fehler beschreiben:

• Physisches Lösen oder Kabel-Bewegung.
• Elektrisches Rauschen oder instabile Stromversorgung.
• Host-Controller-Port-Reset.
• Device-Firmware-Crash und Reboot.
• Fehlgeschlagene Enumeration nach Reset.
• Treiber-Unload und Reload.
• Selective Suspend oder Runtime Power Management.
• Endpoint-STALL gefolgt von Recovery-Fehler.
• Composite-Device-Interface-Fehler.
• High-Bandwidth-Transfer-Überlast.

Diese Fehler sehen in Desktop-Benachrichtigungen ähnlich aus, in der USB-Evidence aber unterschiedlich.

Enumeration-Reset-Loop

Ein Reset-Loop startet oft damit, dass der Host ein Gerät erkennt, den Port resettet, Deskriptoren liest, eine Adresse zuweist und dann scheitert, bevor die Konfiguration abschließt. Der Zyklus wiederholt sich.

Eine vereinfachte Sequenz sieht so aus:

Port reset
GET_DESCRIPTOR device
SET_ADDRESS
GET_DESCRIPTOR configuration
SET_CONFIGURATION
Disconnect
Port reset
GET_DESCRIPTOR device
...

Scheitert das Gerät vor SET_CONFIGURATION, liegt das Problem möglicherweise in Deskriptor-Inhalten, Firmware-Timing, Strom oder Host-Kompatibilität. Scheitert es nach SET_CONFIGURATION, kann das Problem Klassen-Initialisierung, Endpoint-Setup oder ein Treiber-Request sein.

Power-Probleme können wie Protokoll-Probleme aussehen

USB-Geräte können resetten, wenn die Spannung abfällt, die Stromaufnahme spikes oder ein Hub nicht genug Strom liefern kann. Das ist häufig bei:

• USB-Kameras
• USB-Capture-Karten
• Externen Laufwerken
• Dev-Boards
• Mobilfunk-Modems
• Geräten hinter passiven Hubs
• Langen oder minderwertigen Kabeln

Auf Paket-Ebene sieht ein Power-bezogener Reset wie plötzliche Stille aus, gefolgt von Re-Enumeration. Das Gerät beantwortet keine Requests mehr, der Host resettet den Port und die Enumeration startet erneut.

Bus Scope kann Spannung nicht direkt messen, aber es kann Timing und Sequenz rund um den Reset zeigen. War die letzte erfolgreiche Operation der Start eines bandbreitenintensiven Streams oder ein Motor-/Power-Mode-Kommando, deutet die Evidence auf Power- oder Firmware-Stress hin.

Selective Suspend und Runtime Power Management

Betriebssysteme können idle USB-Geräte suspendieren, um Strom zu sparen. Das ist normal, wenn Gerät und Treiber es korrekt unterstützen. Es wird zum Problem, wenn die Geräte-Firmware nicht sauber resumed oder wenn der Treiber ein Gerät suspendiert, von dem die App erwartet, dass es aktiv bleibt.

Symptome:

• Gerät läuft nach Anstecken, scheitert aber nach Idle-Zeit.
• Erster Request nach Idle gibt einen Fehler zurück.
• Gerät verschwindet nach Sleep oder Bildschirmsperre.
• Serial-Gerät ändert State nach Resume.
• HID-Gerät verpasst Input nach Wake.

Der USB-Trace kann zeigen, ob der Traffic vor dem Fehler stoppte und ob eine Resume/Reset-Sequenz passiert ist. Das ist nützlicher, als aus der App-Fehlermeldung zu raten.

Endpoint-STALL vor Disconnect

Manche Disconnect-Berichte sind eigentlich Endpoint-Level-Fehler. Das Gerät kann einen Bulk-Endpoint, Interrupt-Endpoint oder Control-Request stallen. Der Treiber versucht, den Stall zu clearen. Scheitert die Recovery, resettet der Treiber das Gerät oder die App schließt das Handle.

Achten Sie auf:

• STALL auf einem Control-Transfer.
• Wiederholt fehlgeschlagene Bulk-Transfers.
• CLEAR_FEATURE(ENDPOINT_HALT).
• Reset nach demselben Request jedes Mal.
• Timeout vor Disconnect.

Löst immer dasselbe Kommando den Reset aus, stürzt die Geräte-Firmware bei der Verarbeitung dieses Kommandos möglicherweise ab.

Composite-Device-Reset-Loops

Composite-USB-Geräte legen mehrere Interfaces unter einem Gerät offen. Zum Beispiel kann ein Gerät bereitstellen:

• CDC-Serial-Interface
• HID-Control-Interface
• Mass-Storage-Interface
• Herstellerspezifisches Diagnose-Interface

Das Gerät kann teilweise enumerieren und trotzdem scheitern, wenn sich ein Interface-Treiber attachiert. Nutzer sehen möglicherweise "USB device recognized" gefolgt von sofortigem Disconnect, weil ein Interface einen Firmware-Crash oder Treiber-Konflikt auslöst.

Im Trace prüfen Sie Interface-Deskriptoren, Alternate Settings, Endpoint-Deskriptoren und klassenspezifische Requests. Der Reset passiert möglicherweise erst, nachdem der Host ein bestimmtes Interface konfiguriert.

High-Bandwidth-Geräte

USB-Video, -Audio, -Capture- und Datenerfassungs-Geräte können unter Last disconnecten. Das Gerät kann korrekt enumerieren und einfache Control-Requests bestehen, dann aber scheitern, wenn Streaming startet.

Häufige Ursachen:

• Isochronous-Bandbreiten-Reservierungs-Fehler.
• Bulk-Endpoint-Timeout.
• Host-Controller-Bandbreiten-Druck.
• Hub-Bottleneck.
• USB 2.0 vs. USB 3.x Mode-Mismatch.
• Firmware-Buffer-Overflow.
• Treiber wählt nicht unterstütztes Alternate Setting.

Passiert der Disconnect nach einem Stream-Start-Request oder Alternate-Setting-Wechsel, inspizieren Sie den exakten Transfer direkt vor dem Reset. Das ist oft der wichtigste Hinweis.

Was zu capturen ist

Für einen wiederholbaren Disconnect capturen Sie ab vor dem Anstecken oder vor der scheiternden Aktion. Sie wollen die ganze Geschichte:

1. Device-Attach.
2. Port-Reset.
3. Deskriptor-Reads.
4. Adressvergabe.
5. Konfigurationsauswahl.
6. Interface-Treiber-Requests.
7. Erster normaler App-Transfer.
8. Letzter erfolgreicher Transfer vor dem Fehler.
9. Timeout, Stall, Reset oder Disconnect.
10. Re-Enumeration nach dem Fehler.

Capture zu starten, nachdem das Gerät bereits gescheitert ist, verpasst die wichtigste Evidence.

Debug-Checkliste

Nutzen Sie diese Reihenfolge:

1. Mit kurzem, bekannt-gutem Kabel reproduzieren.
2. Passive Hubs beim ersten Test vermeiden.
3. Enumeration ab Anstecken capturen.
4. Prüfen, ob der Fehler vor oder nach SET_CONFIGURATION passiert.
5. Den letzten erfolgreichen Request identifizieren.
6. Nach Stalls, Timeouts und wiederholten Resets suchen.
7. Idle-Fehler vs. Under-Load-Fehler vergleichen.
8. Anderen USB-Port oder Controller testen.
9. Selective Suspend erst deaktivieren, nachdem Evidence gesammelt ist.
10. Dasselbe Gerät auf einem anderen OS vergleichen, falls möglich.

Enddiagnose

"USB device keeps disconnecting" ist ein Symptom, keine Root-Cause. Der Fix hängt davon ab, ob die Evidence Power-Instabilität, Firmware-Reset, Deskriptor-Fehler, Treiber-Klassen-Request-Fehler, Endpoint-STALL, Suspend/Resume-Problem oder High-Bandwidth-Überlast zeigt.

Bus Scope hilft, indem es die USB-Transaktionen rund um den Fehler zeigt – so hören Sie auf, aus Desktop-Benachrichtigungen zu raten, und debuggen aus dem tatsächlichen Bus-Verhalten.