Dispositivo USB che continua a disconnettersi: debug di reset loop e alimentazione
Come diagnosticare un dispositivo USB che si disconnette, si resetta, si enumera di nuovo o fallisce dopo la sospensione usando evidenze USB a livello di pacchetto.
Un dispositivo USB che continua a disconnettersi è uno dei problemi hardware più frustranti, perché il sintomo è rumoroso e incoerente. Il dispositivo appare, sparisce, si riconnette, cambia porta COM, non riesce a enumerare o funziona per pochi secondi e poi si resetta. Gli utenti cercano "USB device keeps disconnecting", "USB reset loop", "USB device not recognized after reconnect" e "why does my USB device re-enumerate" perché il messaggio del sistema operativo raramente spiega cosa sia successo davvero.
L'evidenza utile sta sotto il livello applicativo. Devi sapere se l'host ha resettato la porta, se il dispositivo ha smesso di rispondere, se la lettura del descrittore è fallita, se la gestione dell'alimentazione ha sospeso il dispositivo, se il driver ha emesso una richiesta di classe o se l'endpoint è andato in STALL.
Bus Scope è pensato per questo tipo di troubleshooting USB. Invece di trattare USB come una scatola nera, aiuta a ispezionare trasferimenti di controllo, letture dei descrittori, reset, comportamento degli endpoint e timing intorno alla disconnessione.
Cosa può significare "si disconnette"
La frase "USB che si disconnette" può descrivere diversi guasti:
- Distacco fisico o movimento del cavo.
- Rumore elettrico o alimentazione instabile.
- Reset della porta da parte del controller host.
- Crash e riavvio del firmware del dispositivo.
- Enumerazione fallita dopo il reset.
- Unload e reload del driver.
- Sospensione selettiva o runtime power management.
- STALL di endpoint seguito da recupero fallito.
- Guasto di un'interfaccia in un dispositivo composito.
- Sovraccarico di trasferimenti ad alta larghezza di banda.
Questi guasti si assomigliano in una notifica desktop, ma appaiono diversi nelle evidenze USB.
Reset loop durante l'enumerazione
Un reset loop spesso inizia con l'host che rileva un dispositivo, resetta la porta, legge i descrittori, assegna un indirizzo e poi fallisce prima che la configurazione sia completata. Il ciclo si ripete.
Una sequenza semplificata è:
Port reset
GET_DESCRIPTOR device
SET_ADDRESS
GET_DESCRIPTOR configuration
SET_CONFIGURATION
Disconnect
Port reset
GET_DESCRIPTOR device
...
Se il dispositivo fallisce prima di SET_CONFIGURATION, il problema può essere contenuto dei descrittori, timing del firmware, alimentazione o compatibilità host. Se fallisce dopo SET_CONFIGURATION, il problema può essere inizializzazione di classe, setup degli endpoint o richiesta del driver.
I problemi di alimentazione possono sembrare problemi di protocollo
I dispositivi USB possono resettarsi quando la tensione cala, l'assorbimento di corrente ha un picco o un hub non riesce a fornire abbastanza potenza. È comune con:
- videocamere USB
- schede di acquisizione USB
- drive esterni
- schede di sviluppo
- modem cellulari
- dispositivi collegati tramite hub passivi
- cavi lunghi o di bassa qualità
A livello di pacchetto, un reset legato all'alimentazione può apparire come silenzio improvviso seguito da nuova enumerazione. Il dispositivo smette di rispondere alle richieste, l'host resetta la porta e l'enumerazione ricomincia.
Bus Scope non può misurare direttamente la tensione, ma può mostrare timing e sequenza intorno al reset. Se l'ultima operazione riuscita era l'avvio di uno stream pesante in banda o un comando di modalità motore/alimentazione, le evidenze puntano verso stress di alimentazione o firmware.
Sospensione selettiva e runtime power management
I sistemi operativi possono sospendere dispositivi USB inattivi per risparmiare energia. È normale quando dispositivo e driver lo supportano correttamente. Diventa un problema quando il firmware non riprende in modo pulito o quando il driver sospende un dispositivo che l'applicazione si aspetta resti attivo.
I sintomi includono:
- Il dispositivo funziona dopo il collegamento ma fallisce dopo un periodo di inattività.
- La prima richiesta dopo l'inattività restituisce un errore.
- Il dispositivo sparisce dopo sospensione o blocco schermo.
- Un dispositivo seriale cambia stato dopo il resume.
- Un dispositivo HID perde input dopo il wake.
La traccia USB può mostrare se il traffico si è fermato prima del guasto e se c'è stata una sequenza di resume/reset. È più utile che tirare a indovinare dal messaggio di errore dell'applicazione.
STALL di endpoint prima della disconnessione
Alcune segnalazioni di disconnessione sono in realtà guasti a livello endpoint. Il dispositivo può mettere in STALL un endpoint bulk, un endpoint interrupt o una richiesta di controllo. Il driver prova a cancellare lo STALL. Se il recupero fallisce, il driver resetta il dispositivo o l'applicazione chiude l'handle.
Cerca:
STALLsu un trasferimento di controllo.- Trasferimenti bulk ripetutamente falliti.
CLEAR_FEATURE(ENDPOINT_HALT).- Un reset dopo la stessa richiesta, ogni volta.
- Un timeout prima della disconnessione.
Se lo stesso comando provoca sempre il reset, il firmware del dispositivo potrebbe andare in crash mentre elabora quel comando.
Reset loop nei dispositivi compositi
I dispositivi USB compositi espongono più interfacce sotto un unico dispositivo. Per esempio, un dispositivo può offrire:
- interfaccia seriale CDC
- interfaccia di controllo HID
- interfaccia mass storage
- interfaccia diagnostica vendor-specific
Il dispositivo può enumerare parzialmente e fallire comunque quando si aggancia il driver di una certa interfaccia. Gli utenti possono vedere "dispositivo USB riconosciuto" seguito da una disconnessione immediata perché una interfaccia provoca un crash firmware o un conflitto di driver.
In una traccia, controlla descrittori di interfaccia, alternate setting, descrittori endpoint e richieste specifiche di classe. Il reset può avvenire solo dopo che l'host inizia a configurare una specifica interfaccia.
Dispositivi ad alta larghezza di banda
Dispositivi USB video, audio, di acquisizione e di data acquisition possono disconnettersi sotto carico. Il dispositivo può enumerare correttamente e superare semplici richieste di controllo, poi fallire quando parte lo streaming.
Cause comuni includono:
- Fallimento della prenotazione di banda isocrona.
- Timeout di endpoint bulk.
- Pressione di banda sul controller host.
- Collo di bottiglia nell'hub.
- Discrepanza tra modalità USB 2.0 e USB 3.x.
- Overflow dei buffer firmware.
- Driver che sceglie un alternate setting non supportato.
Se la disconnessione avviene dopo una richiesta di avvio stream o un cambio di alternate setting, ispeziona il trasferimento esatto che precede il reset. Spesso è l'indizio più importante.
Cosa acquisire
Per una disconnessione ripetibile, acquisisci da prima del collegamento o da prima dell'azione che scatena il guasto. Ti serve la storia completa:
- Collegamento del dispositivo.
- Reset della porta.
- Letture dei descrittori.
- Assegnazione dell'indirizzo.
- Selezione della configurazione.
- Richieste dei driver di interfaccia.
- Primo trasferimento applicativo normale.
- Ultimo trasferimento riuscito prima del guasto.
- Timeout, STALL, reset o disconnessione.
- Nuova enumerazione dopo il guasto.
Avviare l'acquisizione dopo che il dispositivo è già fallito perde l'evidenza più importante.
Checklist di debug
Segui questo ordine:
- Riproduci con un cavo corto e sicuramente buono.
- Evita hub passivi nel primo test.
- Acquisisci l'enumerazione dal collegamento.
- Verifica se il guasto avviene prima o dopo
SET_CONFIGURATION. - Identifica l'ultima richiesta riuscita.
- Cerca STALL, timeout e reset ripetuti.
- Confronta guasto in idle e guasto sotto carico.
- Prova un'altra porta o un altro controller USB.
- Disabilita la sospensione selettiva solo dopo aver raccolto evidenze.
- Se possibile, confronta lo stesso dispositivo su un altro sistema operativo.
Diagnosi finale
"USB device keeps disconnecting" è un sintomo, non una causa radice. La correzione dipende dal fatto che le evidenze mostrino instabilità di alimentazione, reset firmware, errore nei descrittori, fallimento di una richiesta di classe del driver, STALL di endpoint, problema suspend/resume o sovraccarico di banda.
Bus Scope aiuta mostrando le transazioni USB intorno al guasto, così puoi smettere di tirare a indovinare dalle notifiche desktop e iniziare il debug dal comportamento reale del bus.