Fallo de enumeración del dispositivo USB: lo que el ingeniero de firmware debería capturar primero

Cuando un dispositivo USB no se reconoce, la primera pregunta rara vez es "¿qué botón de la UI debería pulsar?". La pregunta útil es: "¿hasta dónde llegó la enumeración y qué evidencia demuestra dónde se paró?" La enumeración USB es una conversación estructurada entre host y dispositivo. El host resetea el puerto, pide descriptores, asigna una dirección, selecciona una configuración y carga un driver según la evidencia de clase e interfaz. Un problema de firmware, un desajuste de descriptor, un problema de timing, un problema de cable o un problema de binding de driver pueden producir el mismo síntoma de cara al usuario: "el dispositivo no aparece."

Empieza por la línea de tiempo de enumeración

Una buena captura USB debería mostrar:

• Attach del dispositivo o reset de puerto.
• Setup packets.
• Peticiones GET_DESCRIPTOR.
• Respuesta del device descriptor.
• Asignación de dirección.
• Petición del configuration descriptor.
• Peticiones de string descriptor, si los hay.
• SET_CONFIGURATION.
• Class-specific requests tras la configuración.

Si la línea de tiempo se para antes del device descriptor, el problema puede ser eléctrico, de timing, del hub, del cable o de readiness de bajo nivel del dispositivo. Si se para en el parseo de configuración, revisa la longitud del descriptor, las definiciones de endpoint, las clases de interfaz y los campos de longitud total. Si la enumeración va bien pero la aplicación falla, el problema puede estar en el protocolo de clase, el comportamiento del endpoint o las expectativas del driver.

La evidencia de descriptores gana a las suposiciones

Los equipos de firmware suelen saber qué querían exponer: HID, CDC, mass storage, endpoints vendor-specific o un layout compuesto. El host solo ve descriptores. Si los descriptores son inconsistentes, el host puede rechazar el dispositivo aunque la lógica del firmware sea correcta.

Campos importantes:

• Vendor ID y Product ID.
• Device class, subclass y protocol.
• Longitud total de la configuración.
• Número de interfaces.
• Dirección y dirección de endpoint.
• Tipo de transferencia del endpoint.
• Max packet size.
• Disponibilidad del HID report descriptor.
• CDC functional descriptors.

Pequeños errores de descriptor pueden causar síntomas grandes. Una longitud total mal calculada o un endpoint que falta pueden hacer que el dispositivo entero parezca roto.

Captura antes de instalar más drivers

Instalar drivers puede cambiar el comportamiento, pero también puede tapar el fallo original. Para diagnóstico, captura el primer intento limpio de enumeración. Después, captura tras los cambios de driver si hace falta. La comparación es valiosa.

Un flujo práctico de soporte es:

1. Capturar el attach y la enumeración.
2. Identificar la última petición exitosa del host.
3. Inspeccionar los campos del descriptor en torno al fallo.
4. Comparar contra la clase USB objetivo.
5. Repetir tras cambios de firmware o driver.

Eso evita la trampa de depurar solo el error final de la aplicación.

Linux y Windows necesitan rutas de captura distintas

En Linux, usbmon da evidencia del tráfico USB a nivel de kernel. En Windows, USBPcap es la ruta habitual de driver de captura. Las capturas no son idénticas en el setup operativo, pero el objetivo de ingeniería es el mismo: conservar evidencia de petición, respuesta, endpoint, dirección y clase.

Para equipos que dan soporte en ambas plataformas, el informe debería dejar clara la fuente de captura. Un dispositivo que enumera en Linux pero falla en Windows puede tener un problema de binding de driver. Un dispositivo que falla antes de los descriptores en ambas plataformas es más probablemente firmware, cable, hub o timing eléctrico.

Dónde encaja Bus Scope

Bus Scope se construye alrededor de evidencia USB, no de una proliferación amplia de protocolos. Ayuda a los equipos de firmware y hardware a inspeccionar transferencias, descriptores, endpoints y observaciones de clase en un banco de trabajo denso. El objetivo no es reemplazar cualquier analizador de fabricante. El objetivo es hacer que la evidencia USB del día a día sea más fácil de capturar, inspeccionar, guardar y entregar.

Para fallos de enumeración, el deliverable valioso es una frontera clara:

• El host hizo esta petición.
• El dispositivo devolvió esta respuesta.
• La enumeración se paró aquí.
• La evidencia de descriptor sugiere este desajuste.
• La siguiente acción corresponde a firmware, driver, cable, hub o política del host.

Eso es lo que convierte "USB device not recognized" en un caso de ingeniería.