Depuración de dispositivos compuestos USB: números de interfaz, IAD, endpoints y binding de driver

Cómo depurar dispositivos compuestos USB cuando una interfaz funciona, otra falla o el host enlaza el driver equivocado.

USB, dispositivo compuesto, IAD, interfaz, binding de driver

Los dispositivos compuestos USB son cómodos y peligrosos a la vez. Un único dispositivo puede exponer controles HID, CDC serie, mass storage, endpoints vendor-specific, audio, vídeo o interfaces de diagnóstico. Cuando todo se describe correctamente, el host enlaza los drivers adecuados y cada función va. Cuando un campo de descriptor está mal, el dispositivo entero puede parecer poco fiable.

Búsquedas como "USB composite device not recognized", "CDC interface not showing", "HID works but serial does not" o "wrong driver binding USB interface" suelen apuntar a estructura de descriptores, numeración de interfaz, asignación de endpoints o comportamiento del Interface Association Descriptor.

Los dispositivos compuestos necesitan una configuración coherente

El configuration descriptor es el mapa de nivel superior. Tiene que describir la longitud total, el número de interfaces, los atributos de potencia y todos los descriptores de interfaz y endpoint anidados. Si wTotalLength está mal, el host puede no leer todas las funciones. Si el conteo de interfaces está mal, el host puede ignorar las últimas. Si las direcciones de endpoint colisionan, las transferencias se vuelven ambiguas o inválidas.

Inspecciona:

  • Longitud total de la configuración.
  • Número de interfaces.
  • Números de interfaz.
  • Alternate settings.
  • Direcciones de endpoint.
  • Direcciones de endpoint.
  • Valores de class, subclass, protocol.
  • Orden de los descriptores.

Una captura debería mostrar si el host pidió la configuración completa y qué bytes devolvió el dispositivo.

El IAD ayuda a agrupar interfaces relacionadas

Los Interface Association Descriptors se suelen usar para agrupar varias interfaces que pertenecen a una misma función, como la comunicación CDC más los datos CDC. Sin un agrupamiento correcto, el host puede enlazar drivers mal o exponer solo parte de la función.

Evidencia de IAD a inspeccionar:

  • Primer número de interfaz.
  • Conteo de interfaces.
  • Class, subclass y protocol de la función.
  • Posición antes de las interfaces agrupadas.
  • Consistencia con los descriptores de interfaz reales.

Si el CDC serie no aparece pero el HID sí, puede que la interfaz HID esté bien y el agrupamiento CDC esté mal.

Las colisiones de direcciones de endpoint son fáciles de pasar por alto

Las direcciones de endpoint incluyen la dirección. El endpoint 0x81 y el 0x01 son direcciones distintas, pero dos endpoints IN con la misma dirección no son válidos dentro de la misma configuración. Los equipos de firmware a veces copian descriptores de endpoint entre interfaces y se olvidan de actualizar las direcciones.

Síntomas:

  • Una interfaz funciona y otra queda muda.
  • El host manda transferencias a un endpoint inesperado.
  • El driver de clase carga pero la aplicación no recibe datos.
  • STALL o timeout en endpoint tras la configuración.
  • Solo una función va a la vez.

La captura debería enseñar los descriptores de endpoint y el tráfico posterior de transferencia lado a lado.

El binding de driver también es evidencia

El host elige drivers según los descriptores. Un dispositivo que se enlaza mal puede tener evidencia de descriptores que explique por qué. Class, subclass, protocol, interface association, compatible IDs y descriptores específicos del SO pueden afectar al binding.

No diagnostiques el binding solo con el Administrador de dispositivos o con logs de la aplicación. Compara las class-specific requests del host con el árbol de descriptores. Si las peticiones de clase esperadas no llegan, probablemente el host no enlazó el driver esperado.

Dónde encaja Bus Scope

Bus Scope debería ayudar a los equipos de firmware a inspeccionar dispositivos compuestos a dos niveles:

  • Mapa de descriptores.
  • Evidencia de transferencias tras el binding del driver.

Una buena sesión .bscope para depurar compuestos muestra:

  • Todas las interfaces.
  • Agrupamiento por IAD.
  • Asignación de endpoints.
  • Class-specific requests por interfaz.
  • Bytes de descriptor en crudo.
  • Estado de las transferencias tras la configuración.

Eso hace que la conversación de soporte sea concreta. En lugar de "a Windows no le gusta nuestro dispositivo compuesto", el informe puede decir "la interfaz 2 nunca recibe class requests CDC porque el descriptor de agrupamiento no coincide con el layout declarado de interfaces".

Ese es el nivel de evidencia que necesitan los equipos de firmware.