VxWorks USB Driver Development: USB Architecture and Protocol Basics
Developing a USB driver on VxWorks requires more than understanding the operating system’s driver framework. Developers also need a solid grasp of the USB protocol, its layered architecture, enumeration process, transfer types, endpoint model, and transaction flow.
This chapter provides a practical introduction to the USB concepts that are most relevant when analyzing or developing USB drivers on VxWorks. It is not intended to replace the official USB specification. Instead, it establishes the foundation needed to understand how VxWorks USB software communicates with physical USB devices.
The discussion focuses primarily on USB 2.0 concepts, including high-speed, full-speed, and low-speed operation.
🔌 USB Specification Fundamentals #
USB is a high-speed serial bus designed to support plug-and-play operation and hot-plugging. It uses differential signaling and provides multiple speed grades depending on the USB generation and device capabilities.
USB 2.0 supports:
- High-speed: 480 Mb/s
- Full-speed: 12 Mb/s
- Low-speed: 1.5 Mb/s
USB 2.0 maintains backward compatibility with full-speed and low-speed USB devices. A high-speed host can communicate with slower devices through the USB protocol and hub mechanisms.
For driver developers, however, raw signaling speed is only one part of the architecture. Understanding how devices are addressed, enumerated, and accessed through endpoints is much more important.
USB Device Addressing #
A USB host can represent up to 128 address values, ranging from 0 through 127.
Address 0 is reserved for the default state during device enumeration. A newly attached device initially responds using address 0 until the host assigns it a unique address.
As a result, up to 127 addresses can be assigned to USB devices simultaneously in theory.
The practical number of functional devices is lower because hubs also consume addresses and the USB topology imposes additional constraints.
Host-Initiated Communication #
USB follows a fundamentally host-controlled communication model.
The host initiates transfers rather than allowing arbitrary devices to transmit whenever they want. This is an important distinction when developing drivers because a USB device generally cannot simply place data onto the bus whenever it has something to report.
A typical transaction follows the general pattern:
Token → Data → Handshake
The token identifies the target device and endpoint. The data packet carries information when required, while the handshake communicates the result of the transaction.
The addressing information ensures that only the intended device responds to the host’s request.
🧩 USB Pipes, Endpoints, and Interfaces #
A pipe is the logical communication path between a USB host and an endpoint on a device.
USB defines two broad categories:
- Stream pipes — transfer unformatted data.
- Message pipes — transfer structured messages.
Every USB device has a default control pipe associated with endpoint 0 immediately after connection.
The default control pipe is especially important during enumeration because the host uses it to retrieve descriptors, assign the device an address, obtain configuration information, and configure the device.
USB Endpoints #
Endpoints represent the actual communication points exposed by a USB device.
A device can provide multiple endpoints, each with characteristics such as:
- Direction.
- Transfer type.
- Maximum packet size.
- Polling interval where applicable.
A single pipe supports one transfer type, so a complex USB function may require several pipes.
The collection of related pipes used to implement a device function forms an interface.
This distinction is fundamental when reading USB descriptors or analyzing a VxWorks USB driver.
🔍 USB Enumeration: The Foundation of Plug-and-Play #
When a USB device is connected, the host must enumerate it before normal operation can begin.
The simplified enumeration process is:
- Detect the device connection.
- Communicate with the device through the default control pipe.
- Retrieve the device descriptor.
- Assign a unique USB address.
- Retrieve configuration descriptors.
- Select and configure the desired configuration.
- Initialize the device’s interfaces and endpoints.
- Begin normal data transfers.
Enumeration is effectively the USB system’s discovery and initialization procedure.
For a VxWorks driver, problems during enumeration can prevent the driver from ever reaching the stage where application-level I/O is possible.
When debugging a USB driver, it is therefore useful to determine whether a failure occurs during:
- Device detection.
- Address assignment.
- Descriptor retrieval.
- Configuration.
- Endpoint initialization.
- Normal data transfer.
📦 USB Transfer Types #
USB defines four fundamental transfer types.
Control Transfers #
Control transfers are primarily used for device configuration, enumeration, status queries, and device-specific control operations.
They are performed through the control endpoint and support the structured Setup, Data, and Status stages.
Control transfers are essential for virtually every USB device because the host uses them to discover and configure the device.
Interrupt Transfers #
Interrupt transfers are designed for relatively small amounts of data that need predictable polling.
Common examples include:
- Keyboards.
- Mice.
- Game controllers.
- Other human-interface devices.
Despite their name, interrupt transfers do not mean that the device interrupts the host.
The host periodically polls the endpoint according to the interval specified in the endpoint descriptor. If the device has data available, it responds with the appropriate data. Otherwise, it can return a NAK.
This distinction is particularly important when designing or debugging VxWorks USB drivers.
Bulk Transfers #
Bulk transfers are intended for reliable movement of relatively large amounts of data when latency is less critical.
Typical applications include:
- USB mass storage.
- Printers.
- Data acquisition devices.
- Other devices that require reliable high-volume transfers.
Bulk transfers use handshakes and DATA0/DATA1 sequencing to maintain synchronization.
Isochronous Transfers #
Isochronous transfers are designed for time-sensitive data streams where maintaining timing is more important than guaranteeing delivery of every packet.
Typical applications include:
- USB audio.
- Video streams.
- Other continuous real-time data.
Unlike bulk and interrupt transfers, isochronous transfers do not use handshake packets and do not provide retransmission for lost data.
The host gives them the highest transfer scheduling priority.
📨 USB Request Categories #
USB control communication can contain three broad categories of requests.
Standard Requests #
Standard requests are defined by the USB specification and must be supported as required by USB devices.
Examples include requests for:
- Device descriptors.
- Configuration information.
- Device status.
- Address assignment.
- Configuration selection.
These requests form the foundation of USB enumeration.
Class-Specific Requests #
USB defines standardized device classes, such as:
- Hub.
- Mass storage.
- Human interface devices.
- Audio.
- Communication devices.
Each class can define its own requests and behaviors.
A class-compliant driver can therefore use standardized protocols rather than requiring every device manufacturer to invent a completely independent interface.
Vendor-Specific Requests #
Vendor-specific requests are proprietary commands defined by the device manufacturer.
They are commonly used for device-specific configuration, diagnostics, firmware operations, or functionality that does not fit into an existing USB class.
When developing a VxWorks driver for a proprietary USB device, vendor-specific control requests can become a major part of the driver implementation.
🌐 USB Hub Architecture #
USB hubs provide a practical mechanism for expanding the number of available ports.
A hub has:
- One upstream port connected toward the host or another hub.
- Multiple downstream ports connected to devices or additional hubs.
Each downstream port can detect device attachment and removal and can manage the corresponding port state and power.
USB devices can operate at different speeds within the same physical topology.
From a physical perspective, USB therefore forms a tiered-star topology.
From a logical perspective, however, hubs are largely transparent. The host software can treat each functional device as an individual USB device rather than requiring application software to understand every physical hub connection.
🏗️ USB Data-Flow Architecture #
USB software is organized into several logical layers.
The architecture can be viewed as three major layers:
- Function layer — defines the behavior and semantics of the device function.
- Device layer — converts functional requests into USB transfers and transactions.
- Bus-interface layer — handles packet transmission, physical signaling, and bus management.
This layered model is particularly useful when analyzing a VxWorks USB driver because different components of the software stack are responsible for different parts of the communication process.
Client Software and USB System Software #
Application or client software does not normally communicate directly with the physical USB bus.
Instead, it submits I/O requests through the USB device-driver framework.
Conceptually, the path looks like:
Application → USB Device Driver → USBD → HCD → Host Controller → USB Bus → Device
The USBD layer handles USB device-level services, while the Host Controller Driver (HCD) communicates with the underlying host controller hardware.
The HCD is responsible for converting higher-level requests into transactions that can be scheduled on the USB bus.
Why the HCD Matters #
Multiple USB clients can issue requests concurrently.
The host controller therefore needs a mechanism for scheduling those transactions according to USB timing and priority rules.
The HCD acts as the bridge between the operating system’s USB software and the hardware host controller.
When debugging VxWorks USB problems, identifying whether an error originates in the client driver, USBD layer, HCD, or hardware is often the key to finding the root cause.
🧱 USB Packets and Protocol Structure #
USB packets are the smallest units transmitted across the USB bus.
Every packet begins with a SYNC field followed by a Packet Identifier (PID) and other fields depending on the packet type.
USB packets can be divided into four major categories:
- Token packets
- Data packets
- Handshake packets
- Special packets
The PID identifies the packet type.
Token Packets #
Token packets identify the target device and endpoint.
They contain:
- A 7-bit device address.
- A 4-bit endpoint number.
- A CRC field.
Token packets do not carry a conventional data payload.
The Start-of-Frame (SOF) packet is a special type of token containing an 11-bit frame number.
Data Packets #
Data packets contain the actual payload.
They include:
- PID.
- Data payload.
- CRC16.
Data packet PIDs can alternate between DATA0 and DATA1 in transfer types that use data toggling.
This mechanism helps the sender and receiver detect duplicated or lost transactions.
Handshake Packets #
Handshake packets contain only a PID.
They communicate the status of a transaction, including successful completion or conditions such as NAK or STALL.
Handshake behavior differs depending on the transfer type.
⏱️ USB Frames and Transaction Timing #
USB transfers are organized around frames.
For USB 2.0:
- Full-speed and low-speed operation use 1 ms frames.
- High-speed operation uses 125 µs microframes.
An SOF packet marks the beginning of a frame or microframe.
The end of the frame is represented by an EOF condition rather than a conventional packet.
USB packets must be transmitted completely within the applicable scheduling interval.
A transaction consists of one or more packets and must also fit within the relevant frame or microframe constraints.
A higher-level transfer can contain multiple transactions and therefore span multiple frames.
Understanding this hierarchy is essential:
Packet → Transaction → Transfer
🔄 USB Transaction Flow #
Different transfer types use different transaction sequences.
Bulk Transaction #
A bulk transaction generally follows a reliable request/data/handshake pattern.
When a large amount of data must be transferred, the overall bulk transfer is divided into multiple transactions.
DATA0 and DATA1 packet sequencing is used to maintain synchronization.
The distinction between a bulk transaction and a bulk transfer is important: a transfer can consist of many individual transactions.
Control Transfer #
A control transfer consists of up to three stages:
- Setup stage
- Data stage, when required
- Status stage
The Setup stage contains the request information.
The optional Data stage carries the requested data.
The Status stage completes the operation and occurs in the opposite direction from the preceding Data stage.
A successful Status stage normally uses a zero-length data packet. Error conditions can result in responses such as NAK or STALL.
Control transfers are therefore more structured than bulk or interrupt transfers.
Interrupt Transaction #
Interrupt transactions use a structure similar to bulk transactions but differ in scheduling, endpoint requirements, and transfer characteristics.
The host schedules them according to the polling interval specified in the interrupt endpoint descriptor.
Interrupt transfers receive higher scheduling priority than bulk transfers, although isochronous traffic receives higher priority.
DATA0/DATA1 synchronization is also used.
Isochronous Transaction #
Isochronous transactions prioritize timing and bandwidth over guaranteed delivery.
They do not use handshake packets and do not employ the DATA0/DATA1 synchronization mechanism used by bulk and interrupt transfers.
This makes them suitable for continuous streams where retransmitting old data would be less useful than keeping the stream moving.
For example, losing an individual audio sample may be preferable to introducing a delay while waiting for retransmission.
🛠️ Why These Concepts Matter for VxWorks Drivers #
A VxWorks USB driver sits above a complex hardware and protocol stack.
Understanding USB fundamentals helps developers map software operations to what actually happens on the bus.
For example:
- A descriptor request corresponds to a control transfer.
- A keyboard report commonly arrives through an interrupt endpoint.
- Large file transfers generally use bulk endpoints.
- Streaming audio or video may use isochronous endpoints.
- Endpoint configuration determines the available pipes.
- The HCD translates higher-level requests into schedulable USB transactions.
- The host controller ultimately executes those transactions on the physical bus.
Without understanding these relationships, driver debugging can easily become trial and error.
🔎 A Practical Debugging Model #
When a VxWorks USB device fails to operate, it is useful to analyze the system from the bottom upward.
Layer 1: Physical Connection #
Verify:
- Device power.
- USB cable and port.
- Hub operation.
- Device attach detection.
- Supported USB speed.
Layer 2: Enumeration #
Check whether the host can:
- Detect the device.
- Assign an address.
- Retrieve the device descriptor.
- Retrieve configuration descriptors.
- Select a configuration.
If enumeration fails, application-level driver debugging is premature.
Layer 3: Endpoint Configuration #
Verify:
- Interface descriptors.
- Endpoint addresses.
- Transfer types.
- Maximum packet sizes.
- Polling intervals.
- Direction.
An incorrect endpoint configuration can result in apparently mysterious transfer failures.
Layer 4: Driver Requests #
Confirm that the VxWorks USB client driver submits the correct requests to USBD and that the expected completion callbacks or status notifications occur.
Layer 5: Host Controller #
If the request reaches the HCD but does not produce the expected bus activity, investigate host-controller configuration, scheduling, DMA, interrupts, and hardware-specific behavior.
This layered approach helps isolate failures instead of treating the USB stack as a single black box.
📚 Conclusion #
USB driver development on VxWorks requires an understanding of both the operating-system driver architecture and the underlying USB protocol.
The essential concepts include:
- USB device addressing and enumeration.
- Pipes, endpoints, and interfaces.
- Control, interrupt, bulk, and isochronous transfers.
- Standard, class-specific, and vendor-specific requests.
- USB hubs and tiered-star topology.
- USBD and HCD responsibilities.
- Packets, transactions, and transfers.
- USB frame and microframe timing.
- DATA0/DATA1 synchronization.
- Host-controlled polling and scheduling.
These concepts provide the foundation for understanding how a VxWorks USB driver communicates with actual hardware.
In the next stage of driver development, the focus can move from USB protocol fundamentals to the VxWorks-specific implementation: USBD architecture, HCD interfaces, device-driver registration, enumeration callbacks, endpoint management, transfer submission, DMA handling, and interrupt processing.
A strong understanding of the protocol layer makes that software analysis considerably easier—and helps turn USB driver development from a collection of opaque APIs into a predictable sequence of hardware and software operations.