Flujo de depuración de firmware USB: del fallo de enumeración a la evidencia
Un flujo práctico de depuración de firmware USB para ingenieros que necesitan evidencia de descriptores, endpoints, transferencias de control y capturas antes de cambiar código.
Los bugs de firmware USB son caros porque el síntoma visible suele ser vago: "Windows dice que falló la petición de device descriptor, Linux registra un bucle de reset, un HID report se ve mal, o un endpoint bulk se stalled bajo carga. Bus Scope ofrece a los equipos de firmware un flujo local para juntar evidencia a nivel de bus antes de tocar descriptores, comportamiento de endpoint o suposiciones del driver del host." Este hub es el punto de partida para depurar USB con Bus Scope. Úsalo para decidir qué capturar primero, qué frontera de fallo importa y cuándo basta un analizador USB software antes de mandar el caso a un laboratorio hardware.
El flujo
| Paso | Qué demostrar | Evidencia a recoger |
|---|---|---|
| 1. Confirmar enumeración | ¿El host pidió y aceptó los descriptores? | Evidencia de device, configuration, interface, endpoint, HID, CDC, BOS, string y status |
| 2. Inspeccionar endpoint cero | ¿Las transferencias de control terminaron limpias? | Campos del setup packet, longitud del data stage, status stage, STALL, timeout y comportamiento de ZLP |
| 3. Comprobar comportamiento de clase | ¿El comportamiento de clase anunciado coincide con el tráfico? | HID reports, CDC line coding, mass storage BOT, UVC alternate settings o vendor requests |
| 4. Aislar timing de transporte | ¿El endpoint es lento, halted o sobresuscrito? | Bulk timeouts, interrupt polling, huecos isócronos, bInterval, max packet size y cambios de ancho de banda |
| 5. Guardar el caso | ¿Puede otro ingeniero reabrir la misma evidencia? | Sesión .bscope de Bus Scope, exportación de informe y notas enfocadas |
Empieza por la evidencia de enumeración
Cuando un dispositivo falla antes de que cargue el driver, empieza por fallo de enumeración de dispositivo USB. Ese artículo cubre los primeros puntos de captura: reset, asignación de dirección, lecturas de descriptor, selección de configuración y la frontera entre la respuesta del firmware y la política del host.
Si Windows reporta Code 43 o "device descriptor request failed", empareja el flujo de enumeración con fallo en la petición del device descriptor USB en Windows. La pregunta útil no es si Windows está molesto, sino si el bus muestra un descriptor corto, una longitud mala, un reset repetido o ninguna respuesta.
Inspecciona el endpoint cero antes de cambiar firmware
El endpoint cero es donde se hacen visibles muchos bugs de firmware. Usa depuración de STALL en transferencias de control USB cuando falla una petición durante el setup, data o status. Usa depuración del status stage en transferencias de control USB cuando los datos parecen correctos pero la completion nunca se cierra.
Bus Scope mantiene los campos del setup, la dirección, el request type, value, index, length, los bytes en crudo, el status y la salida del decoder en la misma vista local. Esa es la diferencia entre "prueba con otro build de firmware" y "el host pidió 64 bytes, el dispositivo devolvió 18 y luego hizo STALL en la siguiente petición".
Enlaza descriptores con comportamiento de clase
Los descriptores no son papeleo. Controlan qué driver enlaza y qué cree el host que puede hacer el dispositivo. Para HID y CDC, lee depuración de descriptores USB para HID y CDC, depuración de HID feature reports y depuración serie USB CDC ACM.
Los dispositivos compuestos exigen atención especial. Depuración de dispositivos compuestos USB y binding de driver incorrecto en dispositivo compuesto USB explican por qué los números de interfaz, el IAD, los class codes y el layout de endpoints pueden cambiar el resultado del driver antes de que corra el código de aplicación.
Revisa el timing de endpoint y la recuperación
Si la enumeración va bien pero las transferencias fallan después, salta a la evidencia de endpoint. STALL en endpoint y timeout en bulk transfer USB y recuperación de halt en endpoints USB son la primera parada para CLEAR_FEATURE, bulk pipes stalled y bucles de reintento.
Para dispositivos sensibles al timing, usa depuración de bInterval en endpoints interrupt USB y caídas en transferencias isócronas USB. Esos casos suelen parecer inestabilidad del firmware hasta que demuestras el comportamiento del polling interval, alternate setting, ancho de banda o packet size.
Elige la ruta correcta de analizador
Bus Scope es el analizador software centrado para el trabajo rutinario de firmware y driver. Comparativa de software analizador USB, Bus Scope frente a Wireshark y USBPcap y analizador USB por software frente a hardware explican cuándo quedarse en software y cuándo escalar a hardware de capa física.
Si tu equipo ya usa Wireshark, filtros USB de Wireshark con USBPcap y usbmon sigue siendo útil. Bus Scope no te obliga a tirar tu conocimiento de paquetes; añade estructura USB-first alrededor de la evidencia que los equipos de firmware necesitan cada día.
Setup y siguiente paso
Usa la ayuda de conexión de Bus Scope para arrancar una captura local y la configuración de captura por plataforma para confirmar la preparación de usbmon en Linux o USBPcap en Windows. Para más contenido, abre el índice del blog de Bus Scope.