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

A classic USB endpoint halt case works once, then a bulk endpoint stalls, libusb_clear_halt appears to recover it, and the next command enters the same USB STALL loop. The useful diagnosis is not merely “device disconnected,” but whether CLEAR_FEATURE(ENDPOINT_HALT) completed, the data toggle recovered, and the original command immediately halted the endpoint again. A bus trace can prove that recovery sequence and identify the affected endpoint; it cannot explain the firmware branch that chose to STALL without device-side context.

Bus Scope 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.

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