El dispositivo USB se sigue desconectando: depurando bucles de reset, eventos de power y fallos de enumeración

Un dispositivo USB que se desconecta una y otra vez es uno de los problemas más frustrantes a nivel de hardware, porque el síntoma es ruidoso e inconsistente. El dispositivo aparece, desaparece, se reconecta, cambia de COM, falla al enumerar o funciona unos segundos y luego se resetea. Los usuarios buscan "USB device keeps disconnecting", "USB reset loop", "USB device not recognized after reconnect" y "why does my USB device re-enumerate" porque el mensaje del sistema operativo rara vez explica qué pasó de verdad.

La evidencia útil está por debajo de la capa de aplicación. Necesitas saber si el host reseteó el puerto, si el dispositivo dejó de responder, si la lectura de descriptor falló, si el power management suspendió el dispositivo, si el driver lanzó una class request o si el endpoint hizo STALL.

Bus Scope está pensado para ese estilo de troubleshooting USB. En vez de tratar el USB como una caja negra, ayuda a inspeccionar las transferencias de control, las lecturas de descriptor, los resets, el comportamiento de endpoint y el timing alrededor de la desconexión.

Qué puede significar "desconectarse"

La frase "USB disconnecting" puede describir varios fallos distintos:

• Desconexión física o movimiento del cable.
• Ruido eléctrico o mala estabilidad de alimentación.
• Reset de puerto del host controller.
• Crash y reboot del firmware del dispositivo.
• Enumeración fallida tras un reset.
• Descarga y recarga del driver.
• Selective suspend o runtime power management.
• STALL de endpoint seguido de fallo de recuperación.
• Fallo de interfaz en dispositivo compuesto.
• Sobrecarga de transferencia de alto ancho de banda.

Esos fallos se parecen en una notificación del escritorio, pero se ven distintos en la evidencia USB.

Bucle de reset en enumeración

Un bucle de reset suele empezar con el host detectando un dispositivo, reseteando el puerto, leyendo descriptores, asignando una dirección y fallando antes de que la configuración termine. El ciclo se repite.

Una secuencia simplificada:

Port reset
GET_DESCRIPTOR device
SET_ADDRESS
GET_DESCRIPTOR configuration
SET_CONFIGURATION
Disconnect
Port reset
GET_DESCRIPTOR device
...

Si el dispositivo falla antes de SET_CONFIGURATION, el problema puede estar en el contenido del descriptor, el timing del firmware, el power o la compatibilidad con el host. Si falla después de SET_CONFIGURATION, el problema puede estar en la inicialización de clase, el setup de endpoint o una petición de driver.

Los problemas de power pueden parecer problemas de protocolo

Los dispositivos USB pueden resetearse cuando cae la tensión, hay picos de consumo de corriente o un hub no puede entregar suficiente potencia. Es habitual con:

• Cámaras USB.
• Tarjetas de captura USB.
• Discos externos.
• Placas de desarrollo.
• Módems celulares.
• Dispositivos conectados a través de hubs pasivos.
• Cables largos o de baja calidad.

A nivel de paquete, un reset por power puede parecer silencio súbito seguido de re-enumeración. El dispositivo deja de responder, el host resetea el puerto y la enumeración empieza de nuevo.

Bus Scope no mide tensión directamente, pero puede enseñar el timing y la secuencia alrededor del reset. Si la última operación correcta fue el inicio de un stream con mucho ancho de banda o un comando de modo motor/power, la evidencia apunta a power o a estrés del firmware.

Selective suspend y runtime power management

El sistema operativo puede suspender dispositivos USB inactivos para ahorrar energía. Es normal cuando el dispositivo y el driver lo soportan correctamente. Se vuelve problema cuando el firmware del dispositivo no se reanuda limpio o cuando el driver suspende un dispositivo que la aplicación espera que siga activo.

Síntomas:

• El dispositivo funciona tras enchufarlo pero falla tras un tiempo inactivo.
• La primera petición tras inactividad devuelve un error.
• El dispositivo desaparece tras sleep o bloqueo de pantalla.
• El dispositivo serie cambia de estado tras el resume.
• El dispositivo HID pierde inputs tras el wake.

La traza USB puede enseñar si el tráfico se paró antes del fallo y si hubo una secuencia de resume o reset. Eso es más útil que adivinar a partir del mensaje de error de la aplicación.

STALL de endpoint antes de la desconexión

Algunos informes de desconexión son realmente fallos a nivel de endpoint. El dispositivo puede hacer STALL en un endpoint bulk, en un endpoint interrupt o en una petición de control. El driver intenta limpiar el stall. Si la recuperación falla, el driver resetea el dispositivo o la aplicación cierra el handle.

Busca:

• STALL en una transferencia de control.
• Bulk transfers fallidos repetidos.
• CLEAR_FEATURE(ENDPOINT_HALT).
• Un reset después de la misma petición cada vez.
• Un timeout antes de la desconexión.

Si el mismo comando dispara el reset siempre, puede que el firmware del dispositivo esté cayendo mientras procesa ese comando.

Bucles de reset en dispositivos compuestos

Los dispositivos compuestos exponen varias interfaces bajo un mismo dispositivo. Por ejemplo, un dispositivo puede ofrecer:

• Interfaz CDC serie.
• Interfaz HID de control.
• Interfaz mass storage.
• Interfaz vendor-specific de diagnóstico.

El dispositivo puede enumerar parcialmente y aun así fallar cuando se conecta un driver de una interfaz. Los usuarios pueden ver "USB device recognized" seguido de una desconexión inmediata porque una interfaz dispara un crash de firmware o un conflicto de driver.

En una traza, inspecciona los interface descriptors, los alternate settings, los endpoint descriptors y las class-specific requests. El reset puede pasar solo después de que el host empiece a configurar una interfaz concreta.

Dispositivos de alto ancho de banda

Dispositivos de vídeo, audio, captura y adquisición de datos USB pueden desconectarse bajo carga. El dispositivo puede enumerar correctamente y pasar peticiones de control simples, y luego fallar cuando empieza el streaming.

Causas habituales:

• Fallo de reserva de ancho de banda isócrono.
• Timeout en endpoint bulk.
• Presión de ancho de banda del host controller.
• Cuello de botella en el hub.
• Desajuste de modo USB 2.0 frente a USB 3.x.
• Desbordamiento de buffer en el firmware.
• Driver que elige un alternate setting no soportado.

Si la desconexión pasa tras una petición de start de stream o un cambio de alternate setting, inspecciona la transferencia exacta que viene justo antes del reset. Esa suele ser la pista más importante.

Qué capturar

Para una desconexión repetible, captura desde antes del plug-in o antes de la acción que falla. Quieres la historia completa:

1. Attach del dispositivo.
2. Port reset.
3. Lecturas de descriptor.
4. Asignación de dirección.
5. Selección de configuración.
6. Peticiones de driver de interfaz.
7. Primera transferencia normal de aplicación.
8. Última transferencia correcta antes del fallo.
9. Timeout, stall, reset o desconexión.
10. Re-enumeración tras el fallo.

Empezar la captura cuando el dispositivo ya falló se pierde la evidencia más importante.

Checklist de depuración

Usa este orden:

1. Reproduce con un cable corto y conocido como bueno.
2. Evita hubs pasivos en la primera prueba.
3. Captura la enumeración desde el plug-in.
4. Comprueba si el fallo pasa antes o después de SET_CONFIGURATION.
5. Identifica la última petición correcta.
6. Busca stalls, timeouts y resets repetidos.
7. Compara el fallo en reposo frente al fallo bajo carga.
8. Prueba otro puerto USB u otro controller.
9. Desactiva selective suspend solo tras recoger evidencia.
10. Compara el mismo dispositivo en otro SO si es posible.

Diagnóstico final

"USB device keeps disconnecting" es un síntoma, no una causa raíz. La corrección depende de si la evidencia muestra inestabilidad de power, reset de firmware, fallo de descriptor, fallo de class request del driver, stall de endpoint, problemas de suspend/resume o sobrecarga de alto ancho de banda.

Bus Scope ayuda mostrando las transacciones USB alrededor del fallo para que dejes de adivinar con notificaciones del escritorio y empieces a depurar desde el comportamiento real del bus.