USB CDC ACM DTR- und RTS-Debugging: SetControlLineState, Serial-Port-Öffnung, Bootloader-Reset und fehlende Daten

USB-CDC-ACM-Geräte wirken wie serielle Ports, aber viele "Serial-Port"-Bugs sind eigentlich USB-Klassen-Control-Bugs. Nutzer suchen nach "CDC ACM DTR RTS", "SetControlLineState USB", "USB serial no data until DTR", "Arduino resets when serial port opens", "USB CDC bootloader reset" und "COM port opens but device does not respond", wenn der Port existiert, das Verhalten aber falsch ist.

Bus Scope hilft, weil DTR und RTS keine magischen App-Flags sind. Der Host sendet klassenspezifische Control-Requests, und die Firmware reagiert auf diese Requests.

Was SetControlLineState tut

CDC ACM nutzt einen Klassen-Request, der üblicherweise SetControlLineState heißt. Er überträgt den Control-Line-State wie:

• DTR: Data Terminal Ready.
• RTS: Request To Send.

Viele Geräte nutzen diese Bits für mehr als klassisches Modem-Verhalten. Die Firmware startet das Streaming vielleicht erst, nachdem DTR asserted wurde, wechselt in den Bootloader, wenn DTR togglet, oder nutzt RTS für Flow-Control-Semantik.

Häufige Symptome

Control-Line-Probleme zeigen sich als:

• COM-Port öffnet, aber es kommen keine Daten.
• Gerät sendet erst, nachdem sich das Terminal-Programm verbindet.
• Firmware resettet, wenn sich ein Serial-Monitor öffnet.
• Bootloader erscheint nach Port-Open/Close.
• Daten stoppen, wenn DTR fällt.
• RTS/CTS-Flow-Control-Option verändert das Verhalten.
• Linux-Tool läuft, Windows-Tool nicht.
• Python-Skript verhält sich anders als Terminal-Emulator.

Diese Phrasen passen zu den Symptomen, die Engineers beim Reproduzieren des Fehlers beschreiben.

Verhalten beim Öffnen des Serial-Ports

Verschiedene Host-Apps setzen DTR und RTS unterschiedlich beim Öffnen eines Ports.

Beispiele:

• Terminal-Emulator asserted DTR sofort.
• Skript öffnet den Port, lässt DTR aber false.
• Firmware-Update-Tool togglet DTR als Reset-Signal.
• Treiber setzt RTS basierend auf Flow-Control-Settings.
• App schließt den Port und droppt DTR unerwartet.

Der Packet-Trace zeigt die tatsächliche Control-Request-Sequenz, statt sich auf App-Annahmen zu verlassen.

Bootloader-Reset-Patterns

Viele Dev-Boards nutzen DTR- oder RTS-Transitions, um in den Bootloader-Modus zu resetten. Das ist praktisch für Firmware-Upload, aber überraschend in Production-Tools.

Fehler-Patterns:

• Gerät resettet jedes Mal, wenn sich ein Log-Viewer öffnet.
• Firmware-Upload funktioniert, aber normale Serial-Verbindung schlägt fehl.
• Gerät erscheint als eine USB-Identität, resettet, re-enumeriert dann als Bootloader.
• Serial-Number oder Product-String ändert sich nach Reset.
• App verliert das Port-Handle.

Bus Scope sollte den Control-Request und die Re-Enumeration-Sequenz erhalten.

Keine Daten bis DTR

Manche Firmware wartet absichtlich auf DTR, bevor sie Daten sendet. Das kann ein Tool defekt wirken lassen, während ein anderes funktioniert.

Evidence:

• Host öffnet Bulk- oder Interrupt-Endpoints.
• Keine IN-Daten werden gesendet.
• Host sendet SetControlLineState mit DTR true.
• Gerät beginnt zu senden.

Das ist kein Kabel-Problem und nicht zwingend ein Treiber-Bug. Es ist Firmware-Policy.

RTS- und Flow-Control-Verwirrung

RTS kann für Hardware-Flow-Control genutzt werden, aber viele USB-CDC-Geräte haben keine echten Modem-Leitungen. Die Firmware legt RTS-State trotzdem gegenüber der App-Logik offen.

Fragen:

• Setzt der Host RTS?
• Braucht das Gerät RTS vor dem Senden?
• Verändert das Aktivieren von Hardware-Flow-Control im Terminal die Request-Bits?
• Ignoriert die Firmware RTS, obwohl die Doku etwas anderes sagt?
• Wird RTS als Bootloader- oder Mode-Select-Signal genutzt?

Packet-Evidence verhindert Rätselraten.

Debug-Checkliste

Nutzen Sie diesen Ablauf:

1. Enumeration capturen.
2. Den Serial-Port mit der fehlerhaften App öffnen.
3. CDC-klassenspezifische Requests aufzeichnen.
4. SetControlLineState finden.
5. DTR- und RTS-Bits dekodieren.
6. Mit einem funktionierenden Terminal-Programm vergleichen.
7. Prüfen, ob Daten nach DTR starten.
8. Prüfen, ob Reset oder Re-Enumeration auf ein Toggle folgt.
9. Windows- und Linux-Tools vergleichen.
10. Control-Requests und erste Daten-Pakete zusammen aufbewahren.

Enddiagnose

USB-CDC-ACM-DTR- und RTS-Probleme sind Klassen-Control-Sequencing-Probleme. Der Port kann existieren und Treiber korrekt binden, während die Firmware auf einen Control-Line-State wartet, den die App nie sendet.

Bus Scope zeigt SetControlLineState, DTR, RTS, Serial-Open-Verhalten, Bootloader-Resets und Missing-Data-Ursachen auf USB-Protokoll-Ebene.