Depuración del Device Qualifier y Other Speed Configuration USB

Cómo depurar descriptores Device Qualifier, Other Speed Configuration, diferencias de enumeración high-speed frente a full-speed y fallos por desajuste de descriptores.

usb device qualifier, other speed configuration, high speed usb, full speed usb, descriptor mismatch, usb enumeration, diagnóstico USB

Los dispositivos USB que soportan operación full-speed y high-speed deben describir cómo se comportan a la otra velocidad. Los usuarios buscan "USB Device Qualifier descriptor", "Other Speed Configuration descriptor", "high speed device enumerates as full speed", "USB descriptor mismatch" y "device works on USB 2.0 but fails on hub" cuando el mismo producto se comporta distinto según el puerto, el cable, el hub o el host controller.

Bus Scope ayuda porque el diagnóstico exige comparar peticiones de descriptor, velocidad real, tamaños de paquete de endpoint, descriptores de configuración y decisiones del host durante la enumeración.

Qué es el Device Qualifier

El Device Qualifier describe cómo se comportaría un dispositivo capaz de high-speed a la otra velocidad. Si el dispositivo está en high-speed, el qualifier informa al host sobre el comportamiento full-speed. Si está en full-speed, puede describir la capacidad high-speed.

Campos importantes:

  • Versión USB.
  • Device class.
  • Subclass.
  • Protocol.
  • Max packet size del endpoint cero.
  • Número de configuraciones.

Si este descriptor falta, está mal formado o es inconsistente, la enumeración puede ir bien en un host y fallar en otro.

Other Speed Configuration

El Other Speed Configuration describe los detalles de configuración a la velocidad opuesta. Los tamaños de paquete de endpoint, los intervalos de polling y las suposiciones de ancho de banda pueden variar.

Patrones de fallo habituales:

  • La configuración full-speed anuncia tamaños de endpoint que solo tienen sentido en high-speed.
  • La configuración high-speed se olvida de una interfaz.
  • El conteo de descriptores other-speed no coincide con la configuración real.
  • El firmware devuelve STALL cuando el host espera un descriptor.
  • El host acepta el dispositivo pero enlaza el driver equivocado.
  • El dispositivo va por un hub y falla por otro.

Estos problemas son difíciles de ver en logs de aplicación.

Dispositivo high-speed que enumera como full-speed

Un caso habitual de soporte es "USB high-speed device detected as full-speed". Puede deberse a la calidad del cable, topología del hub, integridad de señal, comportamiento de chirp del firmware, diseño eléctrico o problemas de descriptor.

La evidencia de paquetes ayuda a separar capas:

  • ¿Pasó la negociación high-speed?
  • ¿Pidió el host el Device Qualifier?
  • ¿Devolvió el dispositivo bytes de descriptor válidos?
  • ¿Coincidieron los endpoint descriptors con la velocidad elegida?
  • ¿Reseteó y reintentó el host?
  • ¿Reenumeró más tarde el dispositivo a otra velocidad?

Si la traza muestra que el dispositivo nunca llegó a high-speed, los fixes de descriptor pueden no bastar. Si muestra enumeración high-speed pero otros descriptores other-speed inválidos, el firmware es el sospechoso más fuerte.

Desajuste de max packet size entre velocidades

Los endpoint descriptors pueden variar entre full-speed y high-speed. Un endpoint bulk puede ser de 64 bytes en full-speed y 512 bytes en high-speed.

Síntomas:

  • Las transferencias fallan solo en puertos high-speed.
  • Las transferencias fallan solo a través de un hub full-speed antiguo.
  • El tamaño de buffer del firmware encaja con una velocidad y el descriptor anuncia otra.
  • El driver del host manda transferencias más grandes de lo que el firmware esperaba.
  • El dispositivo devuelve short packets en límites inesperados.

Esto conecta directo con la depuración de wMaxPacketSize.

Dispositivos compuestos

Los dispositivos compuestos hacen los descriptores other-speed aún más frágiles. Un dispositivo puede exponer HID, CDC, vendor-specific, mass storage e interfaces de actualización de firmware. El árbol other-speed tiene que mantenerse consistente.

Bugs típicos:

  • Falta el Interface Association Descriptor a una velocidad.
  • Números de interfaz distintos entre velocidades.
  • Direcciones de endpoint que cambian sin razón.
  • Una interfaz tiene un descriptor other-speed válido y otra no.
  • Windows enlaza un driver distinto tras la re-enumeración.

En productos con firmware a medida, esto es un fallo típico de copy-paste.

STALL puede ser válido o sospechoso

Algunas peticiones de descriptor pueden hacer STALL legítimamente para dispositivos que no soportan la capacidad pedida. Pero para dispositivos capaces de high-speed, los fallos repetidos alrededor del Device Qualifier u Other Speed Configuration merecen atención.

El informe debería conservar:

  • Request type.
  • Descriptor type.
  • wValue.
  • wIndex.
  • wLength.
  • Datos devueltos.
  • Estado STALL o timeout.

Bus Scope debería hacer estas transferencias de control legibles en vez de obligar a los ingenieros a decodificar bytes a mano.

Checklist de depuración

Usa este flujo:

  1. Captura desde el plug-in físico.
  2. Apunta la velocidad negociada real.
  3. Inspecciona el Device Descriptor.
  4. Inspecciona el Device Qualifier.
  5. Inspecciona el Other Speed Configuration.
  6. Compara tamaños de paquete de endpoint entre velocidades.
  7. Revisa números de interfaz y direcciones de endpoint.
  8. Prueba directo al puerto, vía hub y vía dock USB-C.
  9. Compara el comportamiento de enumeración en Windows y Linux.
  10. Conserva los fallos y reintentos de peticiones de descriptor.

Diagnóstico final

Los bugs de Device Qualifier y Other Speed Configuration son problemas de consistencia de descriptores. Explican por qué un dispositivo puede ir a una velocidad y fallar a otra, o comportarse distinto según el hub o el dock.

Bus Scope ayuda a capturar la evidencia exacta de enumeración: peticiones de descriptor, bytes other-speed, tamaños de endpoint, STALLs, resets y consecuencias de binding de driver.