USB Composite Device Debugging: Interface Numbers, IAD, Endpoints, and Driver Binding

USB composite devices are convenient and dangerous. A single device can expose HID controls, CDC serial, mass storage, vendor-specific endpoints, audio, video, or diagnostics interfaces. When everything is described correctly, the host binds the right drivers and each function works. When one descriptor field is wrong, the whole device can look unreliable.

Searches like "USB composite device not recognized," "CDC interface not showing," "HID works but serial does not," or "wrong driver binding USB interface" usually point to descriptor structure, interface numbering, endpoint assignment, or Interface Association Descriptor behavior.

Composite Devices Need a Coherent Configuration

The configuration descriptor is the top-level map. It must describe the total length, number of interfaces, power attributes, and all nested interface and endpoint descriptors. If wTotalLength is wrong, the host may not read all functions. If interface count is wrong, the host may ignore later interfaces. If endpoint addresses collide, transfers become ambiguous or invalid.

Inspect:

• configuration total length
• number of interfaces
• interface numbers
• alternate settings
• endpoint addresses
• endpoint directions
• class, subclass, protocol values
• descriptor order

A capture should show whether the host requested the full configuration and what bytes the device returned.

IAD Helps Group Related Interfaces

Interface Association Descriptors are often used to group multiple interfaces that belong to one function, such as CDC communication plus CDC data. Without correct grouping, the host may bind drivers incorrectly or expose only part of the function.

IAD evidence to inspect:

• first interface number
• interface count
• function class, subclass, protocol
• placement before grouped interfaces
• consistency with actual interface descriptors

If CDC serial does not appear but HID works, the HID interface may be fine while the CDC grouping is wrong.

Endpoint Address Collisions Are Easy to Miss

Endpoint addresses include direction. Endpoint 0x81 and 0x01 are different directions, but two IN endpoints with the same address are not valid within the same device configuration. Firmware teams sometimes copy endpoint descriptors between interfaces and forget to update addresses.

Symptoms include:

• one interface works, another is silent
• host sends transfers to unexpected endpoint
• class driver loads but application gets no data
• endpoint STALL or timeout after configuration
• only one function works at a time

The capture should show endpoint descriptors and later transfer traffic side by side.

Driver Binding Is Evidence Too

The host chooses drivers based on descriptors. A device that binds incorrectly may have descriptor evidence that explains why. Class, subclass, protocol, interface association, compatible IDs, and OS-specific descriptors can all affect binding.

Do not diagnose driver binding only from Device Manager or application logs. Compare the host's class-specific requests with the descriptor tree. If the expected class requests never arrive, the host probably did not bind the expected driver.

Where BusScope Fits

BusScope should help firmware teams inspect composite devices at both levels:

• descriptor map
• transfer evidence after driver binding

A good .bscope session for composite debugging shows:

• all interfaces
• IAD grouping
• endpoint assignments
• class-specific requests per interface
• raw descriptor bytes
• transfer status after configuration

That makes the support conversation specific. Instead of "Windows does not like our composite device," the report can say "interface 2 never receives CDC class requests because the grouping descriptor does not match the declared interface layout."

That is the level of evidence firmware teams need.