USB Requests and Stages of Control Transfer (Part 4/6)

In the previous article of this series, USB Descriptors were discussed. When a USB peripheral is connected to a host device, the host sends queries in the form of requests. The peripheral responds by sending Descriptors. The Descriptors contain the information required for identifying and configuring the peripheral device, implementing the interfaces and setting endpoints. The device descriptor is the first descriptor sent to the host and it helps configuring the peripheral with respect to the host. The subsequent descriptors implements the functioning, the peripheral is meant for.

The Control Transfer is the only transfer type which is supported even when the device is yet not configured. That is the reason, it is used for sending requests and obtaining the descriptors. The default endpoint is endpoint 0 which is bidirectional and used for control transfers.

Therefore, the first request that is prompted by the host to the peripheral just involves a control transfer. As discussed before while discussing USB protocol, the Control Transfer consists of three transactions – Setup transaction, Data transaction (optional) and Status transaction.

1. SETUP TRANSACTION

The Control Transfer starts with a Setup Stage. The setup transaction is used in this stage. The transaction consists of three packets – Token, Data and Handshake.

Token Packet: It contains Setup PID (Packet Identifier), device address, endpoint and CRC. The default endpoint and device address 0 is used. The address is updated after assigning a unique address to the device. This packet is sent by host.

Data Packet : It contains Data0 PID. The data payload is 8-byte long. This packet is also sent by the host. The contents of data payload includes following fields :

• bmRequestType – This field provides information related to data direction, type of request, and the designated recipient. Bit 7 represents the direction of data flow in data stage. Bit 5-6 represents the type of request. Bit 4-0 specifies the recipient for the request.

• bRequest – The type of request can be selected by bmRequestType. The unique value of the bRequest specifies one of the selected requests. For example, bRequest value can be used to select one of the standard USB requests.

• wValue – This field specifies the information that needs to be passed from host to device with the request. For example, in Set_Address request, wValue contains the device address.

• wIndex – This field also specifies the information that needs to be passed from host to device with the request. The typical use includes passing the endpoint or interface number. For endpoint, bit 3-0 represents the endpoint number and bit 7 represents the direction; 0 : OUT; 1 : IN. For interface, bit 7-0 represents the interface number.

• wLength – This field indicates the number of bytes to be transferred in data stage. For Host to Device transfer, this field specifies the exact amount of data that host will transfer. For Device to Host transfer, this field specifies the maximum amount of data that device can transfer. For no data stage, this field is zero.

Handshake Packet : This packet is sent by the peripheral device to the host in Setup Stage. It contains acknowledgment (ACK) if the data packet has been received with no errors. If an error has occurred, the handshake packet is not returned.

2. DATA TRANSACTION

This is the second and an optional stage in Control Transfer. In this stage the requested data is transferred. It contains various IN or OUT transactions. Each transaction contains three packets, Token, Data and Handshake.

Token Packet: This packet contains PID that specifies whether the transaction is IN or OUT, device address, endpoint and CRC. This packet is sent by host.

Data Packet: This packet is used to transfer the requested data. The length of the data is already specified by the wLength field. The data may be sent in more than one packet if the data length exceeds the maximum value of packet length. It used Data1 PID for the first packet and additional alternate Data0/Data1. For IN transaction, the device sends the data and for OUT transaction, the Host sends the data..

Handshake Packet: This packet is sent by Host if there is an IN transaction. The device sends this packet in case of OUT transaction. The packet provides the status of the data packet received. This packet can return ACK (valid data received), NAK (busy), STALL (request not supported or endpoint is halted) or NYET (the current transaction data has been accepted but not yet ready for another data packet). The host can only return ACK.

3. STATUS TRANSACTION

The purpose of the Status Stage is same as a Handshake Packet. The only difference is the Handshake packet provides status or completion information for a single transaction whereas the Status transaction provides status about success or failure of the entire transfer. The status transaction provides feedback or status of the completion of the above mentioned stages. Each transaction contains three packets, Token, Data and Handshake.

Token Packet: This packet contains PID that specifies whether the transaction is IN or OUT, device address, endpoint and CRC. This packet is sent by host. The value of PID will be IN if the transactions in Data Stage were OUT and vice versa.

Data Packet: This packet uses Data1 PID. It is used to specify the status of the entire transfer. The possible values of the data can be zero which indicates success, NAK (busy), or STALL (endpoint halted). The host can only transfer zero length data. For no data stage, the Status Stage specifies whether the request has been taken. For example, in Set_address request, this stage indicates that the unique address provided by the Host has been allotted.

Handshake Packet : This packet is sent by Host if there is an IN transaction. The peripheral device sends this packet if it in an OUT transaction. The PID may be ACK (success), NAK (busy) or STALL (request not supported or endpoint is halted). The host responds with ACK for successfully data received. If the receiver detects any error in the token or data packet, then no handshake packet is transferred. This packet is the final packet in the transfer.

Standard USB Requests

The following are the standard requests sent by a host device to a peripheral :

GET_STATUS: This request is used to get the status information from the device, interface or endpoint. The device returns two bytes in the data stage. The recipient can be device, interface or endpoint depending on the value of bmRequestType field. The interface number or endpoint number can be selected using wIndex field. According to the designated recipient the device returns Device Status, Interface Status or Endpoint Status.

SET_FEATURE/CLEAR_FEATURE: These requests are used to enable or disable the features of the device, interface or endpoint. The recipient can be device, interface or endpoint depending on the value of bmRequestType field. The interface number or endpoint number can be selected using wIndex field. The device returns no data in these requests. The feature can be selected using wValue field.

There is one feature for an endpoint – ENDPOINT_HALT. Setting this feature will STALL any IN or OUT transactions for an endpoint. There is no feature for an Interface. There are five possible features for a device. They are :

• DEVICE_REMOTE_WAKEUP – Setting this feature enables a standby device to request the host to resume communication through signaling the host.

• TEST_MODE – If this feature is set, the device will enter into test mode.

• B_HNP_ENABLE – This feature is only applicable on OTG devices.

• A_HNP_ENABLE – This feature is only applicable on OTG devices.

• A_ALT_HNP_SUPPORT – This feature is only applicable on OTG devices

SET_ADDRESS : This request is used to allocate a unique address to the device for communications. A device attached to the bus can be allocated address between 1 through 127. The device uses default address 0 before the allocation of a unique address. After completion of the Status Stage of this request, the USB device changes its address. The device must change its address within 20 ms after completing the Status Stage.

There is a difference between SET_ADDRESS request and all other requests. In other requests, the request action is taken before the completion of Status Stage while in SET_ADDRESS request, the result action is taken after the completion of Status Stage. The device returns no data in this request.

GET_DESCRIPTOR: This request is used to obtain the specified descriptor from the USB device and helps in identifying and configuring the device. Information related to device, endpoints, configurations and interfaces can be obtained using this request.

The high byte of wValue field specifies the descriptor type and low byte specifies the descriptor index. The descriptor index is used when there is more than one descriptor available for a particular type. The descriptor index is only used for configuration and string descriptors. For example, a device may have more than one configuration descriptors.

The wIndex value specifies the Language ID for String Descriptors and for other descriptors the value is zero. The wLength field specifies the maximum size of descriptor that can be send by the device.

SET_DESCRIPTOR: This request is used to add new or update existing descriptor. This request is optional and not often used. The wValue, wIndex and wLength field carries same information as in GET_DESCRIPTOR.

SET_CONFIGURATION: This request is used to set or enable a specified configuration for the device. After obtaining configuring information like PID/VID, the Host loads the driver and uses SET_CONFIGURATION request to configure the device.

If there is only one configuration for a device, the wValue is set to 1. For other configuration if possible, the wValue will be used to set the particular configuration. If the wValue is set to zero, it will de-configure the device. The wIndex and wLength field is zero. The device returns no data in this request. Once the device is configured, it can respond to transfer types other than Control Transfer.

GET_CONFIGURATION: This request is used to get information of the current configuration set by SET_CONFIGURATION request. The configuration value is returned by device in data stage.

SET_INTERFACE: When the device is configured, a default interface is selected. This request is used to select alternate interface other than default interface. If the requested alternate interface or setting does not exist, the device returns a STALL.

GET_INTERFACE: This request is used to check which alternate interface has been selected by SET_INTERFACE.

SYNCH_FRAME: This request is used in some isochronous transfers where the data size varies with frame. For example, an endpoint may send a sequence of 8,8,64 bytes. The host uses this request to know the exact frame in which the repeating begins. The device responds to this with data containing frame number in which the pattern begins. This request is rarely used.

The standard USB requests have been summarized below :

Validity of Requests

When a request is made, the device can be in one of three states :

1. Default State: This state occurs when the device is plugged and a unique address has not been allocated. In this state, the valid requests that can be made are only GET_DESCRIPTOR and SET_ADDRESS.

2. Addressed State: This state occurs when the device has been assigned a unique address via SET_ADDRESS request. In this, the device is ready to accept the following requests:

• SET_CONFIGURATION

• GET_CONFIGURATION

• SET_FEATURE

• CLEAR_FEATURE

• GET_STATUS

• SET_DESCRIPTOR

3. Configured State: This state occurs when the device has been configured using SET_CONFIGURATION request and now is ready to do operations. In this, the SET_ADDRESS is not a valid request. The requests that can be made only after configuration are:

• GET_INTERFACE

• SET_INTERFACE

• SYNCH_FRAME

In the next article signaling and encoding in USB interface will be discussed.