Recupero USB endpoint halt: CLEAR_FEATURE, loop STALL e reset driver

Come diagnosticare il recupero da USB endpoint halt, CLEAR_FEATURE ENDPOINT_HALT, loop STALL ripetuti, fallimenti dei trasferimenti bulk, reset del driver e bug di stato firmware.

USB, endpoint halt, CLEAR_FEATURE, STALL, bulk transfer, reset USB, debug firmware

Gli endpoint halt USB sono una causa comune dei bug "funziona una volta, poi fallisce". Un trasferimento bulk va in STALL, il driver cancella l'halt, il dispositivo va di nuovo in STALL e alla fine l'applicazione segnala timeout, errore I/O, reset del dispositivo o disconnessione. Gli utenti cercano "USB endpoint halt", "CLEAR_FEATURE ENDPOINT_HALT", "USB STALL loop", "bulk endpoint stalled" e "libusb clear halt" quando il dispositivo non sparisce semplicemente, ma smette di accettare traffico su uno specifico endpoint.

Bus Scope è utile perché il recupero da endpoint halt è una sequenza, non un singolo evento. Devi vedere il primo STALL, la richiesta di recupero dell'host, cosa ha fatto dopo il dispositivo e se lo stesso comando ha causato di nuovo l'halt.

Cosa significa endpoint halt

Un endpoint halt significa che l'endpoint è in STALL e non può continuare i trasferimenti normali finché la condizione di halt non viene cancellata. L'host può emettere:

CLEAR_FEATURE(ENDPOINT_HALT)

verso l'endpoint interessato. Dopo, il data toggle dell'endpoint e lo stato lato dispositivo possono dover restare coerenti perché il trasferimento riprenda correttamente.

Se il firmware cancella solo il flag hardware USB ma non il proprio stato interno di protocollo, il trasferimento successivo può fallire di nuovo.

STALL vs timeout

STALL è esplicito. Timeout significa che non c'è stato completamento entro il tempo previsto. Un timeout può avvenire perché l'endpoint non ha mai risposto, il dispositivo ha continuato a fare NAK o il dispositivo si è disconnesso.

Il recupero da endpoint halt inizia con uno STALL. Se l'host non vede mai uno STALL e vede solo timeout, il percorso di recupero è diverso.

Halt di endpoint bulk

Gli endpoint bulk spesso vanno in halt quando un comando non è valido, una fase del protocollo è sbagliata o il firmware rileva un errore.

Esempio:

Host -> Device bulk OUT command
Device -> Host STALL on bulk IN
Host -> Device CLEAR_FEATURE(ENDPOINT_HALT)
Host retries bulk IN
Device stalls again

Questo pattern suggerisce che l'endpoint halt è un sintomo dello stato del protocollo del dispositivo, non solo un errore transitorio del bus.

Il recupero deve corrispondere alla direzione dell'endpoint

Gli indirizzi endpoint includono la direzione. L'endpoint 0x81 e l'endpoint 0x01 sono direzioni diverse. Cancellare l'endpoint sbagliato non recupera la pipe in STALL.

Controlla:

  • Quale endpoint è andato in STALL?
  • Direzione IN o OUT?
  • L'host ha cancellato lo stesso endpoint?
  • I trasferimenti sono ripresi dopo il clear?
  • Data toggle e stato si sono recuperati correttamente?

Questa è una causa comune di segnalazioni fuorvianti come "clear halt non funziona".

Loop STALL ripetuti

Uno STALL ripetuto dopo il clear di solito significa che la causa sottostante rimane:

  • L'host invia di nuovo un comando non supportato.
  • La macchina a stati firmware resta in errore.
  • Il dispositivo si aspetta un reset prima del retry.
  • L'host legge dall'endpoint sbagliato.
  • Lunghezza o checksum del comando sono sbagliati.
  • Data toggle/stato dell'endpoint non sono coerenti.
  • Il firmware richiede una richiesta di classe/vendor prima di riprendere.

La traccia dovrebbe includere il comando prima del primo STALL, non solo i tentativi di recupero.

Comportamento di reset del driver

Se il recupero clear-halt fallisce, i driver possono resettare il dispositivo. Questo può nascondere l'errore endpoint originale. L'utente vede una riconnessione o la scomparsa del dispositivo, ma le evidenze sul bus mostrano che il primo vero guasto era un loop STALL.

Conserva la timeline:

  1. Ultimo comando riuscito.
  2. Primo STALL.
  3. Tentativo di clear halt.
  4. Retry.
  5. STALL ripetuto o timeout.
  6. Reset o disconnessione del dispositivo.

Checklist di debug

Usa questo workflow:

  1. Identifica l'endpoint che è andato in STALL.
  2. Registra direzione e tipo di trasferimento dell'endpoint.
  3. Ispeziona il comando o trasferimento immediatamente prima dello STALL.
  4. Controlla se l'host invia CLEAR_FEATURE(ENDPOINT_HALT).
  5. Conferma che punti all'endpoint corretto.
  6. Verifica se il trasferimento riprende.
  7. Se lo STALL si ripete, ispeziona lo stato del protocollo firmware.
  8. Cerca un reset del dispositivo dopo il recupero fallito.
  9. Confronta con una sequenza di comandi nota come buona.
  10. Conserva abbastanza contesto prima dello STALL.

Diagnosi finale

Il recupero da USB endpoint halt è un problema di macchina a stati. CLEAR_FEATURE(ENDPOINT_HALT) può cancellare la condizione dell'endpoint USB, ma non corregge automaticamente stato del protocollo firmware, comandi non validi, endpoint sbagliati o logica di retry del driver.

Bus Scope aiuta a esporre l'intera sequenza di halt e recupero, così i guasti degli endpoint possono essere diagnosticati dal comportamento USB reale.