Desaparición del puerto COM serie USB: depurando re-enumeración, binding de driver, números de puerto y bridges CDC

Los dispositivos serie USB están en todos lados: "placas Arduino, controladores industriales, modems, receptores GPS, fixtures de test, sondas de debug, herramientas de PLC, dispositivos de códigos de barras y firmware CDC ACM a medida. Cuando el puerto COM desaparece, los usuarios buscan "USB serial COM port disappears", "COM port missing Device Manager", "USB serial re-enumerates", "CDC ACM device disconnects" y "COM port changes after reconnect" porque la aplicación suele decir solo que no puede abrir el puerto." Bus Scope ayuda porque un puerto COM desaparecido puede venir de capas muy distintas: "enumeración USB, problemas de descriptor, binding de driver, reset del dispositivo, handle obsoleto de la aplicación, fallo en line coding o asignación de un nuevo número COM por Windows."

El COM no es el dispositivo USB

El COM es una abstracción del sistema operativo creada tras la enumeración del dispositivo USB y el binding del driver serie. Si el dispositivo USB nunca enumera, no puede aparecer un COM. Si el dispositivo enumera pero la interfaz CDC falla, el COM puede seguir faltando.

Separa las capas:

• ¿Se conectó el dispositivo USB?
• ¿Se leyeron los descriptores correctamente?
• ¿Terminó la configuración?
• ¿Aparecieron las interfaces CDC?
• ¿Se enlazó el driver?
• ¿Asignó el SO un número COM?
• ¿Abrió la aplicación el puerto correcto y actual?

La re-enumeración cambia los números de puerto

Windows puede asignar un nuevo número COM cuando aparece un dispositivo con un número de serie distinto, otro USB path, otro VID/PID o una identidad de interfaz distinta. Un dispositivo que resetea al modo bootloader puede exponer otro COM o ninguno.

Síntomas:

• El dispositivo era COM8, ahora es COM11.
• La aplicación recuerda el COM antiguo.
• Enchufarlo en otro puerto USB cambia la asignación.
• El bootloader usa otro puerto.
• El dispositivo aparece como desconocido tras actualizar el firmware.

La traza del bus identifica si cambió la identidad del dispositivo.

Class requests de CDC ACM

Los dispositivos serie CDC suelen recibir class requests:

• SET_LINE_CODING
• GET_LINE_CODING
• SET_CONTROL_LINE_STATE
• SEND_BREAK

Si el firmware las stall o maneja mal, el puerto puede abrirse pero los datos no fluyen, o el binding de driver puede fallar.

Captura el comportamiento al abrir el puerto, no solo al enchufar. Muchos fallos pasan cuando la aplicación abre el COM y el driver manda cambios de line coding o de estado DTR/RTS.

Handles obsoletos de la aplicación

A veces el USB reenumera bien, pero la aplicación mantiene un handle antiguo o un caché de COM. El bus muestra que el dispositivo nuevo está. La aplicación falla porque no soltó o refrescó el puerto.

No es un fallo del bus USB. Es comportamiento de gestión de dispositivo o aplicación.

Checklist de depuración

Usa este flujo:

1. Captura desde el plug-in.
2. Confirma el device descriptor y el configuration descriptor.
3. Inspecciona los descriptores de interfaz CDC.
4. Captura la apertura del COM por parte de la aplicación.
5. Inspecciona las class requests CDC.
6. Comprueba si hay reset o desconexión tras el line coding.
7. Compara la identidad del dispositivo antes y después de reconectar.
8. Mira si cambió el número COM.
9. Comprueba si la aplicación usa un nombre de puerto obsoleto.
10. Conserva juntos la evidencia USB y las notas de asignación de puerto del SO.

Diagnóstico final

Un COM serie USB que desaparece puede ser fallo de enumeración, fallo de descriptor CDC, fallo de binding de driver, re-enumeración con una identidad nueva, fallo en line coding, reset bajo carga o estado obsoleto de la aplicación.

Bus Scope ayuda enseñando el lado USB de la historia para que los síntomas de COM se puedan atar a attach, descriptores, requests CDC, resets e identidad real del dispositivo.