Introduction to USB protocol

Introduction to USB protocol
USB is a protocol bus, that is, the communication between the host and the device needs to follow a series of conventions. The agreement content is many, here only makes some simple introduction, in-depth study, may refer to the USB specification (WWW. usb ORG).
To understand the name in the agreement, look at Figure 10. 32. The diagram highlights the communication flow (communication flow) between the client software on the host and the USB logic device (the device involved), which spans the USB driver USBD, the host controller driver UHCD, the host controller, and other hardware interfaces and their connections. The endpoint (endpoints) is the only identifiable part of the USB device that is the endpoint of the communication flow between the host and the device. Each logical device has several independent endpoints, each of which is assigned a unique device-determined identifier, called the endpoint number, at design time.
10. As shown in 32, the channel that will be used for the flow of traffic is called the pipe, which is a very vivid salutation that ignores many intermediate links, which is helpful for understanding the transmission of information in USB system. The figure shows 3 endpoints as an interface, and the instructions for the interfaces are arranged behind.

1. Package format
The concept of the package has been described earlier, and the package is the basic component of the frame. Common packages are tokens, packets, and handshake packets. For high-speed transmissions, it also defines a dedicated token package for transaction splitting (transaction split start token package and transaction split completion token package).
1) Token package format
In a USB system, all communication is caused by the host issuing the corresponding token. Token package Format diagram
10. As shown in 33.
Wherein the PID is the package identification, addr is the device address, ENDP is the endpoint number, CRC5 is the addr and ENDP domain to verify the 5-bit CRC check code, the check polynomial is: G (X) =x5+x2+1.
2) Packet format
The packet is used for data transfer between the host and the device. Packet format 10. As shown in 34.
Where the PID is the packet identity, data is a bit, up to 8 192 bits, and data should be an integer multiple of bytes. The CRCL6 is a 16-bit CRC checksum that verifies the data domain, and the checksum polynomial is: G (X) =x16+x15+x2+1.

3) Handshake Package format
The handshake packet is used to indicate that the data was successfully received, that the command was received or rejected, and so on. Handshake package Format 10. As shown in 35.
The handshake package consists only of PII. There are four commonly used handshake packets (ACK, NAK, Stall and Nyet) and a dedicated handshake package, the type of the handshake packet is represented by the PID encoding.
· An ACK packet indicates that the sink 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 terminated or does not support a control pipeline request.
· The Nyet package indicates that the receiver has not responded yet.
4) frame start Package sof (start of frame)

At full speed or low speed, the host is ms±0 every 1. 0005 MS emits a frame to start the package SOF, at high speed, every 125μs±0. 0625μs emits a SOF to indicate the beginning of a new frame. SOF package Format 10. As shown in 36.

Where Fmmenumber is the frame number, after each post frame Framenumber plus L, when 11 bits are 1 (that is, 3FFH) and add 1 back to 0. CRC validation of the Framenumber domain in the SOF package.
2. PID domain format
The first of the packages above is the PID domain. PID domain format 10. As shown in 37.

The low 4 bits are used to identify different packages, and the high 4 bits are low 4 bits respectively. This arrangement is designed to ensure a reliable decoding of the PID, which also enables the other parts of the package to be correctly interpreted. Table Lo. 20 represents the PID code and the corresponding PID type. The 3rd column is the low 4-bit PID, which is the PID code.
There are two kinds of data packet pid in the table, both of which are used for data transmission, and the other parts are the same in addition to one bit of the PID part (and the opposite bit corresponding to it). Both of these packets are set up to keep the sender and receiver in sync, which involves some details that will be in 10. 3. described in section 6. In Figure 10. 38~10. You might think of them as a packet in 40.

3. The process of USB transmission
As mentioned above, there are four types of transmissions in the USB system: A transmission is usually broken down into several transactions, while a transaction typically undergoes three stages of token package, packet and handshake package, but there are also some transactions that do not have a packet phase or no handshake package stage, and some transactions are only token package stages. The following four kinds of transmission of the processing process are described separately.
1) Block transfer
Used for bulk data transfer between the host and USB devices, usually one-time block transfer needs to be decomposed into several block transport transactions. Obviously, the direction of a block transfer is single, for the host, either input or output. Therefore, the one-time block transfer is made up of several in transactions or a number of out transactions. Figure 10. 38 shows the block transport transaction process. The ping package and the Nyet package are only used for high-speed transmission devices, and beginners can not consider them for the time being.

    for the block transfer to be entered, a number of in transactions are typically performed. Each time an in transaction is executed, the host first issues an in token package. When a device endpoint receives a response, it typically sends back a packet. If the data cannot be echoed, echo the NAK packet or the stall package. NAK indicates that the device is temporarily unable to send back data, stall indicates that the endpoint has been stopped or needs to intervene IJSB system software, and if the host receives a legitimate packet, the ACK handshake packet is returned, and if the host finds an error while receiving the data, no echo is given to the device.
    A number of out transactions are typically performed for the block transport to be output. Each time an out transaction is executed, the host first issues the out token package and then sends the packet. After receiving the packet, the device returns to the handshake packet according to the situation, and the ACK indicates that the data has been received correctly, and notifies the host to start the next 0UT transaction in order to transmit the next packet, and the NAK to indicate that the data is received correctly, but the host does not send the data because the device is temporarily unavailable (e.g. buffer full If the endpoint is terminated, return to stall and notify the host not to re-send the data because the device has failed, and if a CRC checksum error occurs at the time of receipt, no handshake packets are sent.
    needs to point out that in and out transactions are not only used in block transport transactions, but also in several other transport transactions, of course, the process may be different.
    2) interrupt transmission
    for data transmission of small, non-cyclical, but sensitive to response time, requires immediate response to the transmission. The name of the interrupt transmission implies that a device can cause a hardware outage, and this hardware outage will allow the host to respond quickly. But the real situation is that the interrupt transmission is the same as all other USB transmissions, only when the host accesses the device. This is referred to as an interrupt transmission because it ensures that the host will respond to or send data in the shortest delay. What is special about interrupt transmission is that the host will access the endpoint that can cause the interruption (called the interrupt endpoint) for a specific period of time to see if there is an outage. Figure 10. 39 shows the process of interrupting the transport transaction.

For an interrupt transmission to be entered, the host executes the in transaction on a specific cycle, and if no interruption occurs, the interrupt endpoint is returned to the NAK packet, and the interrupt data is echoed if there is an outage. After the host receives the data, it sends an ACK packet.
For an interrupt transmission to be output, the host executes an out transaction for a specific period, and then sends the packet after the out token is sent. If no interruption occurs, the interrupt endpoint is returned to the NAK packet or the stall packet, and the ACK packet is echoed if the interrupt occurs and the data is received without error. It should be noted that, in the event that the device is not interrupted, the host will always execute the out transaction on a specific cycle, and the data being sent remains unchanged. When an interrupt occurs, the data pointer is modified to point to the next data area.
An interrupt transport consists of one or more in transactions or one or more out transactions. An interrupt transfer ends with one of the following two scenarios: when the requested amount of data is delivered, or when the packet length is less than the specified maximum value (including 0-length packets). The end of the interrupt transfer indicates that the data to be transferred is already aligned and the receiver can take advantage of it, and that the host's periodic query to the interrupt endpoint will continue so that the next interrupt transmission begins when the next interrupt occurs.
3) equal-time transmission
Used for data transmission with periodic and constant transfer rates. The number of bytes transmitted in each frame by the equal-time transmission is certain. An equal-time transmission consists of one or more successive frames per frame in a in or an out office. Figure 10. 40 indicates the processing of the equal-time transport transaction. It can be seen that the in and out transactions of the time-of-transport include only the token package and the packet two phases, no handshake packet phase, and no support for retries.

4) control transmission
Control transport provides a way to configure a USB device and to control certain aspects of its operation. Each device must have a default control endpoint (usually the O endpoint) set. Control endpoints are used to configure devices, control device status, and some aspects of device operation. The control endpoint responds to some USB special requests that are sent over the control transmission. For example, when the system detects a device, the system software must read the device's descriptor to determine its type and operating characteristics.
The control transmission consists of at least two stages or three stages:
①setup phase: The control transfer is always initiated from the setup stage, which sends the information to the target device, defining the type of request for the device (for example, a read device descriptor).
② Data phase: This phase is only defined for requests that require data transfer. For example, in the data phase, the read descriptor requests the contents of the descriptor to be sent to the host. Some requests do not require data transfer outside of the setup phase.
③ State phase: This stage is always used to report the result of the requested operation.
In the setup phase, a setup transaction is used to transmit information to the control endpoint. Setup transactions are similar to
An out transaction, just the package identity PID is setup, not out. Figure 10. 41 shows the setup transaction execution process. The data phase of the Setup transaction always utilizes the DATA0 PID. If received correctly, the control endpoint is returned with an ACK packet, and if the receive is incorrect or the data is lost, no handshake packets are echoed.

The data phase of the control transfer is not required. If this phase is required, it consists of one or more in transactions or one or more out transactions. The direction of all transactions in the data phase must be consistent, that is, both in transactions or out transactions. The amount and direction of data transmitted during the data phase is specified in the setup phase. If the amount of data exceeds the predetermined packet size, the data is sent with more than one transaction (in or out) that can carry the largest packet, and the remainder (less than the maximum packet size) is then scheduled for a transaction.
The state phase of the control transport is the last phase of the transmission, and it requires only one transaction. The flow direction of the state phase should be different from the previous phase, and always take advantage of the datal PID. For example, if the data stage executes an out transaction, the state stage is an in transaction. If there is no data stage for a control transfer, the state stage consists of an in transaction. Figure 10. 42 shows the sequence of transactions, the value of the triggering bit (in parentheses), and the type of data PID, which control the read transmission, the control of the write transmission, and the control transmission without the data stage.

The processing of the transport and transport transactions described above reflects the process of data transmission in the USB system. Notice that there are four transport transactions in a frame (or a micro-frame), so the actual transfer process is more complex than the one described here.
4. Data triggering technology
The data triggering technology is adopted in the USB system. Data triggering is a mechanism used to ensure synchronization between the sender and receiver of the data transfer, which is especially important for a long transmission process that requires a large number of transactions. The data triggering mechanism enables resynchronization between the sender and the receiver in case of an error in the handshake packet.
Data triggering only supports interrupt transmission, block transfer, and control transfer. The sender and receiver supporting the data triggering mechanism must have a trigger bit at each data transfer. When both parties believe that the data transfer has been completed correctly, they will convert their trigger bit to the opposite state. Two types of packets (Datao and datal) are alternately transmitted, and the receiver of the packet will compare it to the trigger bit to determine if the received packet is correct. The sender uses a packet type that is consistent with the current state of its trigger bit (for example, if the trigger bit is 0, the packet is DATA0). The following is only an example of an out transaction to understand the data triggering mechanism.
Example 10. 1 Figure 10. 43 shows the process of error-free out transaction and the change of the trigger bit. Assume that the trigger bit for both the sender and the receiver starts at 0. The process of transmission

As follows:
Transact-Handle L:

The ① host sends an out token to the target device.
The ② target device received the token package without error.
The ③ host sends a DATA0 packet (consistent with its trigger bit) to the target device.
The ④ target device receives the packet DATA0, which is consistent with the trigger bit.
The ⑤ target device successfully receives the packet DATA0, and the trigger bit transitions to 1.
The ⑥ target device sends an ACK handshake packet to the host notifying the host that the data has been received without errors.
The ⑦ host received an ACK packet without error.
⑧ successfully received the ACK packet, the host changed the trigger bit to L.
Transaction Processing 2:
The ① host sends a new out token to the target device and begins the next transaction process.
The ② target device received the token package without error.
The ③ host sends a DAL, A1 packet (and its trigger bit consistency) to the target device.
The ④ target device receives the packet datal, which is consistent with the trigger bit.
The ⑤ target device successfully receives the packet datal, and the trigger bit transitions to 0.
The ⑥ target device sends an ACK handshake packet to the host notifying the host that the data has been received without errors.
The ⑦ host received an ACK packet without error.
⑧ successfully received the ACK packet, the host changed the trigger bit to 0.
This process is true for every transaction until the entire transfer is complete. As long as the received packet is consistent with the triggering phase, and the sender receives the ACK handshake packet without error, the sender and receiver remain in sync.
Above is the case where both the packet and handshake packets are transmitted correctly. The following are the cases where the packet transmission error and the handshake packet transmission error are seen separately.
Example l0.2 Figure 10. 44 is shown as the first m out of a transmission. The processing of a transaction, during which an error occurred during packet transmission. The actions taken by the host and target devices are as follows:
Transaction processing M:
The ① host sends an out token to the target device.
The ② target device received the token package without error. ，
The ③ host sends a DATA0 packet (consistent with its trigger bit) to the target device.
④ An error was found when the target device received a packet Datao.
⑤ the target device will ignore the packet because it detects a packet error. Data is discarded and no handshake packets are sent to the host. The trigger bit remains unchanged because the packet is not received correctly.
The ⑥ host waits for the handshake package to return, but does not respond. After the bus timeout period (16 bit time) arrives, the host detects that there is no response, so it considers that the transmission of the packet is unsuccessful and the trigger bit of the host remains unchanged. The host must re-process the transaction at a later time.
Transaction M re-performed:
The ① host then sends an out token to the target device.
The ② target device received the token package without error.
The ③ host sends a DATAO packet to the target device (consistent with its trigger bit), which was unsuccessful on the last transmission.
The ④ target device successfully receives the packet DATA0, which is consistent with the trigger bit.
⑤ because the packet DATA0 is correctly received, the target device turns the trigger bit to 1.
The ⑥ target device sends an ACK handshake packet to the host notifying the host that the data has been received without errors.
The ⑦ host received an ACK packet without error.
⑧ successfully received the ACK packet, the host changed the trigger bit to L.
As can be seen from the above process, the host and target device can remain in sync despite the transmission error.

    Example 10. 3  Figure 10. 45 shows the processing of the nth out transaction for a transmission, which failed during the ACK packet error. Each step for error detection and recovery is listed as follows:
    transaction N:
The    ① host sends an out token to the target device. The
   ② target device received the token package without error.
   ③ then the host sends a DATA0 packet to the target device (and its trigger bit is consistent). The
   ④ target device receives the packet DATA0, which is consistent with the trigger bit. The
   ⑤ target device successfully received the packet DATA0, and the trigger bit transitions to 1. The
   ⑥ target device sends an ACK handshake packet to the host notifying the host that the data has been received without errors. An error occurred in the ACK packet received by the
   ⑦ host.
   ⑧ because the host detected an error, it cannot determine whether the target device has successfully received the data. Therefore, the trigger bit of the host does not change (or 0). The host assumes that the target device did not receive the data, and therefore the transaction is re-processed.
    Transaction N re-   ①:
The host then sends an out token to the target device. The
   ② target device received the token package without error. The
   ③ host re-sends the DATA0 packet to the target device (and its trigger bit is consistent), the packet was last passed  

It is not known if the target device was received correctly.
The ④ target device does not receive the packet DATA0 incorrectly, but it does not match the trigger bit.
The ⑤ target device considers itself to be out of sync with the host, discarding the data, and the trigger bit remains unchanged (1).
The ⑥ target device sends an ACK handshake packet to the host notifying the host that the data has been received without errors because
The host obviously did not receive the last ACK handshake package.
The ⑦ host received an ACK handshake packet without error.
⑧ successfully received the ACK packet, the host changed the trigger bit to 1. Now the host and target devices are ready for the next transaction.
This example shows that the host and target devices are temporarily not agreeing on the issue of whether the data transfer is complete. However, the data triggering mechanism ensures that the state of the synchronization can be detected and can be re-implemented.

Introduction to USB protocol (RPM)