Debug dei descrittori USB per dispositivi HID e CDC

I dispositivi HID e CDC sono diffusi perché permettono ai team firmware di offrire interfacce USB utili senza scrivere un driver personalizzato per ogni host. Questa comodità dipende però da descrittori precisi. Quando una tastiera HID, un sensore, un bridge seriale o un dispositivo composito non funziona, la causa principale è spesso visibile nei descrittori prima ancora di emergere nell'applicazione.

Il debug dei descrittori non è la parte più appariscente del lavoro, ma è uno dei modi più rapidi per risolvere i casi di supporto USB.

HID: il descrittore di report è il contratto

Per i dispositivi HID, all'host non bastano le informazioni sugli endpoint. Ha bisogno del descrittore di report HID. Quel descrittore definisce report ID, usage, dimensioni, conteggi, intervalli logici e il modo in cui i byte devono essere interpretati.

Errori HID comuni includono:

• la lunghezza del report non corrisponde ai payload interrupt reali
• un report ID viene usato nel firmware ma non dichiarato in modo coerente
• i valori logici minimo e massimo non corrispondono alla rappresentazione dei dati
• usage page o usage non corrispondono alle aspettative dell'host
• l'intervallo dell'endpoint non è realistico per il comportamento del dispositivo
• le assunzioni del boot protocol entrano in conflitto con il comportamento del report protocol

Un errore dell'host può sembrare generico. Un'acquisizione che mostra i byte dei descrittori e i trasferimenti interrupt può rendere evidente la discrepanza.

CDC: il layout delle interfacce conta

I dispositivi CDC ACM di solito espongono un'interfaccia di comunicazione e un'interfaccia dati. L'host si aspetta un insieme coerente di descrittori e richieste specifiche di classe. Un descrittore funzionale mancante, un'associazione di interfaccia errata o una discrepanza sugli endpoint possono impedire la comparsa della porta seriale virtuale.

Evidenze da controllare:

• classe e sottoclasse dell'interfaccia
• descrittori CDC header, ACM, union e call management
• endpoint di notifica
• endpoint bulk IN e OUT
• SET_LINE_CODING
• SET_CONTROL_LINE_STATE
• trasferimenti dati dopo la configurazione

Se la porta seriale compare ma non passa alcun byte, il problema può essere nel comportamento degli endpoint o nel protocollo applicativo. Se la porta seriale non compare mai, descrittori e richieste di classe sono il primo punto da esaminare.

I dispositivi compositi richiedono più disciplina

I dispositivi compositi possono combinare HID, CDC, mass storage, interfacce vendor-specific e altro ancora. Questo è utile, ma moltiplica le modalità di guasto. Un errore nel descrittore di una sola interfaccia può influenzare il binding dell'host per l'intero dispositivo.

Per il debug di dispositivi compositi, controlla:

• lunghezza totale della configurazione
• numeri di interfaccia
• descrittori di associazione interfaccia
• unicità degli endpoint
• posizione dei descrittori specifici di classe
• richieste dell'host per ciascuna interfaccia

Non dare per scontato che "il firmware invia i byte giusti" finché l'acquisizione non prova che l'host ha visto la struttura corretta.

Perché contano sia i byte grezzi sia l'interpretazione di classe

I byte grezzi sono la verità di riferimento. L'interpretazione di classe li rende utilizzabili. Un buon strumento diagnostico USB dovrebbe mostrare entrambi. Gli ingegneri devono vedere i byte esatti del descrittore quando qualcosa non torna, ma hanno anche bisogno dei campi decodificati per evitare di contare manualmente gli offset in ogni caso.

Il workflow migliore è:

1. ispezionare l'albero dei descrittori decodificato
2. passare ai byte grezzi per i campi sospetti
3. confrontare le richieste dell'host con le risposte del firmware
4. ispezionare i trasferimenti degli endpoint dopo la configurazione
5. salvare la sessione per riprodurre il caso o consegnarlo al supporto

Questo workflow mantiene la diagnosi legata alle evidenze.

Dove si inserisce Bus Scope

Bus Scope è progettato per team firmware, laboratori hardware e produttori di dispositivi che hanno bisogno di una risposta ripetibile al perché il traffico USB fallisce. Tiene insieme in un unico workbench contesto dell'esplorazione dispositivo, dettaglio dei pacchetti, byte grezzi, descrittori, osservazioni di classe, filtri e sessioni .bscope salvate.

Per i casi HID e CDC, Bus Scope dovrebbe aiutare a rispondere a domande come:

• l'enumerazione è stata completata?
• i descrittori corrispondono alla classe prevista?
• l'host ha inviato le richieste di classe attese?
• i trasferimenti degli endpoint corrispondono alle aspettative su report o line coding?
• è un problema di firmware, driver host o protocollo applicativo?

Questa è la differenza tra vedere "driver non riuscito" e capire quale contratto USB è stato violato.