Timeout en control request vendor-specific USB

Las vendor-specific USB control requests son habituales en herramientas de firmware, utilidades de calibración, software de test de fábrica, bootloaders, modos de debug y dispositivos a medida. Cuando fallan, las aplicaciones suelen reportar solo "control transfer timeout", "vendor request failed", "device not responding" o LIBUSB_ERROR_TIMEOUT. Los usuarios buscan "USB vendor request timeout", "bmRequestType debugging", "control transfer endpoint zero timeout" y "vendor-specific USB command failed" porque el fallo está en un protocolo privado que el SO no puede explicar.

Bus Scope ayuda porque cada vendor-specific control request sigue teniendo un setup packet estándar. Aunque el significado del comando sea privado, la estructura de la transferencia es visible.

Campos del setup packet

Una control request incluye:

• bmRequestType.
• bRequest.
• wValue.
• wIndex.
• wLength.

Para vendor requests, bmRequestType identifica el tipo vendor y la dirección. bRequest, wValue y wIndex los define el firmware del dispositivo.

Si la dirección o la longitud está mal, el dispositivo puede hacer STALL o timeout.

Timeout frente a STALL

STALL significa que el dispositivo rechazó la petición de forma explícita. Timeout significa que el host no recibió completion a tiempo.

El timeout puede significar:

• El firmware se colgó procesando el comando.
• El dispositivo se reseteó durante la petición.
• Desajuste de dirección.
• El host esperaba datos pero el dispositivo no mandó ninguno.
• El dispositivo esperaba datos OUT pero el host pidió IN.
• El comando solo es válido en otro estado.
• La operación de erase de flash o del sensor tardó demasiado.

La traza debería enseñar si hubo data stage y si el dispositivo desapareció después.

Comandos de bootloader y de actualización de firmware

Las vendor requests suelen disparar entrada al bootloader, erase de flash, escritura de firmware, reset o polling de status. Esos comandos pueden tardar legítimamente, pero el timeout del host tiene que coincidir con el comportamiento esperado.

Si una petición siempre hace timeout antes de una reconexión, puede que el dispositivo se esté reseteando bien. Si hace timeout y nunca reenumera, puede que el firmware esté atascado.

Checklist de depuración

Usa este flujo:

1. Captura antes de mandar el comando vendor.
2. Decodifica los campos del setup packet.
3. Confirma que la dirección coincide con el data stage esperado.
4. Comprueba wLength.
5. Busca bytes del data stage.
6. Busca STALL, timeout, reset o desconexión.
7. Mira si el dispositivo reenumera en otro modo.
8. Compara la secuencia de comandos con una herramienta conocida buena.
9. Aumenta el timeout solo tras demostrar que el comando tarda legítimamente.
10. Conserva la secuencia de vendor request antes y después del fallo.

Diagnóstico final

Los timeouts en vendor-specific control requests son fallos de protocolo privado, pero la evidencia USB sigue siendo visible. El setup packet, la dirección, la longitud, el timing, el comportamiento de reset y la respuesta del endpoint cero enseñan si el responsable es la forma de la petición del host o el estado del firmware del dispositivo.

Bus Scope ayuda a convertir un fallo de comando privado en evidencia USB inspeccionable.