Timeout em bulk transfer USB: high-speed, full-speed, STALL, NAK e delays de firmware

Bulk transfers em USB são usados quando a correção importa mais que a temporização fixa. Dispositivos de armazenamento, adaptadores seriais, probes de debug, atualizadores de firmware, scanners, dispositivos vendor e muitos produtos de aquisição de dados usam endpoints bulk. Quando falham, a busca é por "USB bulk transfer timeout", "bulk endpoint stalled", "USB read timeout", "USB write timeout", "libusb bulk transfer failed" e "USB device stops responding during bulk transfer".

A aplicação geralmente vê um timeout ou I/O error. O barramento pode contar uma história mais rica: o dispositivo NAKou demais, o endpoint travou, o host retentou, o dispositivo resetou, o tamanho da transferência estava errado, a velocidade do dispositivo ficou abaixo do esperado ou o firmware bloqueou preparando dados.

O Bus Scope ajuda porque falhas em bulk transfer precisam de evidência em nível de endpoint, não só de stack trace da aplicação.

Onde o bulk brilha

Bulk transfers são confiáveis no nível de protocolo USB. Eles usam a banda disponível e podem retentar. São bons para mover grandes volumes de dados onde a latência pode ser menos crítica que a correção.

Dispositivos comuns com bulk:

• USB mass storage
• adaptadores seriais CDC
• ferramentas vendor de firmware
• probes de debug
• dispositivos de medição
• impressoras e scanners
• alguns dispositivos de captura
• pipes de dados de FPGA ou microcontrolador

Como bulk usa a banda que sobra, a performance pode variar conforme o tráfego USB e o agendamento do host.

Timeout nem sempre significa perda de pacote

Um timeout em bulk transfer normalmente significa que a requisição no host não terminou dentro do timeout da aplicação. Isso pode acontecer mesmo com o barramento se comportando dentro da lei.

Causas comuns:

• Dispositivo sem dados prontos, NAKando.
• Firmware ocupado, atrasando a resposta.
• Endpoint halted depois de um STALL.
• Host mandou a requisição para o endpoint errado.
• Tamanho da transferência não bate com a expectativa do protocolo.
• Dispositivo resetou ou desconectou.
• Driver submeteu a transferência errado.
• Caminho full-speed lento demais para a vazão esperada.
• Outro dispositivo consumindo banda do barramento.
• Timeout da aplicação agressivo demais.

O trace deve mostrar qual dessas é plausível.

Comportamento de NAK

Dispositivos USB podem responder com NAK para indicar que ainda não estão prontos. NAK não é necessariamente erro. É um sinal de controle de fluxo.

Para um endpoint bulk IN, NAKs repetidos podem significar que o dispositivo ainda não tem dados. Para um endpoint bulk OUT, NAKs podem significar que o dispositivo ainda não pode aceitar mais dados.

O problema é a duração e o contexto. Alguns NAKs são normais. NAKs contínuos até o timeout da aplicação significam que o dispositivo nunca ficou pronto ou que o host esperou dados na hora errada.

STALL e halt de endpoint

STALL é diferente de NAK. Geralmente significa que o endpoint travou ou que a requisição não é suportada naquele contexto. A recuperação normalmente exige:

CLEAR_FEATURE(ENDPOINT_HALT)

Se o host não limpa o halt, transferências posteriores podem continuar falhando. Se o endpoint trava de novo imediatamente depois de limpo, o firmware do dispositivo pode estar rejeitando a sequência de comandos.

Procure por:

• Primeiro STALL antes do timeout.
• CLEAR_FEATURE(ENDPOINT_HALT).
• Se a transferência voltou depois do clear.
• Mesmo comando causando STALL toda vez.
• Reset depois de STALLs repetidos.

Expectativas de high-speed versus full-speed

A velocidade do USB muda a vazão realista. Um dispositivo em full-speed não entrega vazão de high-speed. Um dispositivo capaz de high-speed pode regredir por causa de cabo, hub, porta, integridade de sinal ou negociação do dispositivo.

Se a aplicação assume performance de high-speed, mas o dispositivo enumerou em full-speed, timeouts podem aparecer em transferências grandes.

Confira descritores, velocidade negociada, max packet size do endpoint e o pacing real. Não deduza velocidade pelo formato do conector ou pelo rótulo de marketing.

Protocolos de comando sobre bulk

Muitos dispositivos bulk implementam um protocolo de comando e resposta em cima do USB. O host escreve um comando em bulk OUT e espera dados em bulk IN.

Timeouts acontecem quando:

• Formato do comando está errado.
• Dispositivo espera uma control request antes do bulk.
• Dispositivo manda status em outro endpoint.
• Host lê rápido demais.
• Host lê demais.
• Firmware bloqueia processando o comando.
• Dispositivo exige boundary de zero-length packet.
• Estado de erro anterior não foi limpo.

Evidência de pacote pode mostrar se o dispositivo ignorou o comando, travou, aceitou mas nunca respondeu, ou respondeu em outro endpoint.

Tamanho do bulk e short packets

Protocolos USB bulk frequentemente usam short packets para sinalizar fim de transferência. Se o host espera um tamanho fixo, mas o dispositivo manda um short packet, a aplicação pode interpretar errado. Se o host espera mais dados depois do dispositivo já ter encerrado, um timeout pode aparecer na camada de aplicação.

Procure por:

• Tamanho requisitado da transferência.
• Tamanho efetivamente devolvido.
• Short packet.
• Zero-length packet.
• Framing de protocolo acima do USB.

Isso é especialmente importante em firmware custom e ferramentas baseadas em libusb.

Checklist de depuração

Use este processo:

1. Capture a enumeração e os descritores de endpoint.
2. Confirme a velocidade do dispositivo e o max packet size do endpoint.
3. Identifique endpoints bulk IN e bulk OUT.
4. Capture o comando ou a transferência que deu timeout.
5. Confira se o endpoint devolve NAK, STALL, dados ou desconexão.
6. Inspecione a recuperação por CLEAR_FEATURE(ENDPOINT_HALT) se ocorrer STALL.
7. Compare o tamanho requisitado e o tamanho efetivo.
8. Confira se o dispositivo manda short packet ou zero-length packet.
9. Compare porta direta versus hub e caminho high-speed versus full-speed.
10. Correlacione com logs do firmware, se houver.

Diagnóstico final

Timeout em bulk transfer USB não é um único bug. Pode ser NAK normal que estourou o timeout da aplicação, STALL não recuperado, firmware que não respondeu, velocidade abaixo do esperado, framing de protocolo errado ou reset do dispositivo.

O Bus Scope ajuda expondo a sequência em nível de endpoint, para que um timeout vire evidência USB diagnosticável em vez de uma falha genérica de I/O.