Depuração de DTR e RTS em USB CDC ACM: SetControlLineState, abertura de porta, bootloader e dados faltando

Dispositivos USB CDC ACM parecem portas seriais, mas muitos bugs de "porta serial" são, na verdade, bugs de controle de classe USB. Quem busca por "CDC ACM DTR RTS", "SetControlLineState USB", "USB serial no data until DTR", "Arduino resets when serial port opens", "USB CDC bootloader reset" e "COM port opens but device does not respond" geralmente vê a porta existir, mas o comportamento estar errado.

O Bus Scope ajuda porque DTR e RTS não são flags mágicas da aplicação. O host envia requisições de controle específicas de classe, e o firmware reage a essas requisições.

O que o SetControlLineState faz

CDC ACM usa uma requisição de classe comumente chamada SetControlLineState. Ela comunica o estado das linhas de controle, como:

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

Muitos dispositivos usam esses bits para mais do que o comportamento tradicional de modem. O firmware pode começar a transmitir só depois que DTR é ativado, entrar em bootloader quando DTR alterna, ou usar RTS para semântica de controle de fluxo.

Sintomas comuns

Problemas com linhas de controle aparecem como:

• Porta COM abre, mas nenhum dado chega.
• Dispositivo só começa a transmitir depois que o terminal conecta.
• Firmware reseta quando um monitor serial abre.
• Bootloader aparece depois de abrir e fechar a porta.
• Dados param quando DTR cai.
• Opção de controle de fluxo RTS/CTS muda o comportamento.
• Ferramenta no Linux funciona, mas no Windows não.
• Script em Python se comporta diferente de um emulador de terminal.

Essas frases batem com os sintomas que engenheiros descrevem quando tentam reproduzir a falha.

Comportamento de abertura de porta serial

Diferentes aplicações no host tratam DTR e RTS de forma distinta ao abrir a porta.

Exemplos:

• Emulador de terminal sobe DTR imediatamente.
• Script abre a porta, mas deixa DTR em falso.
• Ferramenta de update de firmware alterna DTR como sinal de reset.
• Driver seta RTS com base nas configurações de controle de fluxo.
• Aplicação fecha a porta e derruba DTR de forma inesperada.

O trace de pacotes pode mostrar a sequência real de requisições de controle em vez de depender de suposições da aplicação.

Padrões de reset via bootloader

Muitas placas de desenvolvimento usam transições de DTR ou RTS para entrar em modo bootloader. Isso é prático para upload de firmware, mas pega gente de surpresa em ferramentas de produção.

Padrões de falha:

• Dispositivo reseta toda vez que um visualizador de logs abre.
• Upload de firmware funciona, mas conexão serial normal falha.
• Dispositivo aparece como uma identidade USB, reseta, e reenumera como bootloader.
• Número de série ou product string muda depois do reset.
• Aplicação perde o handle da porta.

O Bus Scope deve preservar a requisição de controle e a sequência de reenumeração.

Sem dados até DTR

Alguns firmware esperam de propósito DTR antes de transmitir. Isso pode fazer uma ferramenta parecer quebrada enquanto outra funciona.

Evidência:

• Host abre endpoints bulk ou interrupt.
• Nenhum dado IN é enviado.
• Host envia SetControlLineState com DTR true.
• Dispositivo começa a transmitir.

Isso não é problema de cabo e não é necessariamente bug de driver. É política do firmware.

Confusão entre RTS e controle de fluxo

RTS pode ser usado para controle de fluxo por hardware, mas muitos dispositivos USB CDC não têm linhas reais de modem. O firmware ainda pode expor o estado de RTS para a lógica da aplicação.

Perguntas:

• O host seta RTS?
• O dispositivo exige RTS antes de transmitir?
• Habilitar controle de fluxo por hardware no terminal muda os bits da requisição?
• O firmware ignora RTS, mas a documentação diz o contrário?
• RTS é usado como bootloader ou sinal de seleção de modo?

Evidência de pacotes evita achismo.

Checklist de depuração

Use este processo:

1. Capture a enumeração.
2. Abra a porta serial com a aplicação que falha.
3. Registre as requisições CDC específicas de classe.
4. Encontre o SetControlLineState.
5. Decodifique os bits DTR e RTS.
6. Compare com um programa de terminal que funciona.
7. Confira se os dados começam depois de DTR.
8. Confira se há reset ou reenumeração depois de um toggle.
9. Compare ferramentas no Windows e no Linux.
10. Preserve as requisições de controle e os primeiros pacotes de dados juntos.

Diagnóstico final

Problemas de DTR e RTS em USB CDC ACM são problemas de sequenciamento de controle de classe. A porta pode existir e os drivers podem vincular corretamente enquanto o firmware espera um estado de linha de controle que a aplicação nunca envia.

O Bus Scope ajuda a mostrar SetControlLineState, DTR, RTS, comportamento de abertura de porta, resets de bootloader e causas de dados ausentes no nível de protocolo USB.