2026-06-03

Depuração do status stage em transferências de controle USB: zero-length packets, endpoint zero e stalls

Como depurar problemas de status stage em transferências de controle USB, zero-length packets, stalls no endpoint zero, sequência SETUP/DATA/STATUS, requisições de descritor e falhas de vendor command.

Transferências de controle USB parecem simples até o dispositivo falhar no status stage. Buscas como "USB control transfer status stage", "zero length packet USB", "endpoint zero stall", "SETUP DATA STATUS USB", "control transfer timeout" e "vendor request fails" acontecem quando os descritores funcionam, mas um comando trava ou dá timeout.

O Bus Scope ajuda porque falhas em control transfer exigem ver as etapas juntas. Só o pacote de setup não basta. O data stage e o status stage provam se o host e o dispositivo completaram a transação.

Etapas da control transfer

Uma control transfer costuma ter:

SETUP stage.
DATA stage opcional.
STATUS stage.

O status stage geralmente usa um zero-length packet na direção oposta ao data stage. Ele confirma a conclusão.

Se o status stage falha, o host pode reportar timeout mesmo que o dispositivo já tenha trocado alguns dados.

Confusão com zero-length packet

Um zero-length packet não significa automaticamente "sem dados" no sentido de aplicação. Em control transfers, ele pode ser o handshake obrigatório de status.

Erros comuns:

Firmware não dá ACK no status stage.
Host espera um zero-length status packet e recebe STALL.
Dispositivo envia dados quando o status deveria estar vazio.
Vendor command completa o data stage mas falha no handshake final.
Máquina de estado do firmware esquece de armar o endpoint zero.

Esses bugs são comuns em vendor commands custom e bootloaders.

Endpoint zero é especial

Endpoint zero cuida da enumeração e das control requests. Se o estado do endpoint zero for corrompido, o dispositivo inteiro pode ficar instável.

Sintomas:

A enumeração começa, mas falha em um descritor mais adiante.
Vendor request funciona uma vez e depois trava.
Dispositivo precisa tirar e recolocar o cabo depois de uma control transfer.
SET_ADDRESS ou SET_CONFIGURATION é instável.
HID Feature Report pelo caminho de controle falha.
DFU detach request volta, mas o dispositivo nunca muda de modo.

O Bus Scope deve mostrar se o endpoint zero se recuperou depois de um stall ou se continuou quebrado.

IN versus OUT em control transfers

A direção da control transfer muda a direção do status stage.

Para uma requisição IN:

Host envia SETUP.
Dispositivo envia DATA.
Host envia status OUT zero-length packet.

Para uma requisição OUT:

Host envia SETUP.
Host envia DATA, se houver.
Dispositivo envia status IN zero-length packet.

Bugs de firmware costumam aparecer quando uma direção é testada mais do que a outra.

Falhas em descritor versus vendor command

Requisições de descritor padrão podem funcionar porque usam caminhos de firmware bem testados. Vendor-specific requests podem falhar porque um handler custom trata errado length, direção ou status stage.

Evidência:

bmRequestType.
bRequest.
wValue.
wIndex.
wLength.
Tamanho real do data stage.
Resultado do status stage.
STALL, NAK, timeout ou reset.

Os campos do pacote de setup precisam ser interpretados junto com o comportamento observado de cada etapa.

Checklist de depuração

Use este fluxo:

Capture a control transfer completa.
Decodifique os campos do SETUP.
Identifique a direção da transferência.
Confira o tamanho de dado esperado.
Verifique os bytes do data stage.
Verifique a direção do status stage.
Procure o zero-length packet.
Confira STALL ou timeout.
Compare requisições standard e vendor.
Preserve o comportamento de recuperação do endpoint zero.

Diagnóstico final

Falhas em control transfer USB são, com frequência, falhas no status stage, não só problemas de pacote de setup. Zero-length packets, estado do endpoint zero, direção e handshake final importam.

O Bus Scope ajuda o engenheiro a provar se um dispositivo falhou no SETUP, no DATA, no STATUS, no tratamento de ZLP, na recuperação do endpoint zero ou no processamento do vendor command.

Teste do contrato USB para “Depuração do status stage em transferências de controle USB: zero-length packets, endpoint zero e stalls”

A resposta direta é que STALL, timeout ou reset não explica sozinho a causa. Primeiro prove que o provider vê o device correto; depois leia o contrato do transfer: tipo, direção, recipient, wValue, wIndex, comprimento declarado e real, status e estado anterior e posterior. Ligue a conclusão à primeira transação diferente do caso bom.

Limite	Comparação	Decisão
Plataforma	provider, permissão, Root Hub ou usbmon/XHC20	Os records são da conexão correta?
Setup	bmRequestType, bRequest, wValue, wIndex, wLength	O host enviou o pedido esperado?
Data	direção, comprimento e bytes retidos	O payload cumpre o contrato?
Status	ACK, STALL, timeout ou cancellation	Onde a transação termina?
Estado	configuration, interface, alternate setting, halt	O device estava pronto?

Comece antes de reset e enumeration e preserve descriptors, SET_CONFIGURATION, SET_INTERFACE e o command anterior à falha. Filtro estreito pode esconder o control transfer decisivo. Execute uma ação USB por teste e altere apenas firmware, driver, porta, cabo, comando ou timing.

Como escrever resposta citável?

Informe request, campos setup, resposta e contexto anterior; depois proponha teste com uma variável. Bytes não retidos não provam packet loss. Proximidade entre command e reset mostra correlação, não causa sem repetição ou mudança de estado.

Mantenha VID/PID, firmware, speed, topologia, provider, filtro e trigger. Compare fases USB semânticas, não frame numbers entre usbmon e USBPcap. Registre início, fim, versão, OS, conexão e checksum. Consulte o troubleshooting Bus Scope.

Os owners Semrush continuam separados: free USB analyzer na página do produto, best USB protocol analyzer na comparação e USB descriptor viewer no guia descriptor. Não invente volume ou KD.

Resposta direta e limite de aceitação

A resposta curta para “Depuração do status stage em transferências de controle USB: zero-length packets, endpoint zero e stalls” é: Como depurar problemas de status stage em transferências de controle USB, zero-length packets, stalls no endpoint zero, sequência SETUP/DATA/STATUS, requisições de descritor e falhas de vendor command. Trate essa frase como um resultado a verificar, não como promessa para qualquer entrada, dispositivo, projeto ou ambiente. Um resultado completo registra estado inicial, ação exata, saída visível e condição que comprova a conclusão da tarefa no Bus Scope.

Procedimento orientado por evidências

Comece com um caso pequeno e repetível antes de alterar um projeto completo. Registre versão do aplicativo, sistema operacional, identidade da entrada ou dispositivo, configurações relevantes e resultado esperado. Execute uma ação deliberada, preserve a primeira transição inesperada e compare com um caso conhecido quando possível. Alterar vários controles ao mesmo tempo esconde qual condição criou ou corrigiu o problema.

Ponto de controle 1: Depuração do status stage em transferências de controle USB: zero-length packets, endpoint

Quando “Depuração do status stage em transferências de controle USB: zero-length packets, endpoint zero e stalls” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 2: Como depurar problemas de status stage em transferências de controle USB, zero-length pack

Verifique “Como depurar problemas de status stage em transferências de controle USB, zero-length packets, stalls no endpoint zero, sequência SETUP/DATA/STATUS, r” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 3: Etapas da control transfer

Quando “Etapas da control transfer” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 4: Confusão com zero-length packet

Verifique “Confusão com zero-length packet” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 5: Endpoint zero é especial

Quando “Endpoint zero é especial” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 6: IN versus OUT em control transfers

Verifique “IN versus OUT em control transfers” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 7: Falhas em descritor versus vendor command

Quando “Falhas em descritor versus vendor command” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 8: Checklist de depuração

Verifique “Checklist de depuração” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 9: Diagnóstico final

Quando “Diagnóstico final” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 10: Teste do contrato USB para “Depuração do status stage em transferências de controle USB: z

Verifique “Teste do contrato USB para “Depuração do status stage em transferências de controle USB: zero-length packets, endpoint zero e stalls”” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Matriz de aceitação

Ponto	Evidência a manter	Condição de aprovação
Depuração do status stage em transferências de controle USB: zero-length packets, endpoint zero e stalls	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Como depurar problemas de status stage em transferências de controle USB, zero-length packets, stalls no endpoint zero,	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Etapas da control transfer	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Confusão com zero-length packet	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Endpoint zero é especial	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
IN versus OUT em control transfers	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado

Isolamento, recuperação e entrega

Pare no primeiro limite que falhar. Preserve fonte, projeto, sessão ou captura, duplique antes de edição destrutiva e altere uma variável por experimento. Repetir um fluxo amplo depois de várias mudanças pode gerar outro resultado sem explicar o motivo.

Separe ausência de evidência de evidência de ausência. Uma tela vazia pode indicar entrada, escopo, filtro, permissão, dispositivo, intervalo ou estado incorreto. Verifique aquisição ou importação antes de interpretar decoder, editor, relatório ou exportação.

Antes da entrega, reabra o artefato e examine início, ponto de decisão e final. Registre versão, plataforma, configuração, expectativa, observação e reprodução mínima. Remova ou oculte dados sensíveis e confirme a autorização do destinatário.

Perguntas e respostas

Qual é a maneira confiável mais rápida de começar?

Use o menor caso representativo, escreva o resultado esperado e altere uma variável. Confirme o caminho básico antes de adicionar filtros, efeitos, edições, automação ou uma fonte maior.

Quais evidências devem ser salvas?

Mantenha identidade da entrada, versão, plataforma, configurações, ação exata, primeira transição inesperada e saída final. Feche e reabra projeto, sessão, relatório ou exportação antes de tratá-lo como durável.

Quando o procedimento deve ser repetido?

Repita após mudanças relevantes no aplicativo, sistema, driver, firmware, modelo, fonte ou fluxo. Preserve o caso aceito anterior como referência sem alterações.

Quando a tarefa está pronta para entrega?

Quando outra pessoa autorizada identifica a entrada, repete a ação, vê o mesmo resultado, entende os limites restantes e abre o artefato sem depender de estado local não documentado.

Guias relacionados

Estas páginas no mesmo idioma cobrem etapas próximas sem alterar o proprietário canônico deste assunto: