USB Explained: Enumeration, Endpoints, Transfers, and What Breaks

You plug a sensor into a computer. Its LED lights up. Your application says “device not found.” Has USB failed?

Not enough evidence yet. Power reaching the board, the operating system recognizing it, a driver exposing an interface, and your application receiving useful measurements are different milestones. Treating them as one event makes debugging unnecessarily mysterious.

This is the first entry in the hardware knowledge base. The starting reference is Total Phase’s USB Background. This article uses its own examples and diagrams, with Microsoft and USB-IF references for additional detail. It focuses on USB 2.0 and the original 5 Gbit/s SuperSpeed architecture—not a complete USB4, electrical-design, or USB Power Delivery guide.

The mental model: a host manages a device #

USB connects a host to peripherals, directly or through hubs. The host controller and operating-system stack coordinate communication. A hub expands connectivity; it does not turn a peripheral into an independent host.

For USB 2.0, imagine a scheduled conversation rather than two applications opening arbitrary network connections. SuperSpeed changes the link and readiness mechanisms, so do not extend every USB 2.0 packet sequence to newer generations. Total Phase provides a useful architectural comparison.

Here is an original conceptual diagram. The arrows show responsibilities, not electrical wiring or the exact order of bus packets:

HOST COMPUTER                         SENSOR DEVICE

Application: record samples           Firmware: collect samples
          |                                      |
Driver / USB stack                    Endpoint buffers
          |                                      |
Host controller <---- cable / optional hub ----> USB controller

Before useful measurements:
Detect -> identify -> configure -> bind driver -> exchange data

When a report says “USB is broken,” locate the last successful boundary in that chain. A device visible to the operating system but inaccessible to an application is a different investigation from a device that never appears at all.

USB-C describes a connector, not the whole connection #

A reversible connector does not promise a specific data rate, charging capability, or display mode. Those depend on the capabilities of the devices and the cable. USB-IF distinguishes cable capabilities and markings in its cables and connectors guidance.

For the generations covered here, the familiar signaling rates are 1.5 Mbit/s for low-speed, 12 Mbit/s for full-speed, 480 Mbit/s for high-speed, and 5 Gbit/s for original SuperSpeed. These are historical modes, not an exhaustive list of modern USB rates. The source article’s original SuperSpeed discussion includes separate transmit and receive pairs; USB 2.0 uses its D+/D− pair. Total Phase explains that physical distinction.

The practical consequence: record the negotiated mode, not just the label on the port. Also record the cable and any intervening hub. A known-good data cable is an experiment that removes a variable, not a universal cure.

Enumeration: the device describes itself #

Before choosing how to communicate, the host needs information. USB descriptors provide that structured description. The host requests them through the default control endpoint. Device information includes vendor and product identifiers; configuration information organizes interfaces; interface information describes functions and alternate settings; endpoint information describes communication properties. See Microsoft’s descriptor overview.

Device
  Configuration
    Interface: sensor measurements
      Alternate setting
        Endpoint: measurements toward host
        Endpoint: commands toward device

This is an illustrative layout, not a real product descriptor. A real device may have multiple configurations, interfaces, or alternate settings. The default control endpoint is separate from the illustrated application-data endpoints.

Descriptors are an interface contract. If firmware advertises a packet size or endpoint that its implementation cannot handle, the host can make perfectly reasonable requests that the device fails to satisfy. Compare the descriptor dump from a working firmware version against the failing version before changing application code.

Identification is not authentication. Vendor/product identifiers help software recognize a device; they do not prove that it is trustworthy. Do not grant sensitive application privileges solely because a peripheral reports the expected identifiers.

Endpoints and pipes: name the direction from the host #

An endpoint is a device-side communication destination or source. A pipe is the host-side software abstraction used to communicate with it. Endpoint zero supports the default bidirectional control path; ordinary data endpoints have a direction. IN means device to host. OUT means host to device. This perspective remains the same when you are writing device firmware. Microsoft: endpoints and pipes.

For the hypothetical sensor, measurement data travels IN even though the firmware developer thinks “I am sending.” Configuration commands travel OUT even though the device thinks “I am receiving.” Write the host-relative direction in logs and test names to avoid this ambiguity.

Do not confuse an endpoint with an application message. Your protocol still needs framing, lengths, versioning, and validation appropriate to its device class or vendor protocol. A successful byte transfer does not establish that a complete, meaningful measurement was received.

Choose the transfer type by what failure costs #

USB exposes four transfer types. This summary combines the endpoint model with Microsoft’s bandwidth-allocation guidance:

“Interrupt” does not mean the device arbitrarily interrupts the host CPU whenever it wants. Likewise, isochronous transport should not be described as having no error detection: the important distinction is the absence of USB transfer-level retransmission for recovering missed data. Timing takes priority over retrying old stream data.

Bulk transport includes error detection and retry mechanisms, but it has no reserved bandwidth and can still fail because of disconnects or other errors. Microsoft’s bulk-transfer documentation makes that distinction useful in practice. “Reliable” is not “your file will eventually arrive under every condition.”

A transfer is not one packet #

An application might submit a buffer much larger than an endpoint’s packet size. The USB stack and controller handle the lower-level transactions. Do not equate the application’s buffer length with a single wire packet.

For example, in a simplified USB 2.0 bulk OUT exchange, the host identifies the target, sends data, and receives a handshake. A temporarily unready endpoint may respond with NAK. Original SuperSpeed uses different readiness behavior, including NRDY and ERDY. See the documented bulk transaction examples.

When reviewing a capture, first identify the bus generation, direction, endpoint, and transfer type. Otherwise a readiness response can be mistaken for corruption, or a normal retry can be blamed for an application timeout whose real cause is firmware that never drains a buffer.

Work the bandwidth requirement before buying a faster port #

Suppose an invented instrument generates eight channels, 2,000 samples per second per channel, and two bytes per sample:

8 × 2,000 × 2 = 32,000 payload bytes/second
32,000 × 8   = 256,000 payload bits/second

This is payload arithmetic, not a measured throughput claim. Add framing and transport overhead, then measure the implementation. A low payload requirement does not prove the system is fast enough: firmware may batch for too long, the host may submit reads too slowly, or another device may consume shared resources.

Conversely, dividing 480 Mbit/s by eight gives 60 MB/s as a raw bit-to-byte conversion, not an application throughput guarantee. Shared scheduling, protocol overhead, device processing, and host software all sit between that number and useful data. Microsoft discusses competition for USB bandwidth.

Use two measurements: sustained useful bytes per second and end-to-end sample age. A stream can meet its throughput target while delivering measurements too late to be useful. This is the same distinction between capacity and deadlines that matters in backend timeout budgets.

Debug by the last boundary that worked #

The following is a proposed investigation checklist, not a diagnosis of a particular device:

Start with operating-system diagnostics and firmware logs. A software trace can reveal submitted requests and completion statuses. A hardware protocol analyzer provides wire-level visibility when that boundary is the question. Neither automatically proves the application’s interpretation of the data correct. Keep captures free of unrelated private device traffic before sharing them.

The production contract extends beyond USB #

For a device command that changes state, distinguish “bytes accepted” from “operation completed.” A host that times out may not know whether the firmware applied a command. Where repetition could cause harm, design command IDs, acknowledgments, and a reconciliation path instead of blindly retrying. The idempotency and side-effect discussion provides a useful software-side parallel, not a claim that USB behaves like Kafka.

Record firmware version, device identity, negotiated mode, endpoint, operation ID, timeout stage, and transferred length in diagnostic events. Avoid logging sensitive payloads by default. Test unplugging during reads and writes, firmware restart, host suspend/resume, and reconnect with pending operations. Define whether reconnect starts a new application session.

The central lesson is small: USB connection, transport success, and product success are different facts. A good knowledge base teaches you which fact you have proved and what evidence would prove the next one.

Further reading #

• Total Phase: USB Background — the starting reference for this article; historical USB 2.0/3.0 context.
• Microsoft: endpoints and pipes — host/device terminology.
• Microsoft: standard descriptors — how devices describe their interfaces.
• Microsoft: bulk transfers — transaction examples and driver responsibilities.
• Microsoft: bandwidth allocation — scheduling and shared resources.
• USB-IF: cables and connectors — connector and cable capability references.

More hardware guides · All engineering essays