Depuração de serial USB CDC ACM: line coding, control line state e dados que não trafegam

Dispositivos USB CDC ACM são usados para portas seriais virtuais, consoles de dispositivo, ferramentas de firmware, telemetria, equipamentos de teste e diagnóstico embarcado. Do lado da aplicação, parecem simples: "abra uma porta COM ou /dev/ttyACM*, configure um baud rate, leia e escreva bytes. Por baixo, o host e o dispositivo continuam trocando requisições USB específicas de classe e transferências em massa." Quando um dispositivo CDC enumera, mas nenhum dado trafega, a captura pode mostrar se o problema está no layout dos descritores, no line coding, no control line state, no tráfego do endpoint ou no buffer do firmware.

CDC ACM tem interface de controle e interface de dados

Um dispositivo CDC ACM típico expõe uma interface de comunicação e uma interface de dados. O host pode enviar requisições específicas de classe antes de iniciar a transferência de dados.

Evidências importantes:

• descritor da interface de comunicação
• descritor da interface de dados
• descritores funcionais CDC
• endpoint de notificação
• endpoint bulk IN
• endpoint bulk OUT
• SET_LINE_CODING
• GET_LINE_CODING
• SET_CONTROL_LINE_STATE

Se essas requisições nunca chegam, talvez o host não tenha carregado o driver CDC esperado.

Baud rate normalmente é só um sinal, não uma UART física

Em muitos dispositivos USB CDC, o baud rate não tem o mesmo significado físico que em uma UART. Mesmo assim, o host envia o line coding. O firmware pode usá-lo para configurar uma ponte, ignorá-lo ou validá-lo.

Perguntas para responder na captura:

• o host enviou SET_LINE_CODING?
• qual baud rate, paridade, stop bits e data bits foram requisitados?
• o firmware aceitou a requisição?
• o host subiu DTR ou RTS via SET_CONTROL_LINE_STATE?
• o firmware espera DTR antes de transmitir?

Muitos problemas de "não sai nada na serial" são, na verdade, "o firmware espera DTR e o host nunca subiu", ou "a aplicação abriu a porta, mas não configurou como esperado".

Endpoints em massa comprovam o tráfego de dados

Depois do setup, os dados CDC normalmente trafegam em endpoints em massa. Se as escritas do host aparecem no bulk OUT, mas nenhuma resposta IN aparece, o firmware pode não estar enviando. Se os dados do bulk IN chegam, mas a aplicação não exibe, o problema pode estar no comportamento da aplicação no host.

Inspecione:

• direção do endpoint
• tamanhos das transferências
• comportamento de NAK ou timeout repetido
• bytes efetivos do payload
• status das transferências
• ordenação em relação às requisições de line state

É assim que uma captura USB vira mais útil que um screenshot de terminal.

Onde o Bus Scope entra

O Bus Scope ajuda a equipe de firmware a manter descritores, requisições de classe e dados brutos de endpoint em uma única sessão. Para a depuração de CDC ACM, ele deve responder:

• o host carregou o driver CDC?
• qual line coding foi enviado?
• DTR/RTS mudaram?
• o bulk OUT carregou comandos?
• o bulk IN carregou respostas?
• o problema aconteceu antes ou depois do tráfego estilo serial começar?

Para buscas como "USB CDC ACM no data", "virtual COM port no output" ou "SET_CONTROL_LINE_STATE DTR", a evidência não está no terminal. Está nas requisições de classe USB e nas transferências de endpoint.