USB Endpoint Halt Recovery: CLEAR_FEATURE, STALL Loops, Bulk Failures, and Driver Reset Behavior

USB endpoint halts are a common source of "works once, then fails" device bugs. A bulk transfer stalls, the driver clears the halt, the device stalls again, and eventually the application reports timeout, I/O error, device reset, or disconnected. Users search for "USB endpoint halt", "CLEAR_FEATURE ENDPOINT_HALT", "USB STALL loop", "bulk endpoint stalled", and "libusb clear halt" when the device does not simply disappear but stops accepting traffic on a specific endpoint.

BusScope is useful because endpoint halt recovery is a sequence, not a single event. You need to see the first STALL, the host recovery request, what the device did afterward, and whether the same command caused the halt again.

What endpoint halt means

An endpoint halt means the endpoint is stalled and cannot continue normal transfers until the halt condition is cleared. The host may issue:

CLEAR_FEATURE(ENDPOINT_HALT)

to the affected endpoint. After that, the endpoint data toggle and device-side state may need to be consistent for transfer to resume correctly.

If firmware clears only the USB hardware flag but not its internal protocol state, the next transfer may fail again.

STALL vs timeout

STALL is explicit. Timeout means no completion within expected time. A timeout may happen because the endpoint never responded, the device kept NAKing, or the device disconnected.

Endpoint halt recovery starts with a STALL. If the host never sees a STALL and only sees timeout, the recovery path is different.

Bulk endpoint halt

Bulk endpoints often halt when a command is invalid, a protocol phase is wrong, or firmware detects an error.

Example:

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

This pattern suggests the endpoint halt is a symptom of device protocol state, not just a transient bus error.

Recovery must match endpoint direction

Endpoint addresses include direction. Endpoint 0x81 and endpoint 0x01 are different directions. Clearing the wrong endpoint will not recover the stalled pipe.

Check:

• Which endpoint stalled?
• Direction IN or OUT?
• Did host clear the same endpoint?
• Did transfers resume after clear?
• Did data toggle/state recover correctly?

This is a common source of misleading "clear halt did not work" reports.

Repeated STALL loops

Repeated STALL after clear usually means the underlying cause remains:

• Host sends unsupported command again.
• Firmware state machine remains in error.
• Device expects reset before retry.
• Host reads from wrong endpoint.
• Command length or checksum is wrong.
• Endpoint data toggle/state is inconsistent.
• Firmware requires a class/vendor request before resuming.

The trace should include the command before the first STALL, not only the recovery attempts.

Driver reset behavior

If clear-halt recovery fails, drivers may reset the device. That can hide the original endpoint error. The user sees a reconnect or device disappearance, but the bus evidence shows the real first failure was a STALL loop.

Preserve the timeline:

1. Last successful command.
2. First STALL.
3. Clear halt attempt.
4. Retry.
5. Repeated STALL or timeout.
6. Device reset or disconnect.

Debug checklist

Use this workflow:

1. Identify the endpoint that stalled.
2. Record endpoint direction and transfer type.
3. Inspect the command or transfer immediately before STALL.
4. Check whether host sends CLEAR_FEATURE(ENDPOINT_HALT).
5. Confirm it targets the correct endpoint.
6. Check whether transfer resumes.
7. If STALL repeats, inspect firmware protocol state.
8. Look for device reset after failed recovery.
9. Compare with a known-good command sequence.
10. Preserve enough context before the STALL.

Final diagnosis

USB endpoint halt recovery is a state-machine problem. CLEAR_FEATURE(ENDPOINT_HALT) can clear the USB endpoint condition, but it does not automatically fix firmware protocol state, invalid commands, wrong endpoints, or driver retry logic.

BusScope helps expose the full halt and recovery sequence so endpoint failures can be diagnosed from actual USB behavior.