Falha na enumeração de dispositivo USB: o que o engenheiro de firmware precisa capturar primeiro

Quando um dispositivo USB não é reconhecido, a pergunta que vale a pena fazer quase nunca é "qual botão clicar na interface". A pergunta certa é: "até onde a enumeração chegou e qual evidência prova onde ela parou?" A enumeração USB é uma conversa estruturada entre host e dispositivo. O host reseta a porta, pede os descritores, atribui um endereço, escolhe uma configuração e carrega um driver com base na classe e na interface apresentadas. Um problema de firmware, um descritor inconsistente, um problema de temporização, um cabo ruim ou um erro de vínculo com o driver podem produzir o mesmo sintoma para o usuário final: "o dispositivo simplesmente não aparece."

Comece pela linha do tempo da enumeração

Uma boa captura de USB precisa mostrar:

• a conexão do dispositivo ou o reset de porta
• pacotes de setup
• requisições GET_DESCRIPTOR
• resposta do descritor de dispositivo
• atribuição de endereço
• requisição do descritor de configuração
• requisições de descritores de string, quando houver
• SET_CONFIGURATION
• requisições específicas de classe depois da configuração

Se a linha do tempo para antes do descritor de dispositivo, o problema provavelmente é elétrico, de temporização, no hub, no cabo ou na prontidão de baixo nível do dispositivo. Se ela para na análise da configuração, vale inspecionar o tamanho do descritor, a definição de endpoints, as classes de interface e os campos de comprimento total. Se a enumeração passa, mas a aplicação falha, o problema costuma estar no protocolo de classe, no comportamento do endpoint ou na expectativa do driver.

Evidência do descritor vale mais que achismo

A equipe de firmware normalmente sabe o que quer expor: HID, CDC, armazenamento em massa, endpoints específicos do fabricante ou um layout composto. O host só vê descritores. Se os descritores forem inconsistentes, o host pode rejeitar o dispositivo mesmo quando a lógica do firmware está correta.

Os campos mais importantes para conferir:

• Vendor ID e Product ID
• classe, subclasse e protocolo do dispositivo
• comprimento total da configuração
• quantidade de interfaces
• endereço e direção do endpoint
• tipo de transferência do endpoint
• max packet size
• presença do descritor de relatório HID
• descritores funcionais de CDC

Pequenos erros de descritor geram sintomas enormes. Um comprimento total errado ou um endpoint faltando podem fazer o dispositivo inteiro parecer quebrado.

Capture antes de instalar mais drivers

Instalar drivers pode mudar o comportamento, mas também pode esconder a falha original. Para diagnosticar, capture a primeira tentativa de enumeração limpa. Depois, se fizer sentido, capture de novo depois de mudar drivers. A comparação costuma ser reveladora.

Um fluxo de suporte prático:

1. capturar a conexão e a enumeração
2. identificar a última requisição do host bem-sucedida
3. inspecionar os campos do descritor perto da falha
4. comparar com a classe USB pretendida
5. repetir depois de mudanças de firmware ou driver

Isso evita a armadilha de depurar apenas o erro final da aplicação.

Linux e Windows exigem caminhos de captura diferentes

No Linux, o usbmon fornece evidência do tráfego USB no nível do kernel. No Windows, o caminho mais comum é o USBPcap. A configuração operacional não é igual, mas o objetivo de engenharia é o mesmo: preservar requisição, resposta, endpoint, direção e classe.

Para equipes que dão suporte às duas plataformas, o relatório precisa indicar a fonte da captura. Um dispositivo que enumera no Linux mas falha no Windows geralmente tem um problema de vínculo com o driver. Um dispositivo que falha antes dos descritores nas duas plataformas provavelmente tem problema de firmware, cabo, hub ou temporização elétrica.

Onde o Bus Scope entra

O Bus Scope é construído em torno da evidência USB, não de uma prateleira enorme de protocolos. Ele ajuda equipes de firmware e hardware a inspecionar transferências, descritores, endpoints e observações de classe em uma bancada de trabalho enxuta. O objetivo não é substituir todos os analisadores de fabricantes. O objetivo é tornar a evidência cotidiana de USB mais fácil de capturar, inspecionar, salvar e entregar.

Para falhas de enumeração, o entregável de valor é uma fronteira bem definida:

• o host fez essa requisição
• o dispositivo devolveu essa resposta
• a enumeração parou aqui
• a evidência do descritor sugere essa incompatibilidade
• a próxima ação é de firmware, driver, cabo, hub ou política de host

É isso que transforma "dispositivo USB não reconhecido" em um caso de engenharia.