2026-06-02

USB Remote Wakeup and Suspend Resume Debugging

Debug USB remote wakeup by tracing descriptor capability, host feature enablement, suspend, device wake signaling, resume, endpoint restoration, reset, and re-enumeration.

A USB device can work for hours while active and then disappear after selective suspend, ignore the event meant to wake the host, or wake the system immediately after sleep. "Remote wakeup failed" is too broad: the device may not advertise capability, the host may never enable it, suspend may not complete, wake signaling may be absent, or endpoints may fail only after resume.

Direct answer: capture from enumeration through idle, suspend, the wake event, and post-resume traffic. Verify descriptor capability, host enable/disable requests, device state before suspend, wake signaling or host-initiated resume, and the first transfer after resume. Then determine whether the same configured device continued or a reset triggered full re-enumeration.

Bus Scope can expose USB descriptors, control requests, timing, transfer gaps, resets, and new enumeration. Platform sleep policy, electrical signaling quality, controller power states, and firmware's private low-power state can require OS traces, hardware measurement, or device logs in addition to the USB capture.

Remote wakeup is a permissioned sequence

For a USB 2.0-style device path, several conditions matter:

the configuration advertises remote-wakeup capability;
the host selects that configuration;
host policy enables the remote-wakeup feature for the device;
the bus/device enters suspend;
a valid external event occurs after suspend is established;
the device signals resume according to the protocol;
the host resumes the path;
firmware restores endpoint and application state.

Failure at any stage can produce "does not wake." Write the report around the first missing stage.

Check descriptor capability

The configuration descriptor's attributes indicate whether the selected configuration supports remote wakeup. Record:

selected configuration value;
configuration attributes;
whether another configuration differs;
device speed and topology;
firmware revision and identity.

Advertising capability does not mean it is always enabled. It tells the host that the selected configuration can support the feature.

If the descriptor bytes are uncertain, use the USB descriptor viewer workflow.

Prove host enablement

The host can enable or clear device remote wakeup with standard feature requests. Decode:

Setup field	Diagnostic meaning
request type	standard device-recipient request
request	`SET_FEATURE` or `CLEAR_FEATURE`
feature selector	device remote wakeup
data length	zero

Create a timeline:

Time	Event	Result
0.20 s	configuration selected	completes
2.10 s	remote wake feature enabled	completes
15.00 s	idle/suspend begins	observed
20.00 s	external button	device log marker
20.01 s	resume sequence	observed
20.04 s	first interrupt report	completes

If the host never enables remote wake, firmware should not assume permission merely because capability was advertised. Continue with OS power policy and device settings.

Selective suspend and system sleep differ

Selective suspend can idle one USB device or function while the rest of the system remains active. System sleep changes a broader platform power state. The available capture perspective and host policy can differ.

Record the test:

selective suspend after application idle;
display sleep;
system sleep state;
lid close;
dock sleep;
controller runtime power management.

Do not merge results from different power transitions. A device that resumes from selective suspend may still fail across a system sleep or dock power loss.

Mark when suspend actually begins

The application becoming idle is not identical to bus suspend. Preserve enough context to identify:

last control request;
last interrupt, bulk, or isochronous transfer;
host feature enablement;
final report before inactivity;
timestamp where normal service stops;
device firmware low-power entry marker if available.

An event arriving before suspend completes can be treated as normal traffic rather than remote wake. An event arriving during a firmware race can be lost. Device-side timestamps help distinguish those cases.

Missed wake events

When the external event occurs but the host stays asleep, test each boundary:

Boundary	Evidence
physical input	GPIO or device log marker
firmware wake source	interrupt/status log
remote-wakeup permission	host feature request
USB resume signaling	bus/controller evidence
hub propagation	topology comparison
host wake policy	OS power trace
first post-wake report	USB transfer and payload

Bus traffic can show that no resume reached the capture point, but absence alone may not identify device, hub, controller, or policy as the root cause. Compare direct port and reported dock while controlling the same event.

Immediate wake after suspend

The opposite failure is a system that wakes immediately. Common causes include:

stale input remains pending;
firmware treats suspend entry as an input edge;
noisy or bouncing wake source;
an interrupt report was queued before suspend;
the device signals wake before suspend is stable;
host policy arms a device that should not wake.

Capture:

last report before suspend;
remote-wakeup enablement;
suspend boundary;
delay to resume;
first post-resume report;
physical wake-source state.

If the same report payload appears before and immediately after suspend, determine whether firmware replayed stale data or the host redelivered buffered input.

Resume is not re-enumeration

Normal resume continues the configured device context. Re-enumeration starts a new USB session with descriptors, address assignment, and configuration.

Evidence after sleep	Classification
endpoint traffic resumes under existing context	resume
port reset, descriptors, new address	reset and re-enumeration
disconnect followed by different PID	mode change or bootloader
no traffic and API timeout	unresolved resume/handle path

Re-enumeration can make an app's old handle invalid. A user sees "device disconnected after sleep," while the bus shows a reset and a new instance. The fix may require both firmware resume repair and host rediscovery.

Endpoint state after resume

Even when wake succeeds, firmware can fail to restore:

endpoint enablement;
receive buffers;
pending interrupt reports;
alternate settings;
class protocol mode;
data-toggle/controller state;
application session state;
clocks and DMA.

Inspect the first transfer on every relevant endpoint:

Endpoint/function	First post-resume result	Meaning
HID interrupt IN	completes with fresh input	HID path restored
CDC bulk OUT	accepted	receive queue restored
CDC bulk IN	times out	response/IN queue not restored
vendor endpoint	STALL	protocol state or halt issue

The USB endpoint timeout guide covers post-resume data-path failures.

Composite devices can resume partially

A composite parent can contain HID, CDC, audio, video, or vendor functions with different idle policies. After resume:

HID wakes correctly but CDC data remains silent;
control interface works but data interface does not;
one alternate setting is not restored;
application opens one child while another is re-created;
parent reset invalidates all child handles.

Map symptoms by interface and endpoint. "Composite device failed resume" is not enough when only one function is broken.

Hub and dock comparisons

Remote wake traverses topology and platform policy. Compare:

direct root port;
same device through the reported hub;
bus-powered versus externally powered dock;
laptop on battery versus AC if policy differs;
same OS power settings;
same firmware and physical event.

Record negotiated speed and whether the path retains power. A capture can correlate failure with topology but may not prove analog signal quality or rail timing.

Selective suspend random disconnects

When a device "randomly disconnects" after idle, look for a repeatable sequence:

no application traffic;
suspend;
resume attempt;
endpoint timeout or STALL;
host reset;
descriptors retrieved again;
application reports device removal.

The visible disconnect is the last step. Fix the first failed resume or endpoint restoration. The dedicated USB selective suspend disconnect guide covers this case.

Cross-platform results

Operating systems can differ in:

whether remote wake is enabled;
idle timeout;
per-device user settings;
hub and controller power management;
resume recovery and reset policy;
application handle behavior.

Compare request and state sequences rather than declaring one platform correct:

Question	Working host	Failing host
capability read	yes	yes
feature enabled	yes	no
suspend reached	yes	yes
device attempted wake	yes	not permitted
endpoint restored	yes	n/a

The first difference tells whether to investigate firmware or host policy.

A repeatable remote-wakeup workflow

Record firmware, device identity, OS, controller, hub, and power state.
Capture from enumeration through the complete sleep test.
Verify selected configuration and wake capability.
Find host feature enable/disable requests.
Mark last normal transfer and actual suspend boundary.
Add a device-side marker for the physical event.
Identify resume signaling or host-initiated resume.
Separate resume from reset/re-enumeration.
Test first transfer on each relevant endpoint.
Compare direct and hub/dock paths.
Pair USB evidence with OS power and device logs.
Save bounded .bscope sessions for working and failing tests.

Use Bus Scope platform capture to select the correct USBPcap controller or Linux usbmon bus before the long idle test.

QA questions

Does advertising remote wakeup mean the device may always wake the host?

No. Capability and host enablement are separate. Verify the selected configuration, host feature request, suspend state, and platform policy.

Why does the device wake the PC immediately?

It may signal on stale input, noise, an event during suspend entry, or a firmware state bug. Correlate the last pre-suspend report, suspend boundary, wake delay, and first post-resume payload.

Is re-enumeration a normal resume?

No. It creates a new device session and can invalidate handles. Record the reset and descriptor sequence, then inspect why configured state could not continue.

Can one function of a composite device resume while another fails?

Yes. Inspect interface-specific class state and the first post-resume transfer on every relevant endpoint instead of judging only the parent device.

Can Bus Scope prove BIOS or OS wake policy is wrong?

It can show USB capability, feature requests, traffic, resets, and timing. BIOS, controller, and OS power-policy decisions require platform evidence when they do not produce a conclusive USB sequence.

Final diagnosis

USB remote wakeup is a chain of permission, suspend, signaling, resume, and endpoint restoration. A useful report names the first missing link and distinguishes a continued configured session from full re-enumeration. That turns "wake does not work" into a firmware, topology, host-policy, or post-resume data-path issue with a repeatable test.

Run the sequence once with wake enabled and once disabled, using the same port and idle period. Preserve the SET_FEATURE or policy evidence, suspend interval, resume signal, first post-resume transfer, and any reset. The controlled pair prevents an unrelated replug or power change from being mistaken for successful remote wakeup.

Related guides

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