Recuperación de halt en endpoints USB: CLEAR_FEATURE, bucles de STALL, fallos bulk y comportamiento de reset del driver

Los halts en endpoints USB son una fuente frecuente de bugs del estilo "funciona una vez y luego falla". Una bulk transfer se stalled, el driver limpia el halt, el dispositivo hace STALL otra vez y, al final, la aplicación reporta timeout, error de E/S, reset del dispositivo o desconexión. Los usuarios buscan "USB endpoint halt", "CLEAR_FEATURE ENDPOINT_HALT", "USB STALL loop", "bulk endpoint stalled" y "libusb clear halt" cuando el dispositivo no desaparece sin más, pero deja de aceptar tráfico en un endpoint concreto.

Bus Scope ayuda porque la recuperación de un halt es una secuencia, no un único evento. Necesitas ver el primer STALL, la petición de recuperación del host, qué hizo el dispositivo después y si el mismo comando volvió a causar el halt.

Qué significa endpoint halt

Un endpoint halt significa que el endpoint está stalled y no puede continuar con transferencias normales hasta que se limpie la condición de halt. El host puede emitir:

CLEAR_FEATURE(ENDPOINT_HALT)

sobre el endpoint afectado. Después, el data toggle del endpoint y el estado del lado del dispositivo tienen que ser consistentes para que la transferencia se reanude bien.

Si el firmware solo limpia el flag hardware del USB pero no su estado interno de protocolo, la siguiente transferencia puede volver a fallar.

STALL frente a timeout

STALL es explícito. Timeout significa que no hubo completion en el tiempo esperado. Un timeout puede pasar porque el endpoint nunca respondió, porque el dispositivo siguió haciendo NAK, o porque se desconectó.

La recuperación de un endpoint halt empieza con un STALL. Si el host nunca ve un STALL y solo ve un timeout, el camino de recuperación es distinto.

Halt en endpoint bulk

Los endpoints bulk suelen hacer halt cuando un comando es inválido, una fase del protocolo está mal, o el firmware detecta un error.

Ejemplo:

Host -> Device bulk OUT command
Device -> Host STALL on bulk IN
Host -> Device CLEAR_FEATURE(ENDPOINT_HALT)
Host retries bulk IN
Device stalls again

Este patrón sugiere que el halt es síntoma del estado de protocolo del dispositivo, no solo un error de bus transitorio.

La recuperación debe coincidir con la dirección del endpoint

Las direcciones de endpoint incluyen la dirección. El endpoint 0x81 y el 0x01 son direcciones distintas. Limpiar el endpoint equivocado no recupera el pipe stalled.

Comprueba:

• ¿Qué endpoint hizo STALL?
• ¿Dirección IN u OUT?
• ¿El host limpió el mismo endpoint?
• ¿Las transferencias se reanudaron tras el clear?
• ¿El data toggle y el estado se recuperaron bien?

Es una fuente frecuente de informes engañosos tipo "el clear halt no funcionó".

Bucles de STALL repetidos

Un STALL repetido tras el clear significa que la causa de fondo sigue ahí:

• El host vuelve a mandar un comando no soportado.
• El state machine del firmware sigue en error.
• El dispositivo espera un reset antes del reintento.
• El host lee desde el endpoint equivocado.
• La longitud o el checksum del comando están mal.
• El data toggle o el estado del endpoint son inconsistentes.
• El firmware requiere una class/vendor request antes de reanudar.

La traza debería incluir el comando anterior al primer STALL, no solo los intentos de recuperación.

Comportamiento de reset del driver

Si la recuperación con clear-halt falla, los drivers pueden resetear el dispositivo. Eso puede tapar el error original de endpoint. El usuario ve una reconexión o desaparición del dispositivo, pero la evidencia del bus muestra que el primer fallo real fue un bucle de STALL.

Conserva la línea de tiempo:

1. Último comando correcto.
2. Primer STALL.
3. Intento de clear halt.
4. Reintento.
5. STALL o timeout repetido.
6. Reset del dispositivo o desconexión.

Checklist de depuración

Usa este flujo:

1. Identifica el endpoint que hizo STALL.
2. Apunta la dirección del endpoint y el tipo de transferencia.
3. Inspecciona el comando o transferencia inmediatamente antes del STALL.
4. Comprueba si el host manda CLEAR_FEATURE(ENDPOINT_HALT).
5. Confirma que apunta al endpoint correcto.
6. Mira si la transferencia se reanuda.
7. Si el STALL se repite, inspecciona el estado del protocolo del firmware.
8. Busca un reset del dispositivo tras la recuperación fallida.
9. Compara con una secuencia de comandos conocida como buena.
10. Conserva suficiente contexto antes del STALL.

Diagnóstico final

La recuperación de halt en un endpoint USB es un problema de state machine. CLEAR_FEATURE(ENDPOINT_HALT) puede limpiar la condición USB del endpoint, pero no arregla automáticamente el estado de protocolo del firmware, los comandos inválidos, los endpoints equivocados ni la lógica de reintento del driver.

Bus Scope ayuda a exponer la secuencia completa de halt y recuperación para que los fallos de endpoint se diagnostiquen desde el comportamiento USB real.