Depuración de transferencias de control USB y setup packets
Arregla errores de STALL en USB y fallos de transferencias de control. Diagnostica problemas de setup packet con bmRequestType, bRequest, wValue, wIndex y evidencia de peticiones de descriptor para depurar el firmware.
Las transferencias de control USB son la primera conversación seria entre host y dispositivo. La enumeración depende de ellas. El setup de clase depende de ellas. La inicialización vendor-specific suele depender de ellas. Cuando fallan las transferencias de control, el usuario puede ver solo "device not recognized" o "driver failed", pero la evidencia suele estar en el setup packet.
Para los ingenieros de firmware, aprender a leer bmRequestType, bRequest, wValue, wIndex y wLength es una de las formas más rápidas de pasar de las suposiciones a una corrección precisa.
El setup packet es el contrato de la petición
Un setup packet USB le dice al dispositivo:
- Dirección de la transferencia.
- Tipo de petición: standard, class, vendor o reserved.
- Recipient: device, interface, endpoint u other.
- Código de la petición.
- Campo value.
- Campo index.
- Longitud de datos esperada.
Si el firmware decodifica mal estos campos, puede devolver el descriptor equivocado, hacer STALL en una petición válida o aceptar un comando inválido. Si el host envía una petición inesperada, la captura también lo enseña.
GET_DESCRIPTOR es el primer sitio donde mirar
Durante la enumeración, el host envía peticiones de descriptor estándar. Un patrón habitual incluye:
- Petición de device descriptor.
- Petición de configuration descriptor.
- Petición de string descriptor.
- Petición de HID report descriptor para dispositivos HID.
- Petición de BOS descriptor en hosts modernos.
En el setup packet, bRequest identifica GET_DESCRIPTOR, mientras que wValue incluye el descriptor type y el descriptor index. wIndex puede identificar el language ID para string descriptors o la interfaz para class-specific descriptors. wLength dice cuántos bytes espera el host.
Cuando la longitud de la respuesta de un descriptor es incorrecta, o cuando el firmware devuelve menos bytes de los que el host necesita, la enumeración puede fallar más adelante de una forma que parece no relacionada.
Los errores de dirección son caros
Las transferencias de control tienen dirección. Las peticiones device-to-host devuelven datos. Las peticiones host-to-device llevan datos o configuran estado. Si el firmware trata una petición de lectura como escritura, o devuelve datos durante una petición de escritura, el host no va a adivinar amablemente la intención.
Fíjate en:
- Dirección IN pero sin data stage.
- Dirección OUT pero el firmware espera para mandar datos.
- Falta el status stage zero-length.
- STALL en una petición standard válida.
- Class request atendida por la interfaz equivocada.
La captura debería enseñar la petición, el data stage y el status stage.
Las class y vendor requests necesitan contexto de interfaz
Después de la enumeración, los drivers de clase envían class-specific requests. CDC puede enviar peticiones de line coding. HID puede pedir report descriptors o feature reports. Herramientas vendor pueden enviar comandos de inicialización. El mismo valor de bRequest puede significar cosas distintas según el request type y el recipient.
Inspecciona:
- Request type.
- Recipient.
- Número de interfaz en
wIndex. - Número de endpoint cuando el recipient es endpoint.
- Bytes del payload.
- Respuesta o STALL.
Si un dispositivo compuesto tiene varias interfaces, enrutar la petición a la interfaz equivocada es un bug frecuente.
Cómo debería ayudar Bus Scope
Bus Scope se ha construido alrededor de evidencia USB. La depuración de transferencias de control necesita campos de setup decodificados y bytes en crudo juntos. La mejor vista permite leer los campos semánticos y, a la vez, validar los bytes exactos del paquete.
Una sesión útil de Bus Scope para depurar transferencias de control debería responder:
- ¿Qué setup packet falló?
- ¿Era standard, class o vendor?
- ¿Qué descriptor o interfaz se pidió?
- ¿Devolvió el dispositivo la longitud esperada?
- ¿Hizo STALL el firmware a propósito o por error?
- ¿Dependía el siguiente paso de enumeración de esta respuesta?
El problema puede describirse como "falló la transferencia de control USB", pero la solución suele estar en un setup packet de cinco campos.