USB endpoint STALL e timeout bulk: leggere l'acquisizione prima del firmware

Dopo che l'enumerazione riesce, i dispositivi USB possono ancora fallire in modi misteriosi per gli sviluppatori applicativi: "letture bulk in timeout, scritture che non completano, report HID che smettono di arrivare o l'host che segnala un endpoint STALL. Questi guasti vengono spesso trattati come bug del driver o blocchi casuali del firmware. Un'acquisizione di solito restringe il problema molto più rapidamente." I guasti degli endpoint sono evidenze del percorso dati. Avvengono dopo che l'host ha imparato la forma del dispositivo. Questo significa che i descrittori possono essere corretti mentre il comportamento degli endpoint resta sbagliato.

STALL è un segnale, non solo un errore

Un endpoint USB può restituire STALL per indicare che non può elaborare una richiesta o che un comando di classe/vendor non è supportato. Gli STALL dell'endpoint di controllo durante richieste di classe possono essere legittimi se la richiesta non è valida. Gli STALL degli endpoint dati durante il normale flusso di trasferimento di solito richiedono un'ispezione più attenta.

Domande da fare sull'acquisizione:

• quale endpoint è andato in STALL?
• era control, bulk, interrupt o isochronous?
• quale richiesta o trasferimento ha preceduto lo STALL?
• l'host ha cancellato la condizione di halt?
• il traffico è ripreso dopo CLEAR_FEATURE(ENDPOINT_HALT)?
• il firmware ha intenzionalmente mandato in STALL comandi non supportati?

Senza questo contesto, "endpoint stalled" è troppo vago per decidere cosa fare.

I timeout bulk richiedono direzione e contesto della coda

Un timeout di trasferimento bulk può significare molte cose:

• l'host si aspettava dati IN ma il dispositivo non ne aveva pronti
• il dispositivo si aspettava dati OUT ma l'applicazione ha smesso di scrivere
• il buffer endpoint del firmware non era preparato
• il driver host ha inviato una read più grande di quanto supporti il firmware
• il dispositivo ha fatto NAK fino al timeout
• indirizzo o direzione dell'endpoint erano sbagliati
• uno STALL precedente non è mai stato cancellato

La prima cosa da ispezionare è la direzione. Un timeout bulk IN e un timeout bulk OUT sono casi diversi. Per IN, chiediti se il dispositivo ha mai restituito dati. Per OUT, chiediti se l'host ha inviato dati e se il dispositivo li ha riconosciuti.

La correttezza dei descrittori è necessaria ma non sufficiente

Un descrittore può dichiarare correttamente un endpoint bulk IN e il dispositivo può comunque non riuscire a inviare dati utili. Un dispositivo CDC può enumerare come porta seriale e comunque ignorare line coding o control line state. Un'interfaccia vendor-specific può esporre endpoint ma richiedere un comando di inizializzazione prima che i dati si muovano.

Questo significa che il debug degli endpoint deve combinare:

• evidenze dei descrittori
• richieste di setup di classe o vendor
• direzione del trasferimento
• lunghezza del payload
• risultato di stato
• timing e tentativi ripetuti

L'acquisizione dovrebbe mostrare se l'host sta chiedendo qualcosa di irragionevole o se il firmware non sta soddisfacendo una richiesta valida.

I team firmware dovrebbero acquisire prima e dopo la correzione

Per i bug sugli endpoint, le acquisizioni prima e dopo sono preziose. La prima acquisizione prova il guasto. La seconda prova la correzione. Un buon confronto mostra:

• stesso dispositivo e configurazione
• stessi indirizzi endpoint
• stesso pattern di richieste dell'host
• la vecchia acquisizione va in STALL o timeout
• la nuova acquisizione completa e trasporta il payload atteso

Questo rende molto più facile la review delle regressioni firmware. Offre anche ai team di supporto un artefatto ripetibile quando i clienti segnalano che "USB si blocca a caso".

Dove si inserisce Bus Scope

Bus Scope è orientato alle evidenze USB, non a una dispersione generica su molti protocolli. Nei casi di endpoint STALL e timeout, dovrebbe tenere vicini dettaglio pacchetto, metadati endpoint, byte grezzi, tipo di trasferimento e interpretazione di classe.

L'output utile è:

• endpoint e direzione
• tipo di trasferimento
• richiesta o trasferimento prima del guasto
• evidenza di stato
• payload grezzo intorno al guasto
• se il problema segue enumerazione, setup di classe o traffico applicativo

Queste sono le informazioni che servono agli ingegneri firmware prima di toccare la logica dei buffer endpoint o il comportamento di retry lato host.

Se la tua ricerca è "USB bulk transfer timeout" o "USB endpoint stalled", non iniziare riscrivendo l'intero stack del dispositivo. Acquisisci prima le evidenze dell'endpoint.