USB CDC ACM Serial Debugging: Line Coding, Control Line State und fehlende Daten

USB-CDC-ACM-Geräte werden für virtuelle serielle Ports, Device-Konsolen, Firmware-Tools, Telemetrie, Test-Fixtures und Embedded-Diagnose genutzt. Aus App-Sicht wirken sie einfach: "COM-Port oder /dev/ttyACM* öffnen, Baudrate setzen, Bytes lesen und schreiben. Darunter tauschen Host und Device aber weiterhin klassenspezifische USB-Requests und Bulk-Transfers aus." Wenn ein CDC-Gerät enumeriert, aber keine Daten fließen, kann der Capture zeigen, ob das Problem Deskriptor-Layout, Line Coding, Control Line State, Endpoint-Traffic oder Firmware-Buffering ist.

CDC ACM hat Control- und Data-Interfaces

Ein typisches CDC-ACM-Gerät legt ein Communication-Interface und ein Data-Interface offen. Der Host kann klassenspezifische Requests senden, bevor der Datentransfer beginnt.

Wichtige Evidence:

• Communication-Interface-Deskriptor
• Data-Interface-Deskriptor
• CDC Functional-Deskriptoren
• Notification-Endpoint
• Bulk-IN-Endpoint
• Bulk-OUT-Endpoint
• SET_LINE_CODING
• GET_LINE_CODING
• SET_CONTROL_LINE_STATE

Wenn diese Requests nie ankommen, hat der Host möglicherweise nicht den erwarteten CDC-Treiber gebunden.

Baudrate ist oft ein Signal, kein physischer UART

Für viele USB-CDC-Geräte ist die Baudrate nicht physisch relevant in der Weise, wie sie es für einen UART ist. Der Host sendet aber trotzdem Line Coding. Die Firmware kann sie nutzen, um eine Bridge zu konfigurieren, sie ignorieren oder validieren.

Capture-Fragen:

• Hat der Host SET_LINE_CODING gesendet?
• Welche Baudrate, Parity, Stop-Bits und Data-Bits wurden angefragt?
• Hat die Firmware den Request akzeptiert?
• Hat der Host mit SET_CONTROL_LINE_STATE DTR oder RTS gesetzt?
• Wartet die Firmware vor dem Senden auf DTR?

Viele "no serial output"-Probleme sind eigentlich "Firmware wartet auf DTR und der Host hat es nie asserted" oder "App hat den Port geöffnet, aber ihn nicht wie erwartet konfiguriert".

Bulk-Endpoints beweisen Datenfluss

Nach dem Setup fließt CDC-Datenverkehr normalerweise über Bulk-Endpoints. Sehen Writes vom Host auf Bulk-OUT, aber keine Bulk-IN-Antwort, sendet die Firmware möglicherweise nicht. Erscheinen Bulk-IN-Daten, aber die App zeigt sie nicht, liegt es möglicherweise am Verhalten der Host-App.

Prüfen Sie:

• Endpoint-Richtung
• Transfer-Längen
• wiederholtes NAK/Timeout-Verhalten
• tatsächliche Payload-Bytes
• Status der Transfers
• Reihenfolge relativ zu Line-State-Requests

So wird ein USB-Capture nützlicher als ein Terminal-Screenshot.

Wo Bus Scope passt

Bus Scope hilft Firmware-Teams, Deskriptoren, Klassen-Requests und rohe Endpoint-Daten in einer Session zu halten. Für CDC-ACM-Debugging beantwortet es:

• Hat der Host CDC gebunden?
• Welches Line Coding hat er gesendet?
• Hat sich DTR/RTS verändert?
• Hat Bulk-OUT Kommandos getragen?
• Hat Bulk-IN Antworten getragen?
• Ist das Problem vor oder nach dem serial-artigen Traffic aufgetreten?

Für Suchen wie "USB CDC ACM no data", "virtual COM port no output" oder "SET_CONTROL_LINE_STATE DTR" liegt die Evidence nicht allein im Terminal. Sie liegt in den USB-Klassen-Requests und Endpoint-Transfers.