STALL em endpoint USB e timeout em transferências bulk: leia a captura antes de mexer no firmware

Depois que a enumeração passa, um dispositivo USB ainda pode falhar de formas que parecem misteriosas para quem está na aplicação: "leituras bulk que dão timeout, escritas que nunca terminam, relatórios HID que param de chegar, ou o host anunciando um STALL no endpoint. Essas falhas costumam ser tratadas como bug de driver ou como travamento aleatório do firmware. Uma captura quase sempre reduz o problema a algo mais objetivo." Falhas de endpoint são evidência do caminho de dados. Elas acontecem depois que o host já aprendeu a forma do dispositivo. Isso significa que os descritores podem estar certos enquanto o comportamento do endpoint ainda está errado.

STALL é um sinal, não só um erro

Um endpoint USB pode devolver STALL para indicar que não consegue processar uma requisição ou que um comando de classe/vendor não é suportado. Stalls no endpoint de controle durante requisições de classe podem ser legítimos quando a requisição é inválida. Stalls em endpoints de dados durante o fluxo normal de transferência geralmente pedem uma investigação mais cuidadosa.

Perguntas para responder na captura:

• qual endpoint travou?
• era control, bulk, interrupt ou isochronous?
• qual requisição ou transferência veio antes do stall?
• o host limpou a condição de halt?
• o tráfego voltou ao normal depois do CLEAR_FEATURE(ENDPOINT_HALT)?
• o firmware travou de propósito comandos não suportados?

Sem esse contexto, "endpoint travou" é vago demais para agir.

Timeout em bulk precisa de direção e contexto de fila

Timeout em transferência bulk pode significar muitas coisas:

• o host esperava dados IN, mas o dispositivo não tinha nada pronto
• o dispositivo esperava dados OUT, mas a aplicação parou de escrever
• o buffer do endpoint no firmware não foi preparado
• o driver do host submeteu uma leitura maior do que o firmware sustenta
• o dispositivo ficou mandando NAK até o timeout
• endereço ou direção do endpoint estavam errados
• um stall anterior nunca foi limpo

A primeira coisa a inspecionar é a direção. Um timeout em bulk IN e um timeout em bulk OUT são casos diferentes. Para IN, pergunte se o dispositivo chegou a devolver algum dado. Para OUT, pergunte se o host enviou os dados e se o dispositivo confirmou.

Descritor certo é necessário, mas não suficiente

Um descritor pode declarar corretamente um endpoint bulk IN e o dispositivo ainda assim não consegue enviar dados úteis. Um dispositivo CDC pode aparecer como porta serial e ainda ignorar line coding ou control line state. Uma interface vendor pode expor endpoints, mas exigir um comando de inicialização antes de começar a trafegar.

Por isso, depurar endpoints exige combinar:

• evidência dos descritores
• requisições de setup de classe ou vendor
• direção da transferência
• tamanho do payload
• status resultante
• temporização e tentativas repetidas

A captura deve mostrar se o host está pedindo algo irrazoável ou se o firmware não está cumprindo uma requisição válida.

Equipes de firmware devem capturar antes e depois da correção

Para bugs de endpoint, capturas de antes e depois valem ouro. A primeira captura prova a falha. A segunda prova a correção. Uma boa comparação mostra:

• mesmo dispositivo e mesma configuração
• mesmos endereços de endpoint
• mesmo padrão de requisição do host
• captura antiga com stall ou timeout
• captura nova completando e levando o payload esperado

Isso facilita muito a revisão de regressão de firmware. E dá à equipe de suporte um artefato reproduzível quando o cliente diz que "o USB trava do nada".

Onde o Bus Scope entra

O Bus Scope mira na evidência USB, não em uma prateleira genérica de protocolos. Para casos de STALL e timeout de endpoint, ele mantém próximos o detalhe do pacote, os metadados do endpoint, os bytes brutos, o tipo de transferência e a interpretação de classe.

O resultado útil é:

• endpoint e direção
• tipo de transferência
• requisição ou transferência antes da falha
• evidência de status
• payload bruto em torno da falha
• se o problema vem da enumeração, do setup de classe ou do tráfego de aplicação

É essa a informação que o engenheiro de firmware precisa antes de mexer na lógica de buffer do endpoint ou no comportamento de retry do host.

Se a sua busca é "USB bulk transfer timeout" ou "USB endpoint stalled", não comece reescrevendo toda a pilha do dispositivo. Capture a evidência do endpoint primeiro.