9.2  USB Control Transfers

9.2.1  USB Control Transfers Overview  Control Data Exchange

USB control exchange is used to determine device identification and configuration requirements and to configure a device, and can also be used for other device-specific purposes, including control of other pipes on the device.
Control exchange takes place via a control pipe, mainly the default Pipe 0, which always exists. The control transfer consists of a setup stage (in which a setup packet is sent from the host to the device), an optional data stage and a status stage.  More About the Control Transfer

The control transaction always begins with a setup stage. The setup stage is followed by zero or more control data transactions (data stage) that carry the specific information for the requested operation, and finally a status transaction completes the control transfer by returning the status to the host.

During the setup stage, an 8-byte setup packet is used to transmit information to the control endpoint of the device. The setup packet's format is defined by the USB specification.

A control transfer can be a read transaction or a write transaction. In a read transaction the setup packet indicates the characteristics and amount of data to be read from the device. In a write transaction the setup packet contains the command sent (written) to the device and the number of control data bytes that will be sent to the device in the data stage.

Refer to Figure 9.2 (taken from the USB specification) for a sequence of read and write transactions.
'(in)' indicates data flow from the device to the host.
'(out)' indicates data flow from the host to the device.

Figure 9.2  USB Read and Write

USB Read and Write  The Setup Packet

The setup packets (combined with the control data stage and the status stage) are used to configure and send commands to the device. Chapter 9 of the USB specification defines standard device requests. USB requests such as these are sent from the host to the device, using setup packets. The USB device is required to respond properly to these requests. In addition, each vendor may define device-specific setup packets to perform device-specific operations. The standard setup packets (standard USB device requests) are detailed below. The vendor's device-specific setup packets are detailed in the vendor's data book for each USB device.  USB Setup Packet Format

The table below shows the format of the USB setup packet. For more information, please refer to the USB specification at http://www.usb.org.

0bmRequest Type Bit 7: Request direction (0=Host to device – Out, 1=Device to host – In).
Bits 5-6: Request type (0=standard, 1=class, 2=vendor, 3=reserved).
Bits 0-4: Recipient (0=device, 1=interface, 2=endpoint,3=other).
1bRequest The actual request (see the Standard Device Request Codes table [].
2wValueL A word-size value that varies according to the request. For example, in the CLEAR_FEATURE request the value is used to select the feature, in the GET_DESCRIPTOR request the value indicates the descriptor type and in the SET_ADDRESS request the value contains the device address.
3wValueHThe upper byte of the Value word.
4wIndexL A word-size value that varies according to the request. The index is generally used to specify an endpoint or an interface.
5wIndexHThe upper byte of the Index word.
6wLengthL A word-size value that indicates the number of bytes to be transferred if there is a data stage.
7wLengthHThe upper byte of the Length word.  Standard Device Request Codes

The table below shows the standard device request codes.

bRequest Value
Reserved for future use2
Reserved for future use4
SYNCH_FRAME12  Setup Packet Example

This example of a standard USB device request illustrates the setup packet format and its fields. The setup packet is in Hex format.

The following setup packet is for a control read transaction that retrieves the device descriptor from the USB device. The device descriptor includes information such as USB standard revision, vendor ID and product ID.

GET_DESCRIPTOR (Device) Setup Packet


Setup packet meaning:

Byte Field Value Description
0BmRequest Type80 8h=1000b

bit 7=1 -> direction of data is from device to host.


bits 0..1=00 -> the recipient is the device.
1bRequest06The Request is GET_DESCRIPTOR.
3wValueH01 The descriptor type is device (values defined in USB spec).
4wIndexL00 The index is not relevant in this setup packet since there is only one device descriptor.
6wLengthL12 Length of the data to be retrieved: 18(12h) bytes (this is the length of the device descriptor).

In response, the device sends the device descriptor data. A device descriptor of Cypress EZ-USB Integrated Circuit is provided as an example:

Byte No.012345678910

Byte No.11121314151617

As defined in the USB specification, byte 0 indicates the length of the descriptor, bytes 2-3 contain the USB specification release number, byte 7 is the maximum packet size for endpoint 00, bytes 8-9 are the Vendor ID, bytes 10-11 are the Product ID, etc.

9.2.2  Performing Control Transfers with WinDriver

WinDriver allows you to easily send and receive control transfers on Pipe00, while using DriverWizard to test your device. You can either use the API generated by DriverWizard [5] for your hardware, or directly call the WinDriver WDU_Transfer() [B.4.8.1] function from within your application.  Control Transfers with DriverWizard

  1. Choose Pipe 0x0 and click the Read / Write button.
  2. You can either enter a custom setup packet, or use a standard USB request.
    • For a custom request: enter the required setup packet fields. For a write transaction that includes a data stage, enter the data in the Write to pipe data (Hex) field. Click Read From Pipe or Write To Pipe according to the required transaction (see Figure 9.3).

      Figure 9.3  Custom Request

      Custom Request

    • For a standard USB request: select a USB request from the requests list, which includes requests such as GET_DESCRIPTOR CONFIGURATION, GET_DESCRIPTOR DEVICE, GET_STATUS DEVICE, etc. (see Figure 9.4). The description of the selected request will be displayed in the Request Description box on the right hand of the dialogue window.

      Figure 9.4  Requests List

      Requests List

  3. The results of the transfer, such as the data that was read or a relevant error, are displayed in Driver Wizard's Log window.
    Figure 9.5 below shows the contents of the Log window after a successful GET_DESCRIPTOR DEVICE request.

    Figure 9.5  USB Request Log

    USB Request Log  Control Transfers with WinDriver API

To perform a read or write transaction on the control pipe, you can either use the API generated by DriverWizard for your hardware, or directly call the WinDriver WDU_Transfer() [B.4.8.1] function from within your application.

Fill the setup packet in the BYTE SetupPacket[8] array and call these functions to send setup packets on Pipe00 and to retrieve control and status data from the device.

  • The following sample demonstrates how to fill the SetupPacket[8] variable with a GET_DESCRIPTOR setup packet:
    setupPacket[0] = 0x80;   /* BmRequstType */
        setupPacket[1] = 0x6;    /* bRequest  [0x6 == GET_DESCRIPTOR] */
        setupPacket[2] = 0;      /* wValue */
        setupPacket[3] = 0x1;    /* wValue [Descriptor Type: 0x1 == DEVICE] */
        setupPacket[4] = 0;      /* wIndex */
        setupPacket[5] = 0;      /* wIndex */
        setupPacket[6] = 0x12;   /* wLength  [Size for the returned buffer] */
        setupPacket[7] = 0;      /* wLength */
  • The following sample demonstrates how to send a setup packet to the control pipe (a GET instruction; the device will return the information requested in the pBuffer variable):
    WDU_TransferDefaultPipe(hDev, TRUE, 0, pBuffer, dwSize, 
           bytes_transferred, &setupPacket[0], 10000);
  • The following sample demonstrates how to send a setup packet to the control pipe (a SET instruction):
    WDU_TransferDefaultPipe(hDev, FALSE, 0, NULL, 0,
            bytes_transferred, &setupPacket[0], 10000);

For further information regarding WDU_TransferDefaultPipe(), refer to section B.4.8.3. For further information regarding WDU_Transfer(), refer to section B.4.8.1.