Timeout em control request vendor-specific USB: comandos de firmware, bmRequestType e endpoint zero

Control requests vendor-specific são comuns em ferramentas de firmware, utilitários de calibração, software de teste de fábrica, bootloaders, modos de debug e dispositivos customizados. Quando falham, a aplicação geralmente reporta apenas "control transfer timeout", "vendor request failed", "device not responding" ou LIBUSB_ERROR_TIMEOUT. Quem busca por "USB vendor request timeout", "bmRequestType debugging", "control transfer endpoint zero timeout" e "vendor-specific USB command failed" está lidando com uma falha em um protocolo privado que o SO não consegue explicar.

O Bus Scope ajuda porque toda requisição vendor-specific ainda tem um pacote de setup padrão. Mesmo que o significado do comando seja privado, a estrutura da transferência é visível.

Campos do pacote de setup

Uma control request inclui:

• bmRequestType
• bRequest
• wValue
• wIndex
• wLength

Para vendor requests, o bmRequestType identifica o tipo vendor e a direção. bRequest, wValue e wIndex são definidos pelo firmware do dispositivo.

Se a direção ou o tamanho estiver errado, o dispositivo pode travar ou dar timeout.

Timeout versus STALL

STALL significa que o dispositivo rejeitou a requisição de forma explícita. Timeout significa que o host não recebeu a conclusão dentro do tempo esperado.

Timeout pode significar:

• Firmware travou processando o comando.
• Dispositivo resetou durante a requisição.
• Direção errada.
• Host esperava dados, mas o dispositivo não mandou.
• Dispositivo esperava dados OUT, mas o host pediu IN.
• Comando só é válido em outro estado.
• Operação de erase na flash ou no sensor demorou demais.

O trace deve mostrar se houve data stage e se o dispositivo desapareceu depois.

Comandos de bootloader e update de firmware

Vendor requests frequentemente disparam entrada em bootloader, erase da flash, escrita de firmware, reset ou polling de status. Esses comandos podem legitimamente demorar, mas o timeout do host precisa casar com o comportamento esperado.

Se uma requisição sempre dá timeout antes de uma reconexão, o dispositivo pode na verdade estar resetando com sucesso. Se dá timeout e nunca reenumera, o firmware pode estar travado.

Checklist de depuração

Use este fluxo:

1. Capture antes de enviar o comando vendor.
2. Decodifique os campos do pacote de setup.
3. Confirme que a direção bate com o data stage esperado.
4. Confira o wLength.
5. Procure os bytes do data stage.
6. Procure STALL, timeout, reset ou desconexão.
7. Confira se o dispositivo reenumera em outro modo.
8. Compare a sequência de comandos com uma ferramenta sabidamente boa.
9. Aumente o timeout só depois de provar que o comando demora mais de fato.
10. Preserve a sequência de vendor request antes e depois da falha.

Diagnóstico final

Timeouts em vendor-specific control requests são falhas em um protocolo privado, mas a evidência USB continua visível. O pacote de setup, a direção, o tamanho, a temporização, o comportamento de reset e a resposta do endpoint zero mostram se a culpa é do formato da requisição do host ou do estado do firmware do dispositivo.

O Bus Scope ajuda a transformar uma falha de comando privado do firmware em evidência USB inspecionável.