STALL en endpoint y timeout en bulk transfer USB: leyendo la captura antes de tocar el firmware

Tras una enumeración correcta, los dispositivos USB pueden seguir fallando de formas que parecen misteriosas al desarrollador: "lecturas bulk con timeout, escrituras que nunca terminan, HID reports que dejan de llegar o el host reportando un STALL en el endpoint. Esas fallas se tratan a menudo como bugs del driver o cuelgues aleatorios del firmware. Una captura suele acotar el problema mucho antes." Los fallos de endpoint son evidencia del data path. Ocurren después de que el host ha aprendido la forma del dispositivo. Eso significa que los descriptores pueden ser correctos y aun así el endpoint comportarse mal.

STALL es una señal, no solo un error

Un endpoint USB puede devolver STALL para indicar que no puede procesar una petición o que un comando class/vendor no está soportado. Los stalls del endpoint de control durante class requests pueden ser legítimos si la petición es inválida. Los stalls de endpoints de datos durante el flujo normal de transferencia suelen requerir inspección más detallada.

Preguntas para la captura:

• ¿Qué endpoint hizo stall?
• ¿Era control, bulk, interrupt o isochronous?
• ¿Qué petición o transferencia precedió al stall?
• ¿El host limpió la condición de halt?
• ¿Se reanudó el tráfico tras CLEAR_FEATURE(ENDPOINT_HALT)?
• ¿El firmware hizo stall a propósito en comandos no soportados?

Sin ese contexto, "endpoint stalled" es demasiado vago para actuar.

Los timeouts en bulk necesitan contexto de dirección y cola

Un timeout en bulk transfer puede significar muchas cosas:

• El host esperaba datos IN pero el dispositivo no tenía ninguno listos.
• El dispositivo esperaba datos OUT pero la aplicación dejó de escribir.
• El buffer del endpoint en firmware no estaba armado.
• El driver del host envió una read más grande de lo que soporta el firmware.
• El dispositivo hizo NAK hasta el timeout.
• La dirección o el endpoint eran incorrectos.
• Un stall previo no se había limpiado.

Lo primero a inspeccionar es la dirección. Un timeout en bulk IN y un timeout en bulk OUT son casos distintos. Para IN, mira si el dispositivo llegó a devolver datos. Para OUT, mira si el host mandó datos y si el dispositivo los acusó.

Que el descriptor sea correcto es necesario, pero no suficiente

Un descriptor puede declarar bien un endpoint bulk IN y aun así el dispositivo no enviar datos útiles. Un dispositivo CDC puede enumerar como puerto serie y aun así ignorar el line coding o el control line state. Una interfaz vendor-specific puede exponer endpoints pero requerir un comando de inicialización antes de mover datos.

Eso significa que la depuración de endpoints tiene que combinar:

• Evidencia de descriptor.
• Class o vendor setup requests.
• Dirección de la transferencia.
• Longitud del payload.
• Resultado de status.
• Timing e intentos repetidos.

La captura debería enseñar si el host está pidiendo algo irrazonable o si el firmware no está cumpliendo una petición válida.

Los equipos de firmware deberían capturar antes y después del fix

Para bugs de endpoint, las capturas antes y después valen mucho. La primera prueba el fallo. La segunda prueba el fix. Una buena comparación enseña:

• Mismo dispositivo y configuración.
• Mismas direcciones de endpoint.
• Mismo patrón de peticiones del host.
• La captura vieja hace stall o timeout.
• La captura nueva completa y lleva el payload esperado.

Eso facilita mucho la revisión de regresiones de firmware. También da al equipo de soporte un artefacto repetible cuando los clientes reportan que "el USB se queda colgado al azar".

Dónde encaja Bus Scope

Bus Scope está orientado a evidencia USB, no a proliferación genérica de protocolos. Para STALLs y timeouts en endpoints, debería mantener cerca el detalle del paquete, los metadatos del endpoint, los bytes en crudo, el tipo de transferencia y la interpretación de clase.

La salida útil es:

• Endpoint y dirección.
• Tipo de transferencia.
• Petición o transferencia antes del fallo.
• Evidencia de status.
• Payload en crudo alrededor del fallo.
• Si el problema sigue a la enumeración, al setup de clase o al tráfico de aplicación.

Esa es la información que necesitan los ingenieros de firmware antes de tocar la lógica de buffer del endpoint o el comportamiento de reintentos del host.

Si tu búsqueda es "USB bulk transfer timeout" o "USB endpoint stalled", no empieces reescribiendo todo el stack del dispositivo. Captura primero la evidencia del endpoint.