2026-06-03

Depuración del status stage en transferencias de control USB

Cómo depurar problemas en el status stage de las transferencias de control USB, zero-length packets, STALLs en endpoint cero, secuenciación SETUP/DATA/STATUS, peticiones de descriptor y fallos de comandos vendor.

Las transferencias de control USB parecen simples hasta que un dispositivo falla en el status stage. Los usuarios buscan "USB control transfer status stage", "zero length packet USB", "endpoint zero stall", "SETUP DATA STATUS USB", "control transfer timeout" y "vendor request fails" cuando los descriptores funcionan pero un comando hace STALL o se queda en timeout.

Bus Scope ayuda porque los fallos de transferencia de control exigen ver todas las etapas juntas. El setup packet por sí solo no basta. El data stage y el status stage demuestran si el host y el dispositivo completaron la transacción.

Etapas de una transferencia de control

Una transferencia de control suele tener:

SETUP stage.
DATA stage opcional.
STATUS stage.

El status stage usa a menudo un zero-length packet en la dirección opuesta al data stage. Confirma que la transferencia terminó.

Si el status stage falla, el host puede reportar un timeout aunque el dispositivo ya haya intercambiado algunos datos.

Confusión con zero-length packets

Un zero-length packet no es automáticamente "sin datos" en el sentido de aplicación. En transferencias de control, puede ser el handshake de status obligatorio.

Errores típicos:

El firmware no hace ACK del status stage.
El host espera un status packet zero-length y recibe STALL.
El dispositivo manda datos cuando el status debería ir vacío.
Un comando vendor completa el data stage pero falla el handshake final.
El state machine del firmware se olvida de armar el endpoint cero.

Estos bugs son frecuentes en comandos vendor a medida y en bootloaders.

El endpoint cero es especial

El endpoint cero se encarga de la enumeración y de las peticiones de control. Si su estado se corrompe, el dispositivo entero puede volverse inestable.

Síntomas:

La enumeración empieza pero falla en un descriptor posterior.
Un vendor request funciona una vez y luego hace STALL.
El dispositivo necesita desenchufarse y volverse a enchufar tras una transferencia de control.
SET_ADDRESS o SET_CONFIGURATION son poco fiables.
HID Feature Report por control path falla.
DFU detach devuelve respuesta pero el dispositivo nunca cambia de modo.

Bus Scope debería enseñar si el endpoint cero se recuperó tras un STALL o se quedó roto.

Transferencias de control IN frente a OUT

La dirección del control cambia la dirección del status stage.

Para una petición IN:

El host manda SETUP.
El dispositivo manda DATA.
El host manda status OUT zero-length packet.

Para una petición OUT:

El host manda SETUP.
El host manda DATA si hay.
El dispositivo manda status IN zero-length packet.

Los bugs de firmware ocurren a menudo cuando una dirección se prueba más que la otra.

Fallos en descriptores frente a comandos vendor

Las peticiones de descriptor estándar suelen funcionar porque pasan por caminos de firmware bien probados. Las vendor-specific requests pueden fallar porque un handler a medida maneja mal la longitud, la dirección o el status stage.

Evidencia:

bmRequestType.
bRequest.
wValue.
wIndex.
wLength.
Longitud real de datos.
Resultado del status stage.
STALL, NAK, timeout o reset.

Los campos del setup packet deben interpretarse junto con el comportamiento observado de cada etapa.

Checklist de depuración

Usa este flujo:

Captura la transferencia de control completa.
Decodifica los campos del SETUP.
Identifica la dirección de la transferencia.
Comprueba la longitud esperada de datos.
Verifica los bytes del data stage.
Verifica la dirección del status stage.
Busca el zero-length packet.
Comprueba STALL o timeout.
Compara peticiones standard y vendor.
Conserva el comportamiento de recuperación del endpoint cero.

Diagnóstico final

Los fallos en transferencias de control USB son con frecuencia fallos en el status stage, no solo en el setup packet. Importan los zero-length packets, el estado del endpoint cero, la dirección y el handshake final.

Bus Scope ayuda a los ingenieros a demostrar si un dispositivo falló durante SETUP, DATA, STATUS, manejo de ZLP, recuperación del endpoint cero o procesamiento del comando vendor.

Prueba del contrato USB para «Depuración del status stage en transferencias de control USB»

La respuesta directa es que STALL, timeout o reset no explica por sí solo la causa. Primero demuestra que el proveedor observa el dispositivo correcto; después lee el contrato de transferencia: tipo, dirección, recipient, wValue, wIndex, longitud declarada y real, status y estado anterior y posterior. En «Depuración del status stage en transferencias de control USB», relaciona la conclusión con la primera transacción que difiere de un caso bueno.

Límite	Qué comparar	Decisión útil
Plataforma	proveedor, permiso, Root Hub o usbmon/XHC20	¿Llegan records de la conexión correcta?
Setup	bmRequestType, bRequest, wValue, wIndex, wLength	¿El host envía la petición prevista?
Data	dirección, longitud y bytes retenidos	¿El payload cumple el contrato?
Status	ACK, STALL, timeout o cancellation	¿Dónde termina la transacción?
Estado	configuration, interface, alternate setting, endpoint halt	¿El dispositivo estaba preparado?

Empieza antes de reset y enumeración y conserva descriptors, SET_CONFIGURATION, SET_INTERFACE y el comando previo al fallo. Un filtro estrecho de endpoint puede ocultar el control transfer decisivo. Ejecuta una sola acción USB documentada por prueba y cambia solo firmware, driver, puerto, cable, comando o timing.

¿Cómo se escribe una respuesta citable?

Indica la petición observada, sus campos setup, la respuesta y el contexto anterior; propone después una prueba con un solo cambio. Bytes no retenidos por el límite de captura no prueban packet loss. La proximidad entre command y reset demuestra correlación, no causa sin repetición o transición de estado.

¿Cuándo vale una comparación?

Mantén VID/PID, firmware, speed, topología, proveedor, filtro y trigger. Compara fases USB semánticas y no frame numbers entre usbmon y USBPcap. Anota inicio, final, versión, OS, conexión y checksum. Revisa la solución de problemas de Bus Scope.

Los propietarios Semrush siguen separados: free USB analyzer en la página de producto, best USB protocol analyzer en la comparación y USB descriptor viewer en la guía de descriptors. Esta página de soporte no recibe volumen o KD inventado.

Respuesta directa y límite de aceptación

La respuesta breve a «Depuración del status stage en transferencias de control USB» es: Cómo depurar problemas en el status stage de las transferencias de control USB, zero-length packets, STALLs en endpoint cero, secuenciación SETUP/DATA/STATUS, peticiones de descriptor y fallos de comandos vendor. Trate esa frase como un resultado que debe comprobarse, no como una promesa para cualquier entrada, dispositivo, proyecto o entorno. Un resultado completo registra estado inicial, acción exacta, salida visible y condición que demuestra que la tarea terminó en Bus Scope.

Procedimiento basado en evidencia

Empiece con un caso pequeño y repetible antes de cambiar un proyecto completo. Anote versión de la aplicación, sistema operativo, identidad de entrada o dispositivo, ajustes relevantes y resultado esperado. Ejecute una acción deliberada, conserve la primera transición inesperada y compárela con un caso conocido cuando exista. Cambiar varios controles a la vez oculta qué condición creó o corrigió el problema.

Punto de control 1: Depuración del status stage en transferencias de control USB

Si «Depuración del status stage en transferencias de control USB» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 2: Cómo depurar problemas en el status stage de las transferencias de control USB, zero-lengt

Compruebe «Cómo depurar problemas en el status stage de las transferencias de control USB, zero-length packets, STALLs en endpoint cero, secuenciación SETUP/DATA» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 3: Etapas de una transferencia de control

Si «Etapas de una transferencia de control» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 4: Confusión con zero-length packets

Compruebe «Confusión con zero-length packets» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 5: El endpoint cero es especial

Si «El endpoint cero es especial» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 6: Transferencias de control IN frente a OUT

Compruebe «Transferencias de control IN frente a OUT» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 7: Fallos en descriptores frente a comandos vendor

Si «Fallos en descriptores frente a comandos vendor» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 8: Checklist de depuración

Compruebe «Checklist de depuración» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 9: Diagnóstico final

Si «Diagnóstico final» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 10: Prueba del contrato USB para «Depuración del status stage en transferencias de control USB

Compruebe «Prueba del contrato USB para «Depuración del status stage en transferencias de control USB»» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Depuración del status stage en transferencias de control USB	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo depurar problemas en el status stage de las transferencias de control USB, zero-length packets, STALLs en endpoint	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Etapas de una transferencia de control	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Confusión con zero-length packets	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
El endpoint cero es especial	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Transferencias de control IN frente a OUT	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado

Aislamiento, recuperación y entrega

Deténgase en el primer límite que falla. Conserve fuente, proyecto, sesión o captura, duplíquelo antes de una edición destructiva y cambie una variable por experimento. Repetir un flujo amplio después de varios cambios puede dar otro resultado sin explicar la causa.

Separe ausencia de evidencia de evidencia de ausencia. Una vista vacía puede indicar entrada, alcance, filtro, permiso, dispositivo, intervalo o estado equivocado. Verifique adquisición o importación antes de interpretar el decoder, editor, informe o exportación.

Antes de entregar, reabra el artefacto y revise inicio, punto de decisión y final. Registre versión, plataforma, configuración, expectativa, observación y reproducción mínima. Elimine o redacte datos sensibles y confirme que el destinatario está autorizado.

Preguntas y respuestas

¿Cuál es la forma fiable más rápida de empezar?

Use el caso representativo más pequeño, escriba el resultado esperado y cambie una variable. Confirme el recorrido básico antes de añadir filtros, efectos, ediciones, automatización o una fuente mayor.

¿Qué evidencia debe guardarse?

Conserve identidad de entrada, versión, plataforma, ajustes, acción exacta, primera transición inesperada y salida final. Cierre y reabra cualquier proyecto, sesión, informe o exportación antes de considerarlo duradero.

¿Cuándo debe repetirse el procedimiento?

Repítalo después de cambios relevantes en aplicación, sistema, driver, firmware, modelo, fuente o flujo. Preserve el caso aceptado anterior como referencia sin modificar.

¿Cuándo está listo para entregar?

Cuando otra persona autorizada identifica la entrada, repite la acción, obtiene el mismo resultado, entiende los límites restantes y abre el artefacto sin depender de estado local no documentado.

Guías relacionadas

Estas páginas en el mismo idioma cubren etapas contiguas sin cambiar el propietario canónico del tema: