2026-06-03

Depuración USB CDC ACM DTR y RTS: SetControlLineState, apertura de puerto serie, reset de bootloader y datos faltantes

Cómo depurar el estado de líneas DTR y RTS en USB CDC ACM, peticiones SetControlLineState, comportamiento al abrir el puerto serie, triggers de reset al bootloader y datos serie que no llegan.

Los dispositivos USB CDC ACM parecen puertos serie, pero muchos bugs de "puerto serie" son en realidad bugs de control de clase USB. Los usuarios buscan "CDC ACM DTR RTS", "SetControlLineState USB", "USB serial no data until DTR", "Arduino resets when serial port opens", "USB CDC bootloader reset" y "COM port opens but device does not respond" cuando el puerto existe pero el comportamiento es incorrecto.

Bus Scope ayuda porque DTR y RTS no son flags mágicas de aplicación. El host envía peticiones de control class-specific y el firmware reacciona a esas peticiones.

Qué hace SetControlLineState

CDC ACM usa una class request conocida como SetControlLineState. Comunica el estado de líneas de control como:

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

Muchos dispositivos usan estos bits para más cosas que el comportamiento clásico de módem. El firmware puede empezar a transmitir solo tras DTR asserted, entrar en bootloader cuando DTR conmuta, o usar RTS como semántica de control de flujo.

Síntomas habituales

Los problemas de líneas de control aparecen como:

El puerto COM se abre pero no llega ningún dato.
El dispositivo empieza a enviar solo cuando se conecta el programa terminal.
El firmware se resetea cuando se abre el monitor serie.
Aparece el bootloader tras abrir/cerrar el puerto.
Los datos se cortan cuando cae DTR.
Cambiar la opción RTS/CTS cambia el comportamiento.
La herramienta de Linux funciona pero la de Windows no.
Un script en Python se comporta distinto al emulador de terminal.

Estas frases encajan con los síntomas que describen los ingenieros cuando intentan reproducir el fallo.

Comportamiento al abrir el puerto serie

Cada aplicación del host configura DTR y RTS a su manera al abrir el puerto.

Ejemplos:

El emulador de terminal pone DTR inmediatamente.
Un script abre el puerto pero deja DTR en false.
La herramienta de actualización de firmware conmuta DTR como señal de reset.
El driver pone RTS según los ajustes de control de flujo.
La aplicación cierra el puerto y DTR cae de forma inesperada.

La traza de paquetes puede enseñar la secuencia real de peticiones de control, en lugar de depender de lo que asume la aplicación.

Patrones de reset al bootloader

Muchas placas de desarrollo usan transiciones de DTR o RTS para resetear y entrar al bootloader. Es cómodo para subir firmware, pero sorprende en herramientas de producción.

Patrones de fallo:

El dispositivo se resetea cada vez que se abre un visor de logs.
La subida de firmware va, pero la conexión serie normal falla.
El dispositivo aparece como una identidad USB, se resetea y reenumera como bootloader.
El número de serie o el string de producto cambia tras el reset.
La aplicación pierde el handle del puerto.

Bus Scope debería conservar la petición de control y la secuencia de re-enumeración.

No hay datos hasta DTR

Algunos firmware esperan a DTR a propósito antes de enviar datos. Eso puede hacer que una herramienta parezca rota mientras otra va bien.

Evidencia:

El host abre endpoints bulk o interrupt.
No se mandan datos IN.
El host envía SetControlLineState con DTR true.
El dispositivo empieza a transmitir.

Esto no es un problema de cable ni necesariamente un bug de driver. Es política del firmware.

Confusión con RTS y el control de flujo

RTS se puede usar para control de flujo hardware, pero muchos dispositivos CDC USB no tienen líneas de módem reales. El firmware puede exponer igualmente el estado de RTS a la lógica de la aplicación.

Preguntas:

¿El host pone RTS?
¿El dispositivo requiere RTS antes de transmitir?
¿Activar el control de flujo hardware en el terminal cambia los bits de la petición?
¿El firmware ignora RTS aunque la documentación diga lo contrario?
¿Se usa RTS como bootloader o como señal de selección de modo?

La evidencia de paquetes evita tener que adivinar.

Checklist de depuración

Usa este proceso:

Captura la enumeración.
Abre el puerto serie con la app que falla.
Apunta las class-specific requests CDC.
Encuentra SetControlLineState.
Decodifica los bits DTR y RTS.
Compara con un programa terminal que sí funcione.
Mira si los datos empiezan tras DTR.
Mira si hay reset o re-enumeración tras una conmutación.
Compara herramientas Windows y Linux.
Conserva juntas las peticiones de control y los primeros paquetes de datos.

Diagnóstico final

Los problemas de DTR y RTS en USB CDC ACM son problemas de secuenciación de control de clase. El puerto puede existir y los drivers pueden enlazar correctamente mientras el firmware espera un estado de línea de control que la aplicación nunca envía.

Bus Scope ayuda a enseñar SetControlLineState, DTR, RTS, el comportamiento al abrir el puerto, los resets al bootloader y las causas de datos faltantes a nivel de protocolo USB.

Prueba del contrato USB para «Depuración USB CDC ACM DTR y RTS: SetControlLineState, apertura de puerto serie, reset de bootloader y datos faltantes»

La respuesta directa es que STALL, timeout o reset no explica por sí solo la causa. Primero demuestra que el proveedor observa el dispositivo correcto; después lee el contrato de transferencia: tipo, dirección, recipient, wValue, wIndex, longitud declarada y real, status y estado anterior y posterior. En «Depuración USB CDC ACM DTR y RTS: SetControlLineState, apertura de puerto serie, reset de bootloader y datos faltantes», relaciona la conclusión con la primera transacción que difiere de un caso bueno.

Límite	Qué comparar	Decisión útil
Plataforma	proveedor, permiso, Root Hub o usbmon/XHC20	¿Llegan records de la conexión correcta?
Setup	bmRequestType, bRequest, wValue, wIndex, wLength	¿El host envía la petición prevista?
Data	dirección, longitud y bytes retenidos	¿El payload cumple el contrato?
Status	ACK, STALL, timeout o cancellation	¿Dónde termina la transacción?
Estado	configuration, interface, alternate setting, endpoint halt	¿El dispositivo estaba preparado?

Empieza antes de reset y enumeración y conserva descriptors, SET_CONFIGURATION, SET_INTERFACE y el comando previo al fallo. Un filtro estrecho de endpoint puede ocultar el control transfer decisivo. Ejecuta una sola acción USB documentada por prueba y cambia solo firmware, driver, puerto, cable, comando o timing.

¿Cómo se escribe una respuesta citable?

Indica la petición observada, sus campos setup, la respuesta y el contexto anterior; propone después una prueba con un solo cambio. Bytes no retenidos por el límite de captura no prueban packet loss. La proximidad entre command y reset demuestra correlación, no causa sin repetición o transición de estado.

¿Cuándo vale una comparación?

Mantén VID/PID, firmware, speed, topología, proveedor, filtro y trigger. Compara fases USB semánticas y no frame numbers entre usbmon y USBPcap. Anota inicio, final, versión, OS, conexión y checksum. Revisa la solución de problemas de Bus Scope.

Los propietarios Semrush siguen separados: free USB analyzer en la página de producto, best USB protocol analyzer en la comparación y USB descriptor viewer en la guía de descriptors. Esta página de soporte no recibe volumen o KD inventado.

Respuesta directa y límite de aceptación

La respuesta breve a «Depuración USB CDC ACM DTR y RTS: SetControlLineState, apertura de puerto serie, reset de bootloader y datos faltantes» es: Cómo depurar el estado de líneas DTR y RTS en USB CDC ACM, peticiones SetControlLineState, comportamiento al abrir el puerto serie, triggers de reset al bootloader y datos serie que no llegan. Trate esa frase como un resultado que debe comprobarse, no como una promesa para cualquier entrada, dispositivo, proyecto o entorno. Un resultado completo registra estado inicial, acción exacta, salida visible y condición que demuestra que la tarea terminó en Bus Scope.

Procedimiento basado en evidencia

Empiece con un caso pequeño y repetible antes de cambiar un proyecto completo. Anote versión de la aplicación, sistema operativo, identidad de entrada o dispositivo, ajustes relevantes y resultado esperado. Ejecute una acción deliberada, conserve la primera transición inesperada y compárela con un caso conocido cuando exista. Cambiar varios controles a la vez oculta qué condición creó o corrigió el problema.

Punto de control 1: Depuración USB CDC ACM DTR y RTS: SetControlLineState, apertura de puerto serie, reset de

Cierre «Depuración USB CDC ACM DTR y RTS: SetControlLineState, apertura de puerto serie, reset de bootloader y datos faltantes» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 2: Cómo depurar el estado de líneas DTR y RTS en USB CDC ACM, peticiones SetControlLineState,

Para «Cómo depurar el estado de líneas DTR y RTS en USB CDC ACM, peticiones SetControlLineState, comportamiento al abrir el puerto serie, triggers de reset », separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 3: Qué hace SetControlLineState

Cierre «Qué hace SetControlLineState» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 4: Síntomas habituales

Para «Síntomas habituales», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 5: Comportamiento al abrir el puerto serie

Cierre «Comportamiento al abrir el puerto serie» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 6: Patrones de reset al bootloader

Para «Patrones de reset al bootloader», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 7: No hay datos hasta DTR

Cierre «No hay datos hasta DTR» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 8: Confusión con RTS y el control de flujo

Para «Confusión con RTS y el control de flujo», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 9: Checklist de depuración

Cierre «Checklist de depuración» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 10: Diagnóstico final

Para «Diagnóstico final», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Depuración USB CDC ACM DTR y RTS: SetControlLineState, apertura de puerto serie, reset de bootloader y datos faltantes	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo depurar el estado de líneas DTR y RTS en USB CDC ACM, peticiones SetControlLineState, comportamiento al abrir el pu	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Qué hace SetControlLineState	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Síntomas habituales	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Comportamiento al abrir el puerto serie	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Patrones de reset al bootloader	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado

Aislamiento, recuperación y entrega

Deténgase en el primer límite que falla. Conserve fuente, proyecto, sesión o captura, duplíquelo antes de una edición destructiva y cambie una variable por experimento. Repetir un flujo amplio después de varios cambios puede dar otro resultado sin explicar la causa.

Separe ausencia de evidencia de evidencia de ausencia. Una vista vacía puede indicar entrada, alcance, filtro, permiso, dispositivo, intervalo o estado equivocado. Verifique adquisición o importación antes de interpretar el decoder, editor, informe o exportación.

Antes de entregar, reabra el artefacto y revise inicio, punto de decisión y final. Registre versión, plataforma, configuración, expectativa, observación y reproducción mínima. Elimine o redacte datos sensibles y confirme que el destinatario está autorizado.

Preguntas y respuestas

¿Cuál es la forma fiable más rápida de empezar?

Use el caso representativo más pequeño, escriba el resultado esperado y cambie una variable. Confirme el recorrido básico antes de añadir filtros, efectos, ediciones, automatización o una fuente mayor.

¿Qué evidencia debe guardarse?

Conserve identidad de entrada, versión, plataforma, ajustes, acción exacta, primera transición inesperada y salida final. Cierre y reabra cualquier proyecto, sesión, informe o exportación antes de considerarlo duradero.

¿Cuándo debe repetirse el procedimiento?

Repítalo después de cambios relevantes en aplicación, sistema, driver, firmware, modelo, fuente o flujo. Preserve el caso aceptado anterior como referencia sin modificar.

¿Cuándo está listo para entregar?

Cuando otra persona autorizada identifica la entrada, repite la acción, obtiene el mismo resultado, entiende los límites restantes y abre el artefacto sin depender de estado local no documentado.

Guías relacionadas

Estas páginas en el mismo idioma cubren etapas contiguas sin cambiar el propietario canónico del tema: