USB continua desconectando: depuração de loops de reset, eventos de energia e falhas de enumeração

Um dispositivo USB que fica desconectando é um dos problemas de hardware mais frustrantes, porque o sintoma é ruidoso e inconsistente. O dispositivo aparece, some, reconecta, muda de porta COM, falha ao enumerar, ou funciona alguns segundos e depois reseta. Buscas como "USB device keeps disconnecting", "USB reset loop", "USB device not recognized after reconnect" e "why does my USB device re-enumerate" aparecem porque a mensagem do sistema operacional raramente explica o que realmente aconteceu.

A evidência útil está abaixo da camada de aplicação. Você precisa saber se o host resetou a porta, se o dispositivo parou de responder, se a leitura do descritor falhou, se o gerenciamento de energia suspendeu o dispositivo, se o driver emitiu uma class request ou se o endpoint travou.

O Bus Scope foi feito para esse estilo de troubleshooting USB. Em vez de tratar o USB como uma caixa-preta, ele ajuda a inspecionar as control transfers, leituras de descritor, resets, comportamento de endpoint e timing em torno da desconexão.

O que "desconectando" pode significar

A expressão "USB disconnecting" pode descrever várias falhas diferentes:

• Detach físico ou movimento de cabo.
• Ruído elétrico ou instabilidade de energia.
• Reset de porta do host controller.
• Crash e reboot do firmware do dispositivo.
• Falha de enumeração depois do reset.
• Driver descarregando e recarregando.
• Selective suspend ou runtime power management.
• Endpoint stall seguido de falha de recuperação.
• Falha de interface em dispositivo composto.
• Sobrecarga de transferência de alta banda.

Essas falhas parecem semelhantes em uma notificação de desktop, mas aparecem diferentes na evidência USB.

Loop de reset de enumeração

Um loop de reset geralmente começa com o host detectando um dispositivo, resetando a porta, lendo descritores, atribuindo um endereço e falhando antes da configuração terminar. O ciclo se repete.

Uma sequência simplificada é:

Port reset
GET_DESCRIPTOR device
SET_ADDRESS
GET_DESCRIPTOR configuration
SET_CONFIGURATION
Disconnect
Port reset
GET_DESCRIPTOR device
...

Se o dispositivo falha antes do SET_CONFIGURATION, o problema pode estar no conteúdo do descritor, no timing do firmware, na energia ou na compatibilidade com o host. Se falha depois do SET_CONFIGURATION, o problema pode estar na inicialização de classe, no setup do endpoint ou em uma requisição do driver.

Problemas de energia que parecem de protocolo

Dispositivos USB podem resetar quando a tensão cai, quando a corrente puxada sobe demais, ou quando um hub não consegue fornecer energia suficiente. Isso é comum com:

• câmeras USB
• placas de captura USB
• drives externos
• placas de desenvolvimento
• modems celulares
• dispositivos conectados via hubs passivos
• cabos longos ou de baixa qualidade

No nível de pacote, um reset relacionado a energia pode parecer silêncio súbito seguido de reenumeração. O dispositivo para de responder às requisições, o host reseta a porta e a enumeração começa de novo.

O Bus Scope não mede tensão diretamente, mas mostra a temporização e a sequência em torno do reset. Se a última operação bem-sucedida foi um start de stream de alta banda ou um comando de modo de motor/energia, a evidência aponta para estresse de energia ou de firmware.

Selective suspend e runtime power management

Sistemas operacionais podem suspender dispositivos USB ociosos para economizar energia. Isso é normal quando o dispositivo e o driver tratam isso corretamente. Vira problema quando o firmware do dispositivo não volta limpo do suspend ou quando o driver suspende um dispositivo que a aplicação espera que fique ativo.

Sintomas:

• Dispositivo funciona logo depois de conectar, mas falha depois de um tempo em idle.
• Primeira requisição depois do idle volta com erro.
• Dispositivo some depois de sleep ou bloqueio de tela.
• Dispositivo serial muda de estado depois do resume.
• Dispositivo HID perde entrada depois do wake.

O trace USB mostra se o tráfego parou antes da falha e se houve uma sequência de resume/reset. Isso é mais útil do que tentar adivinhar pela mensagem de erro da aplicação.

Stall de endpoint antes da desconexão

Alguns relatos de desconexão são, na verdade, falhas em nível de endpoint. O dispositivo pode travar um endpoint bulk, um endpoint interrupt ou uma control request. O driver tenta limpar o stall. Se a recuperação falha, o driver reseta o dispositivo ou a aplicação fecha o handle.

Procure por:

• STALL em uma control transfer.
• Transferências bulk falhando repetidamente.
• CLEAR_FEATURE(ENDPOINT_HALT).
• Reset depois da mesma requisição toda vez.
• Timeout antes da desconexão.

Se o mesmo comando sempre dispara o reset, o firmware do dispositivo pode estar crashando enquanto processa esse comando.

Loops de reset em dispositivo composto

Dispositivos USB compostos expõem várias interfaces sob o mesmo dispositivo. Por exemplo, um dispositivo pode fornecer:

• interface serial CDC
• interface de controle HID
• interface de armazenamento em massa
• interface de diagnóstico vendor-specific

O dispositivo pode enumerar parcialmente e ainda falhar quando um driver de interface se anexa. O usuário pode ver "USB device recognized" seguido de desconexão imediata porque uma interface dispara um crash de firmware ou um conflito de driver.

Em um trace, inspecione os interface descriptors, alternate settings, endpoint descriptors e class-specific requests. O reset pode acontecer só depois que o host começa a configurar uma interface específica.

Dispositivos de alta banda

Dispositivos de vídeo, áudio, captura e aquisição de dados USB podem desconectar sob carga. O dispositivo pode enumerar corretamente, passar control requests simples e depois falhar quando o streaming começa.

Causas comuns:

• Falha de reserva de bandwidth isochronous.
• Timeout em endpoint bulk.
• Pressão de bandwidth no host controller.
• Gargalo de hub.
• Mismatch entre USB 2.0 e USB 3.x.
• Overflow de buffer no firmware.
• Driver escolhendo um alternate setting não suportado.

Se a desconexão acontece depois de uma requisição de start de stream ou de uma mudança de alternate setting, inspecione a transferência exata que vem antes do reset. Costuma ser a pista mais importante.

O que capturar

Para uma desconexão reproduzível, capture desde antes da conexão ou antes da ação que falha. Você quer a história completa:

1. Attach do dispositivo.
2. Reset de porta.
3. Leituras de descritor.
4. Atribuição de endereço.
5. Seleção de configuração.
6. Requisições do driver de interface.
7. Primeira transferência normal da aplicação.
8. Última transferência bem-sucedida antes da falha.
9. Timeout, stall, reset ou desconexão.
10. Reenumeração depois da falha.

Começar a captura depois que o dispositivo já falhou perde a evidência mais importante.

Checklist de depuração

Use esta ordem:

1. Reproduza com um cabo curto e sabidamente bom.
2. Evite hubs passivos no primeiro teste.
3. Capture a enumeração desde a conexão.
4. Confira se a falha acontece antes ou depois do SET_CONFIGURATION.
5. Identifique a última requisição bem-sucedida.
6. Procure stalls, timeouts e resets repetidos.
7. Compare falha em idle com falha sob carga.
8. Teste em outra porta ou controller USB.
9. Só desative selective suspend depois de coletar evidência.
10. Compare o mesmo dispositivo em outro SO se possível.

Diagnóstico final

"USB device keeps disconnecting" é sintoma, não causa raiz. A correção depende de a evidência mostrar instabilidade de energia, reset de firmware, falha de descritor, falha em class request do driver, stall de endpoint, problema de suspend/resume ou sobrecarga de alta banda.

O Bus Scope ajuda mostrando as transações USB em torno da falha, para que você pare de adivinhar pelas notificações do desktop e comece a depurar pelo comportamento real do barramento.