Depuración serie USB CDC ACM: line coding, control line state y datos faltantes

Los dispositivos USB CDC ACM se usan para puertos serie virtuales, consolas de dispositivo, herramientas de firmware, telemetría, fixtures de test y diagnóstico embebido. Desde la aplicación parecen simples: "abres un COM o un /dev/ttyACM*, ajustas el baud rate, lees y escribes bytes. Por debajo, el host y el dispositivo siguen intercambiando class-specific requests USB y bulk transfers." Cuando un dispositivo CDC enumera pero no se mueven datos, la captura puede enseñar si el problema está en el layout de descriptores, el line coding, el control line state, el tráfico de endpoints o el buffering del firmware.

CDC ACM tiene interfaces de control y de datos

Un dispositivo CDC ACM típico expone una interfaz de comunicación y una interfaz de datos. El host puede enviar class-specific requests antes de que empiece la transferencia de datos.

Evidencia importante:

• Descriptor de la interfaz de comunicación.
• Descriptor de la interfaz de datos.
• Functional descriptors CDC.
• Notification endpoint.
• Endpoint bulk IN.
• Endpoint bulk OUT.
• SET_LINE_CODING.
• GET_LINE_CODING.
• SET_CONTROL_LINE_STATE.

Si esas peticiones no llegan, puede que el host no haya enlazado el driver CDC esperado.

El baud rate suele ser señal, no UART físico

En muchos dispositivos CDC USB, el baud rate no es físicamente significativo como lo sería en un UART. Pero el host sigue enviando line coding. El firmware puede usarlo para configurar un bridge, ignorarlo o validarlo.

Preguntas para la captura:

• ¿Mandó el host SET_LINE_CODING?
• ¿Qué baud rate, paridad, bits de stop y bits de datos se pidieron?
• ¿Aceptó el firmware la petición?
• ¿Puso el host DTR o RTS con SET_CONTROL_LINE_STATE?
• ¿Espera el firmware a DTR antes de transmitir?

Muchos problemas de "no sale nada por el serie" son en realidad "el firmware espera DTR y el host nunca lo ha asserted" o "la aplicación abrió el puerto pero no lo configuró como se esperaba".

Los endpoints bulk demuestran el movimiento de datos

Tras el setup, los datos CDC suelen moverse por endpoints bulk. Si las escrituras del host aparecen en bulk OUT pero no llega respuesta en bulk IN, puede que el firmware no esté enviando. Si llegan datos bulk IN pero la aplicación no los enseña, el problema puede estar en la propia aplicación.

Inspecciona:

• Dirección del endpoint.
• Longitudes de transferencia.
• Comportamiento repetido de NAK o timeout.
• Bytes reales del payload.
• Estado de las transferencias.
• Orden relativo a las peticiones de line state.

Así es como una captura USB resulta más útil que una captura de pantalla del terminal.

Dónde encaja Bus Scope

Bus Scope debería ayudar a los equipos de firmware a mantener descriptores, class requests y datos de endpoint en una sola sesión. Para depurar CDC ACM, debería responder:

• ¿El host enlazó CDC?
• ¿Qué line coding mandó?
• ¿Cambiaron DTR/RTS?
• ¿El bulk OUT llevó comandos?
• ¿El bulk IN llevó respuestas?
• ¿Pasó el fallo antes o después de empezar el tráfico estilo serie?

Para búsquedas como "USB CDC ACM no data", "virtual COM port no output" o "SET_CONTROL_LINE_STATE DTR", la evidencia no está solo en el terminal. Está en las class requests USB y las transferencias de endpoint.