Control Transfer is the only supported transfer type even when the device is not yet configured. Therefore, it is used to send requests and obtain descriptors. The default terminal is terminal 0, which is bidirectional and used for control transfers.
Therefore, the first request requested by the host from the peripheral involves only a transfer of control. As discussed earlier when discussing the USB protocol, control transfer consists of three transactions – configuration transaction, data transaction (optional), and status transaction.
1. CONFIGURATION TRANSACTION
Control transfer begins with a configuration stage. The configuration transaction is used at this stage. The transaction consists of three packages – Token, Data and Handshake.
Token bundle: It contains configuration PID (packet identifier), device address, endpoint and CRC. The default endpoint and device address 0 are used. The address is updated after assigning a unique address to the device. This packet is sent by the host.
Data Packet: It contains Data0 PID. The data payload is 8 bytes. This packet is also sent by the host. The content of the data payload includes the following fields:
• bmRequestType – This field provides information related to data direction, request type, and designated recipient. Bit 7 represents the direction of data flow in the data stage. Bits 5 to 6 represent the request type. Bit 4-0 specifies the recipient of the request.
• bRequest – The type of request can be selected by bmRequestType. The unique bRequest value specifies one of the selected requests. For example, the 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 the host to the device with the request. For example, in the Set_Address request, wValue contains the device address.
• wIndex – This field also specifies the information that needs to be passed from the host to the device with the request. Typical usage includes passing the endpoint or interface number. For endpoint, bit 3-0 represents the endpoint number and bit 7 represents the direction; 0: OFF; 1: IN. For interface, bit 7-0 represents the interface number.
2. DATA TRANSACTION
This is the optional second stage of the Transfer of Control. At this stage, the requested data is transferred. It contains multiple IN or OUT transactions. Each transaction contains three packets, Token, Data and Handshake.
Token package: This package contains PID that specifies whether the transaction is IN or OUT, device address, endpoint and CRC. This packet is sent by the host.
Data Packet : This packet is used to transfer the requested data. The length of the data is already specified by the wLength field. Data can be sent in more than one packet if the length of the data exceeds the maximum packet length value. 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 the Host if there is an IN transaction. The device sends this packet in case of OUT transaction. The packet provides the status of the received data packet. This packet can return ACK (valid data received), NAK (busy), STALL (unsupported request or stopped endpoint), or NYET (current transaction data has been accepted but is not yet ready for another data packet). The host can only return ACK.
3. STATUS TRANSACTION
The purpose of the Status Stage is the same as a Handshake Packet. The only difference is that the Handshake package provides status or completion information for a single transaction, whereas the Status transaction provides status on the success or failure of the entire transfer. The status transaction provides feedback or status of completion of the steps mentioned above. Each transaction contains three packets, Token, Data and Handshake.
Token package: This package contains PID that specifies whether the transaction is IN or OUT, device address, endpoint and CRC. This packet is sent by the host. The PID value will be IN if the transactions in the Data Stage are OUT and vice versa.
Data Packet: This packet uses Data1 PID. It is used to specify the status of the entire transfer. Possible data values can be zero, which indicates success, NAK (busy) or STALL (endpoint stopped). The host can only transfer zero-length data. For no data stage, the Status Stage specifies whether the request has been fulfilled. For example, in the Set_address request, this stage indicates that the unique address provided by the Host has been allocated.
Handshake packet: This packet is sent by the Host if there is an IN transaction. The edge device sends this packet if it is in an OUT transaction. The PID can be ACK (success), NAK (busy) or STALL (unsupported request or stopped endpoint). The host responds with ACK for successfully received data. If the receiver detects an error in the token or data packet, no handshake packet will be transferred. This package is the final package of the transfer.
Standard USB requests
The following are standard requests sent by a host device to a peripheral:
GET_STATUS: This request is used to obtain device, interface, or endpoint status information. The device returns two bytes in the data stage. The recipient can be a device, interface or endpoint depending on the value of the bmRequestType field. The interface number or terminal number can be selected using the 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 features of the device, interface, or endpoint. The recipient can be a device, interface or endpoint depending on the value of the bmRequestType field. The interface number or terminal number can be selected using the wIndex field. The device does not return data in these requests. The resource can be selected using the wValue field.
There is a resource for an endpoint – ENDPOINT_HALT. Setting this feature will STOP any IN or OUT transactions to an endpoint. There is no resource for an interface. There are five possible features for a device. They are :
• DEVICE_REMOTE_WAKEUP – Setting this feature allows a standby device to request the host to resume communication by signaling to the host.
• TEST_MODE – If this feature is configured, the device will enter test mode.
• A_HNP_ENABLE – 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 connected to the bus can be assigned addresses between 1 and 127. The device uses the default address 0 before a unique address is allocated. After the Status Step of this request is completed, the USB device changes address. The device must change its address within 20 ms of completing the Status Stage.
There is a difference between the SET_ADDRESS request and all other requests. In other requests, the request action is performed before the Status Stage is completed, while in the SET_ADDRESS request, the result action is performed after the Status Stage is completed. The device returns no data in this request.
GET_DESCRIPTOR: This request is used to obtain the specified descriptor of the USB device and assists in identifying and configuring the device. Information related to devices, endpoints, configurations, and interfaces can be obtained using this request.
The high byte of the wValue field specifies the descriptor type and the low byte specifies the descriptor index. The descriptor index is used when there is more than one descriptor available for a given type. The descriptor index is only used for configuration and string descriptors. For example, a device may have more than one configuration descriptor.
The wIndex value specifies the language ID for string descriptors and for other descriptors the value is zero. The wLength field specifies the maximum descriptor size that can be sent by the device.
SET_DESCRIPTOR : This request is used to add a new descriptor or update an existing descriptor. This request is optional and is not frequently used. The wValue, wIndex and wLength fields carry the same information as GET_DESCRIPTOR.
SET_CONFIGURATION : This request is used to set or activate a specific configuration for the device. After obtaining configuration information such as PID/VID, the Host loads the driver and uses the SET_CONFIGURATION request to configure the device.
If there is only one setting for a device, wValue will be set to 1. For other settings, if possible, wValue will be used to define the specific setting. If wValue is set to zero, it will unconfigure 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 other types of transfers besides Control Transfer.
GET_CONFIGURATION : This request is used to obtain current configuration information defined by the SET_CONFIGURATION request. The configuration value is returned by the device in the data stage.
SET_INTERFACE: When the device is configured, a default interface is selected. This request is used to select an alternative interface other than the default interface. If the requested interface or alternative configuration does not exist, the device returns a STALL.
GET_INTERFACE: This request is used to check which alternative interface was selected by SET_INTERFACE.
SYNCH_FRAME : This request is used in some isochronous transfers where the data size varies with the frame. For example, an endpoint can send a sequence of 8,8,64 bytes. The host uses this request to know the exact frame at which the replay begins. The device responds to this with data containing the frame number at which the pattern begins. This request is rarely used.
Standard USB requests have been summarized below:
Validity of Requests
When a request is made, the device can be in one of three states:
2. Addressed state: This state occurs when the device has been assigned a unique address through the SET_ADDRESS request. In this, the device is ready to accept the following requests:
• SET_CONFIGURATION
• GET_CONFIGURATION
• SET_FEATURE
• CLEAR_FEATURE
• GET_STATUS
3. Configured state: This state occurs when the device has been configured using the SET_CONFIGURATION request and is now ready to perform operations. In this case, SET_ADDRESS is not a valid request. Requests that can be made only after configuration are:
• GET_INTERFACE
• SET_INTERFACE
In the next article signaling and coding in USB interface will be discussed.
