USB-Device-Qualifier- und Other-Speed-Configuration-Debugging

USB-Geräte, die sowohl Full-Speed als auch High-Speed unterstützen, müssen beschreiben, wie sie sich bei der anderen Speed verhalten. Nutzer suchen nach "USB Device Qualifier descriptor", "Other Speed Configuration descriptor", "high speed device enumerates as full speed", "USB descriptor mismatch" und "device works on USB 2.0 but fails on hub", wenn dasselbe Produkt je nach Port, Kabel, Hub oder Host-Controller unterschiedlich arbeitet.

Bus Scope hilft, weil die Diagnose Deskriptor-Requests, tatsächliche Speed, Endpoint-Paketgrößen, Configuration-Deskriptoren und Host-Entscheidungen während der Enumeration vergleichen muss.

Was der Device-Qualifier-Deskriptor ist

Der Device-Qualifier-Deskriptor beschreibt, wie ein High-Speed-fähiges Gerät bei der anderen Speed arbeiten würde. Ist das Gerät aktuell High-Speed, sagt der Qualifier dem Host etwas über Full-Speed-Verhalten. Ist es aktuell Full-Speed, kann es High-Speed-Capability beschreiben.

Wichtige Felder:

• USB-Version.
• Device-Class.
• Subclass.
• Protocol.
• Endpoint-Null-Max-Packet-Size.
• Anzahl der Konfigurationen.

Fehlt dieser Deskriptor, ist er fehlerhaft oder inkonsistent, kann die Enumeration auf einem Host trotzdem gelingen und auf einem anderen scheitern.

Other Speed Configuration

Der Other-Speed-Configuration-Deskriptor beschreibt Konfigurations-Details bei der anderen Speed. Endpoint-Paketgrößen, Polling-Intervalle und Bandbreiten-Annahmen können abweichen.

Häufige Fehler-Patterns:

• Full-Speed-Konfiguration wirbt mit Endpoint-Größen, die nur bei High-Speed Sinn ergeben.
• High-Speed-Konfiguration vergisst ein Interface.
• Other-Speed-Deskriptor-Anzahl passt nicht zur echten Konfiguration.
• Firmware gibt einen STALL zurück, wenn der Host einen Deskriptor erwartet.
• Host akzeptiert das Gerät, bindet aber den falschen Treiber.
• Gerät läuft durch einen Hub, scheitert aber durch einen anderen.

Diese Probleme sind in App-Logs schwer zu sehen.

High-Speed-Gerät enumeriert als Full-Speed

Ein häufiger Support-Fall ist "USB high-speed device detected as full-speed". Das kann durch Kabel-Qualität, Hub-Topologie, Signal-Integrität, Firmware-Chirp-Verhalten, elektrisches Design oder Deskriptor-Probleme verursacht werden.

Paket-Evidence hilft, Schichten zu trennen:

• Hat die High-Speed-Negotiation stattgefunden?
• Hat der Host nach Device-Qualifier gefragt?
• Hat das Gerät gültige Deskriptor-Bytes zurückgegeben?
• Haben die Endpoint-Deskriptoren zur gewählten Speed gepasst?
• Hat der Host resettet und retried?
• Hat das Gerät später bei einer anderen Speed re-enumeriert?

Zeigt der Trace, dass das Gerät nie High-Speed erreicht hat, reichen Deskriptor-Fixes möglicherweise nicht. Zeigt der Trace High-Speed-Enumeration aber invalide Other-Speed-Deskriptoren, ist die Firmware ein stärkerer Verdächtiger.

Endpoint-Paketgrößen-Mismatch über Speeds

Endpoint-Deskriptoren können sich zwischen Full-Speed- und High-Speed-Konfigurationen unterscheiden. Ein Bulk-Endpoint kann 64 Bytes bei Full-Speed und 512 Bytes bei High-Speed sein.

Fehler-Symptome:

• Transfers scheitern nur an High-Speed-Ports.
• Transfers scheitern nur durch älteren Full-Speed-Hub.
• Firmware-Buffer-Größe passt zu einer Speed, Deskriptor wirbt mit anderer.
• Host-Treiber sendet größere Transfers als die Firmware erwartet.
• Gerät gibt Short-Pakete an unerwarteten Grenzen zurück.

Das hängt direkt mit wMaxPacketSize-Debugging zusammen.

Composite-Devices

Composite-Devices machen Other-Speed-Deskriptoren fragiler. Ein Gerät kann HID, CDC, herstellerspezifische, Mass-Storage- und Firmware-Update-Interfaces exponieren. Der Other-Speed-Baum muss konsistent bleiben.

Bugs:

• Fehlender Interface-Association-Deskriptor bei einer Speed.
• Unterschiedliche Interface-Nummern über Speeds hinweg.
• Endpoint-Adressen ändern sich unerwartet.
• Ein Interface hat einen validen Other-Speed-Deskriptor, ein anderer nicht.
• Windows bindet anderen Treiber nach Re-Enumeration.

Für Produkte mit Custom-Firmware ist das ein häufiger Copy-Paste-Fehler.

STALL kann valide oder verdächtig sein

Manche Deskriptor-Requests dürfen legitim STALLen, wenn das Gerät die angefragte Capability nicht unterstützt. Aber für High-Speed-fähige Geräte verdienen wiederholte Fehler rund um Device-Qualifier oder Other-Speed-Configuration Aufmerksamkeit.

Der Report sollte erhalten:

• Request-Typ.
• Deskriptor-Typ.
• wValue.
• wIndex.
• wLength.
• Zurückgegebene Daten.
• STALL- oder Timeout-Status.

Bus Scope sollte diese Control-Transfers lesbar machen, statt Engineers zu zwingen, Rohbytes manuell zu dekodieren.

Debug-Checkliste

Nutzen Sie diesen Workflow:

1. Ab physischem Anstecken capturen.
2. Tatsächliche verhandelte Speed aufzeichnen.
3. Device-Deskriptor inspizieren.
4. Device-Qualifier-Deskriptor inspizieren.
5. Other-Speed-Configuration-Deskriptor inspizieren.
6. Endpoint-Paketgrößen über Speeds vergleichen.
7. Interface-Nummern und Endpoint-Adressen prüfen.
8. Direkten Port, Hub und USB-C-Dock-Pfade testen.
9. Windows- und Linux-Enumeration-Verhalten vergleichen.
10. Deskriptor-Request-Fehler und Retries bewahren.

Enddiagnose

USB-Device-Qualifier- und Other-Speed-Configuration-Bugs sind Deskriptor-Konsistenz-Probleme. Sie erklären, warum ein Gerät bei einer Speed läuft, bei einer anderen scheitert oder sich hinter Hubs und Docks unterschiedlich verhält.

Bus Scope hilft, die exakte Enumeration-Evidence zu capturen: Deskriptor-Requests, Other-Speed-Bytes, Endpoint-Größen, STALLs, Resets und Treiberbindungs-Konsequenzen.