2026-06-02

USB Endpoint STALL and Bulk Transfer Timeout

Diagnose USB endpoint STALL and bulk transfer timeout failures by separating direction, halt state, NAK delay, queue ownership, recovery, reset, and application deadlines.

A USB endpoint STALL and a bulk transfer timeout are not interchangeable diagnoses. A STALL is an explicit endpoint response and can place a non-control endpoint into a halted state. A timeout is usually a host software deadline: the requested transfer did not finish before the caller stopped waiting. A long stream of NAK responses, missing firmware buffers, an unhandled command, a lost device, or an uncleared halt can all surface as a timeout.

Direct answer: identify the exact endpoint, direction, transfer type, first abnormal response, and host deadline. Determine whether the device explicitly stalled, kept returning no-ready-data behavior, disconnected, or stopped receiving requests. If the endpoint halted, trace CLEAR_FEATURE(ENDPOINT_HALT) and the first transfer after recovery. If no STALL occurred, inspect queue ownership, protocol preconditions, payload framing, and timing instead of treating a timeout as a halt.

Bus Scope can preserve USB transfer status, raw payloads, endpoint metadata, and the sequence around failure. It cannot prove why a user-space thread missed its own deadline when the USB requests completed normally, so pair the trace with application and driver timing when required.

First classify the observed failure

Start with evidence, not the error string:

Observation	What it proves	What to inspect next
Endpoint returns STALL	device or controller reported a stall condition	request validity, firmware state, halt recovery
Repeated not-ready behavior, then API timeout	transfer did not complete before software deadline	device queue, command precondition, timeout policy
No bus request after application call	request may be blocked above the bus	driver queue, handle, interface claim, application thread
Device reset or disconnect	previous endpoint context was lost	power, firmware reset, topology, re-enumeration
Transfer completes on USB but app times out	bus is not the failing layer	driver completion, parser, thread scheduling
Wrong endpoint receives traffic	descriptor or application selection mismatch	interface map and endpoint address

This table prevents a common failure: changing endpoint-halt code when the trace contains no STALL at all.

Name the endpoint precisely

An endpoint number without direction is ambiguous. Endpoint 0x81 means endpoint 1 IN; 0x01 means endpoint 1 OUT. Record:

endpoint address;
IN or OUT direction;
owning interface and alternate setting;
bulk, interrupt, control, or isochronous type;
negotiated device speed;
maximum packet size;
first failed transfer index and timestamp.

For bulk IN, the host asks and the device supplies data. For bulk OUT, the host supplies data and the device accepts it. The same application phrase—"read timeout"—can represent no IN data, no request submitted, an earlier command not accepted, or a device that disappeared.

Use the USB descriptor viewer workflow to validate endpoint ownership before debugging queue logic.

What an endpoint STALL means

A device can stall because a request or command is unsupported, invalid in the current state, malformed, or impossible to complete. For a class or vendor protocol, the specification or product contract determines whether that STALL is correct.

Separate two questions:

Why did this transfer stall?
What state did the endpoint enter afterward?

A non-control bulk or interrupt endpoint can remain halted until the host clears the halt condition. Firmware and host must also resynchronize data-toggle state as required by the USB recovery mechanism. Repeatedly resubmitting the same transfer without recovery can reproduce the same failure indefinitely.

Endpoint zero behaves differently because each new setup packet starts a new control request context. Use the dedicated USB control transfer STALL guide for setup-packet analysis.

Follow the halt recovery sequence

When the trace shows an endpoint STALL, look for this evidence:

the exact transfer and payload immediately before the STALL;
the endpoint that stalled;
cancellation or completion of queued host transfers;
a standard CLEAR_FEATURE(ENDPOINT_HALT) request;
the endpoint address encoded in wIndex;
successful status stage for the clear request;
the first data transfer after the clear;
reset or reconfiguration if clearing the halt did not recover.

Build a compact recovery table:

Step	Endpoint/request	Result	Interpretation
command OUT	`0x02`	completes	command reached device
response IN	`0x82`	STALL	response path halted
clear halt	endpoint `0x82`	completes	host attempted recovery
response IN retry	`0x82`	completes	halt recovery worked

If the clear request names 0x02 while the stalled endpoint was 0x82, direction was lost. If the clear completes but firmware retains its application error state, the endpoint may accept traffic while the higher-level command still fails. Clearing halt repairs endpoint transport state; it does not guarantee the command becomes valid.

The endpoint halt recovery guide covers this sequence in more depth.

A bulk timeout may be prolonged not-ready behavior

Bulk transfers are reliable, but they do not reserve a maximum completion time. When a device has no IN data ready or cannot accept OUT data, the host controller can retry according to the USB stack's scheduling. The user-space timeout belongs to the API or application, not to the endpoint descriptor.

Ask:

Was the transfer ever submitted to the host controller?
Did the endpoint return a STALL or remain temporarily not ready?
Did any bytes complete before the deadline?
Was the requested length larger than one protocol message?
Does the device require a command before producing IN data?
Did firmware prime the endpoint buffer?
Was another thread or driver holding the interface?

Do not describe every gap as "packet loss." Bulk transfer reliability and application timeout policy are different layers.

Direction-specific timeout diagnosis

Bulk IN timeout

For IN, establish whether the device had data to return:

Did a preceding OUT command complete?
Was the command syntactically and semantically valid?
Does firmware queue a response before enabling the IN endpoint?
Is the host requesting the correct endpoint?
Did the device send a short packet or zero-length packet that marks a protocol boundary?
Is the application waiting for a fixed byte count larger than the available response?

A device can return 64 useful bytes, but a host read for 512 bytes may continue waiting unless a short transfer, protocol framing, or API policy marks completion. Record requested, transferred, and expected protocol lengths.

Bulk OUT timeout

For OUT, ask whether firmware made receive buffers available:

Was the endpoint enabled in the selected configuration and alternate setting?
Was an OUT buffer queued before the host sent data?
Did the previous message leave the state machine busy?
Did the host send more data than the command buffer accepts?
Did a prior fault halt the endpoint?
Did the device reset while the host retained an old handle?

If no OUT request appears on the USB capture, move upward to driver or application submission. If OUT traffic appears repeatedly but never completes, inspect device readiness and controller status.

Payload framing can masquerade as transport failure

Bulk USB transports bytes; it does not define your application message boundaries. Protocol errors can look like endpoint failures:

a length prefix uses the wrong endianness;
host and firmware disagree about header size;
a response is sent only after a complete command, but the host waits before sending the rest;
a zero-length packet is expected by one side but not the other;
one command consumes bytes belonging to the next;
firmware expects one transfer per message although the host coalesces or splits data.

Capture several transfers before the timeout, not just the final error. Reconstruct the application frame from raw payloads and compare it with the protocol definition. The endpoint may be healthy while both sides wait on incompatible framing assumptions.

Descriptor correctness is necessary but not sufficient

A valid bulk endpoint descriptor proves that the host learned an endpoint address and attributes. It does not prove firmware:

configured the controller endpoint;
allocated DMA or packet buffers;
armed receive requests;
handles short packets correctly;
releases buffers after completion;
survives suspend and resume;
preserves protocol state after clear-halt recovery.

Conversely, a firmware queue can be correct while the descriptor exposes the wrong address or alternate setting. Tie runtime transfers back to the descriptor map before changing either layer.

Distinguish timeout, disconnect, and reset

A timeout around the same moment as re-enumeration is usually not an isolated endpoint event. Look for:

port reset;
device disappearance;
a new USB address;
descriptors requested again;
changed PID, serial, or bcdDevice;
application continuing to use the old device handle.

If the device reconnects as a bootloader, the old bulk endpoint no longer exists. The correct recovery is rediscovery under the new identity, not clearing the old endpoint. The USB device disconnect and reset-loop guide covers that boundary.

Compare a known-good transaction sequence

A good comparison keeps variables controlled:

Variable	Keep fixed or record
host and OS	same build where possible
physical port and hub	same topology
device speed	confirm in both captures
firmware and device identity	record exact versions
application command	same bytes and order
timeout value	same caller deadline
endpoint map	verify descriptors

Find the first divergence rather than comparing only final timeouts. If the known-good device queues IN data 2 ms after a command but the failing device never does, the useful difference is in firmware response scheduling. If both complete on USB but only one app reports a timeout, the difference is above USB.

A repeatable endpoint failure workflow

Record the exact API error and timeout value.
Capture from before configuration or application open.
Map interface, alternate setting, and endpoint address.
Find the last successful transfer on that endpoint.
Mark the first abnormal status, delay, reset, or missing submission.
Separate STALL from temporary not-ready behavior and disconnection.
For STALL, trace clear-halt recovery and the first retry.
For timeout, compare requested, transferred, and protocol message lengths.
Reconstruct preceding commands and required state.
Inspect firmware buffer ownership and queue transitions.
Compare with a known-good capture under controlled conditions.
Save bounded before-and-after .bscope sessions.

Use Bus Scope platform capture to prove the correct controller or usbmon bus is selected before interpreting missing traffic.

QA questions

Is a USB bulk transfer timeout the same as an endpoint STALL?

No. A STALL is an explicit USB endpoint response. A timeout is a software deadline expiring before completion. A timeout can follow an uncleared STALL, but it can also result from no ready data, no submitted request, a disconnect, framing deadlock, or application scheduling.

Does `CLEAR_FEATURE(ENDPOINT_HALT)` fix the original command?

It clears endpoint halt transport state when the request and device behavior are correct. It does not make an unsupported command valid or reset every application state machine. Verify both endpoint recovery and protocol recovery.

Why does a bulk IN read wait after receiving some bytes?

The host may still be waiting for the requested length or a transfer boundary. Compare the API semantics, short-packet behavior, zero-length packet policy, and application framing with the actual bytes completed.

Can a descriptor error cause a runtime timeout?

Yes. The host can target the wrong endpoint or alternate setting if the exposed map is wrong. But a correct descriptor does not prove firmware queue behavior, so verify both the declaration and runtime sequence.

Can Bus Scope prove the application thread caused the timeout?

It can show whether USB requests were submitted and completed, along with timing and payload evidence. If the bus completes normally while the application times out, inspect driver completion, parsing, and thread behavior outside the capture.

Final diagnosis

The effective endpoint report names one endpoint, one direction, one first abnormal event, and one recovery result. That is far more useful than "USB froze." Treat STALL as explicit state, timeout as a deadline symptom, and disconnection as loss of the old device context. Once those are separated, firmware, driver, and application teams can each test the layer they actually own.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: