USB protocol Overview

USB protocol Overview
USB is a protocol bus, that is, the communication between the host and the device must follow a series of conventions. There are many protocols. Here is a brief introduction. For more information, see USB specifications (www.usb.org ).
To understand the name in the protocol, see Figure 10.32. This figure highlights the communication flow between the client software on the host and the USB logic device (the device involved in programming). The communication flow spans the USB driver.ProgramUsbd, master controller driver uhcd, master controller and other hardware interfaces and their connection. An endpoints is the only identifiable part of a USB device and the end point of the communication flow between the host and the device. Each logical device has several independent endpoints, each of which is assigned a unique identifier determined by the device during design, called the endpoint number.
As shown in figure 10.32, the channel used for communication flow is called pipe, which ignores many intermediate links and is helpful for understanding information transmission in the USB system. In the figure, the three endpoints are considered as an interface, and the description of the interface is arranged later.

 

1. package format
The concept of a package is described earlier. A package is the basic component of a frame. Common packages include token packages, data packets, and handshake packets. For high-speed transmission, a dedicated token package for transaction segmentation is also defined (transaction segmentation begins with the token package and transaction segmentation completes the token package ).
1) token package format
In the USB system, all communication is caused by the host issuing the corresponding token. Token package format
10.33.
PID indicates the package ID, ADDR indicates the device address, endp indicates the endpoint number, and crc5 indicates the 5-bit CRC verification code for the ADDR and endp fields. The verification polynomial is g (x) = X5 + X2 + 1.
2) data packet format
Data packets are used for data transmission between the host and the device. The data packet format is 10.34.
The PID is the package ID, and data is the data bit, which can be 8 to 192 digits at most. The data should be an integer multiple of the bytes. Crcl6 is a 16-bit CRC verification code for data domain verification. The verification polynomials are: g (x) = x16 + x15 + X2 + 1.

3) handshake packet format
A handshake package is used to indicate the transaction status, such as the successful receipt of data, the receipt of commands, and the rejection. The handshake package format is 10.35.
A handshake package consists of only PII. There are four common handshake packages (ACK, Nak, stall, and nyet) and a dedicated handshake package. The type of the handshake package is represented by PID encoding.
· Ack package indicates that the receiver has successfully received data.
· The nak package indicates that the receiving device cannot receive data or the sending device cannot send data.
· The stall package indicates that the endpoint has been terminated or the MPs queue control request is not supported.
· The nyet package indicates that the receiver has no response.
4) frame start package sof (start of frame)

 

When the host is at full speed or low speed, the host is at intervals of 1 ms ± 0. 0005 MS sends a frame start packet Sof, at high speed, every 125 μs ± 0. 0625 μs sends out a sof to start a new frame. The format of SOF package is 10.36.

Fmmenumber indicates the frame number. After each frame is sent, framenumber is added with L. When 11 bits are 1 (that is, 3ffh), 1 is added and 0 is returned. Perform CRC verification on the framenumber field in the sof package.
2. PID domain format
The above packages start with the PID field. The PID format is 10.37.

 

The lower 4 bits are used to identify different packages. The higher 4 bits are the lower 4 bits. This arrangement is to ensure reliable decoding of the PID, so that other parts of the package can be correctly explained. Table lo.20 represents the PID encoding and the corresponding PID type. Among them, the 3rd column is the low 4-bit PID, that is, PID encoding.
Two data packet PIDs are used for data transmission. The two data packets whose names start with them are different except that the packet PID contains one bit (and the corresponding reverse bit, the other parts are the same. These two types of data packets are set to keep the sender and receiver synchronized. This involves some details, which will be described in section 10.3.6. See Figure 10.38 ~ 10.40 may consider them as a data packet.

3. Processing of USB transmission
As mentioned above, there are four types of transmission in the USB system: one transmission is usually divided into several transactions, and the processing of one transaction generally goes through three stages: token packet, data packet, and handshake packet, however, some transactions do not have the data packet phase or the handshake packet phase, and some transactions only have the token packet phase. The following describes the processing of these four types of transmission.
1) Block Transmission
It is used for batch data transmission between the host and USB devices. Generally, a single block transmission must be divided into several Block Transmission transactions. Obviously, the direction of one block transmission is single. For the host, it is either input or output. Therefore, a block transfer is composed of several in transactions or several out transactions. Figure 10.38 shows the transaction processing process of block transmission. The Ping package and nyet package in the figure are only used for high-speed transmission devices. For the time being, you can ignore them.

for block transfer to be input, several in transactions are generally executed. Each time an in transaction is executed, the host first issues an in token package. The device endpoint responds after receiving the packet. Generally, a packet is sent back. If data cannot be returned, the Nak package or stall package will be returned. Nak indicates that the device cannot send data back for the time being. Stall indicates that the endpoint has been stopped or the ijsb system software is required to intervene. If the host receives valid data packets, the ACK handshake packet is returned; if an error occurs when the host receives data, no response is sent to the device.
for block transmission to be output, several out transactions are generally executed. Each time an out transaction is executed, the host sends out the out token packet first and then sends out the data packet. After the device receives the data packet, it will return to the handshake package based on the situation. Ack indicates that the data has been received correctly, and notifies the host to start the next 0ut transaction to transmit the next data packet; the returned Nak indicates that the data has been received correctly, but the host does not send data any more, because the device cannot receive the data temporarily (such as the buffer is full). If the endpoint is terminated, stall is returned, notify the host not to resend data because the device is faulty. If CRC verification is incorrect during receiving, no handshake packet is sent.
it should be noted that in transactions and out transactions are used not only in block transfer transactions, but also in other transmission transactions. Of course, the process may be different.
2) interrupted transmission
this function is used for data transmission with low data transmission volume and no periodicity. However, it is sensitive to response time and requires immediate response. The name of the interrupted transmission implies that a device can cause a hardware interruption, which will cause the host to respond quickly. However, the actual situation is that the interrupted transmission occurs only when the host accesses the device, just like all other USB transmissions. It is called interrupted transmission because it ensures that the host will respond to or send data in the shortest latency. The special feature of interrupted transmission is that the host will access the endpoint that can cause the interruption according to a specific cycle (called the interruption endpoint) to check whether there is any interruption. Figure 10.39 shows the process of stopping a transfer transaction.

For the interrupted transmission to be input, the host executes in transactions according to a specific cycle. If there is no interruption, the interrupt endpoint will return to the Nak package. If there is any interruption, the interrupted data will be sent back. The host sends an ACK packet after receiving the data.
For the interrupted transmission to be output, the host executes the out transaction according to the specific cycle, and then sends the packet after the out token is sent. If there is no interruption, the interrupt endpoint will return to the Nak package or stall package. If there is an interruption and the received data is correct, the ACK package will be sent back. It should be noted that when the device is not interrupted, the host will always execute the out transaction according to the specific cycle, and the data sent remains unchanged. When an interruption occurs, the Data Pointer is modified and directed to the next data zone.
An interrupted transmission is composed of one or more in transactions or one or more out transactions. An interrupted transmission ends in either of the following two cases: when the requested data volume is transferred, or when the packet length is smaller than the specified maximum value (including a 0-Length Packet. The end of the interrupted transmission indicates that the data to be transmitted has been completed and can be used by the receiver. The host will continue to periodically query the interrupted endpoint so that when the next interruption occurs, start the next interrupted transmission.
3) Time Transmission
It is used for data transmission with periodic and unchanged transmission rates. The number of bytes transmitted in each frame is certain. An equi-time transmission is composed of one in or one out transaction in one or more consecutive frames. Figure 10.40 shows the processing process of the synchronization transaction. It can be seen that the in transaction and out transaction transmitted at the same time only include two phases: the token package and the data packet. There is no handshake packet phase and retry is not supported.

4) Control Transmission
Control Transmission provides a way to configure a USB device and control some aspects of its operations. Each device must have a default control endpoint (usually the O-number endpoint ). The control endpoint is used to configure the device, control the device status, and perform operations on the device. The control endpoint responds to some USB special requests sent by control transmission. For example, when the system detects a device, the system software must read the descriptor of the device to determine its type and operating characteristics.
Control Transmission consists of at least two stages, or three stages:
① Setup stage: control transmission always starts from setup stage. In this stage, information is sent to the target device and the request type (for example, read device descriptor) of the device is defined ).
② Data stage: This stage is only defined for requests requiring data transmission. For example, in the data stage, the read descriptor request sends the descriptor content to the host. Some requests do not require data transmission outside the setup phase.
③ Status phase: this phase is always used to report the results of the requested operation.
In the setup phase, a setup transaction is used to transmit information to the control endpoint. The setup transaction is similar
An out transaction only identifies the PID as setup rather than out. Figure 10.41 shows the execution process of the setup transaction. The data phase of the setup transaction always uses the data0 PID. If the receiving is correct, the control endpoint returns an ACK packet. If the receiving is incorrect or data is lost, no handshake packet is returned.

The data phase of control transmission is not required. If this stage is required, it is composed of one or more in transactions or one or more out transactions. All transactions in the data phase must be in the same direction, that is, both in transactions or out transactions. The data volume and direction transmitted in the data phase are defined in the setup phase. If the data volume exceeds the predefined data packet size, data transmission requires multiple transactions (in or out) that can carry the largest package, and the rest (below the maximum package size) schedule another transaction.
The state phase of control transmission is the last phase of the transmission. It only needs one transaction. The data flow direction of the State stage should be different from that of the previous stage, and always uses datal PID. For example, if the data stage executes an out transaction, the State stage is an in transaction. If a control transmission has no data phase, the state phase consists of an in transaction. Figure 10.42 shows the transaction arrangement sequence, trigger bit values (in parentheses), and data PID types for controlling read transmission, write transmission, and transfer without data stages.

The transmission and transaction processing process described above reflects the data transmission process in the USB system. Note that a frame (or microframe) contains four transmission transactions, so the actual transmission process is more complex than described here.
4. Data trigger Technology
Data triggering technology is adopted in the USB system. Data triggering is a mechanism used to ensure synchronization between the sender and receiver of data transmission. It is particularly important for a long transmission process that requires a large number of transactions. The data trigger mechanism allows the sender and receiver to be re-synchronized when a handshake packet error occurs.
Data trigger only supports interrupted transmission, block transmission, and control transmission. The sender and receiver supporting the data trigger mechanism must have a trigger bit during each data transmission. When both parties believe that data transmission has been completed correctly, they will convert their trigger bit to the opposite state. Two types of data packets (datao and datal) are transmitted alternately, and the receiver of the packet will compare it with the trigger bit to determine whether the received packet is correct. The data packet type used by the sender is consistent with the current status of its trigger bit (for example, if the trigger bit is 0, the data packet uses data0 ). The following uses an out transaction as an example to understand the data trigger mechanism.
Example 10.1 figure 10.43 shows the handling process and trigger bit changes of the out transaction without errors. Assume that both the sender and receiver start with 0 trigger bits. Transmission process

 

As follows:
Transaction Processing L:

 

① The host sends an out token to the target device.
② The target device receives the token packet without error.
③ The host sends a data0 data packet to the target device (consistent with its trigger bit ).
④ The target device receives the data packet data0, which is consistent with the trigger bit.
⑤ The target device successfully receives the data packet data0, and the trigger bit is changed to 1.
⑥ The target device sends an ACK handshake packet to the host, notifying that the host data has been received without error.
7. The host receives the ACK packet without error.
The supervisor successfully receives the ACK packet, and the host changes the trigger bit to L.
Transaction Processing 2:
① The host sends a new out token to the target device to start the next transaction processing process.
② The target device receives the token packet without error.
③ The host sends a dal and A1 data packet to the target device (consistent with its trigger bit ).
④ The target device receives the data packet datal, which is consistent with the trigger bit.
⑤ The target device successfully receives the data packet, and the trigger bit is changed to 0.
⑥ The target device sends an ACK handshake packet to the host, notifying that the host data has been received without error.
7. The host receives the ACK packet without error.
The supervisor successfully receives the ACK packet, and the host changes the trigger bit to 0.
This process is true for every transaction until the entire transmission is completed. As long as the received data packet is consistent with the trigger phase and the sender does not mistakenly receive the ACK handshake packet, the sender and the receiver are synchronized.
The preceding figure shows that both data packets and handshake packets are correctly transmitted. The following describes the data packet transmission errors and handshaking packet transmission errors.
Figure 10.44 In l0.2 shows the M-out of a transmission. During the transaction processing process, packet transmission errors occur. The actions taken by the host and the target device are as follows:
Transaction Processing M:
① The host sends an out token to the target device.
② The target device receives the token packet without error. ,
③ The host sends a data0 data packet to the target device (consistent with its trigger bit ).
④ When the target device receives the data packet datao, an error is found.
⑤ The packet will be ignored by the target device due to a packet error detected. The data is discarded and no handshake packet is sent to the host. Because the packets are not correctly received, the trigger bit remains unchanged.
⑥ The host waits for the return of the handshake packet but does not respond. When the bus time-out period (16-bit time) arrives, the host detects no response. Therefore, it deems that the data packet transmission is unsuccessful and the trigger bit of the host remains unchanged. The host must re-process the transaction later.
Re-Execute transaction M:
① The host then sends an out token to the target device.
② The target device receives the token packet without error.
③ The host sends a datao packet (consistent with its trigger bit) to the target device. This packet failed during the previous transfer.
④ The target device successfully receives the data packet data0, which is consistent with the trigger bit.
⑤ Because the data packet data0 is correctly received, the target device converts the trigger bit to 1.
⑥ The target device sends an ACK handshake packet to the host, notifying that the host data has been received without error.
7. The host receives the ACK packet without error.
The supervisor successfully receives the ACK packet, and the host changes the trigger bit to L.
The above process shows that, despite the transmission error, the host and the target device can still be synchronized.

 

example 10.3 figure 10.45 shows the process of processing the nth out transaction of a transmission, which fails due to an ACK packet error. Each step of error detection and recovery is listed as follows:
transaction processing N:
① The host sends an out token to the target device.
② the target device receives the token packet without error.
③ the host then sends a data0 packet to the target device (consistent with its trigger bit ).
④ the target device receives the data packet data0, which is consistent with the trigger bit.
⑤ the target device successfully receives the data packet data0, and the trigger bit is changed to 1.
⑥ the target device sends an ACK handshake packet to the host to notify the host that the data has been received without error.
the host receives an ACK packet error.
because the host detects an error, it cannot determine whether the target device has successfully received the data. Therefore, the trigger bit of the host is not changed (or 0 ). The host re-processes the transaction if the target device does not receive the data.
transaction n re-executed:
① The host sends an out token to the target device.
② the target device receives the token packet without error.
③ the host resends the data0 packet to the target device (consistent with its trigger bit). This packet is uploaded in the previous upload.

The target device has received the message correctly.
④ The target device receives the data packet data0 without error, but it is inconsistent with the trigger bit.
⑤ The target device considers itself as not synchronized with the host, so the data is discarded and the trigger bit remains unchanged (1 ).
⑥ The target device sends an ACK handshake packet to the host, notifying that the host data has been received without error. This is because
The host apparently did not receive the last ack handshake packet.
7. The host receives the ACK handshake packet without error.
The supervisor successfully receives the ACK packet, and the host changes the trigger bit to 1. Now the host and target devices are ready for the next transaction processing.
In this example, we can see that there is no agreement between the host and the target device on whether data transmission is complete. However, the data trigger mechanism ensures that the State of non-synchronization can be detected and can be synchronized again.