USB System Architecture

Handshake Packet Errors

Handshake packet errors leave the target and host in disagreement about whether the transaction has completed successfully or has failed. The following paragraphs explain the problem.

During OUT Transactions. During OUT transactions the token and data packets may be received without errors. The target indicates receipt of the data by returning an ACK handshake packet to the host. If errors are detected when the ACK packet is received, the packet will be ignored by the host and the transaction will fail. The target has in fact received the data, but the corrupted handshake misinforms the host of the completion status. The host and target now disagree on whether the transaction has completed successfully or not.

The host believing that an error has occurred, attempts to send the packet again. The target recognizing that the packet has been received, is expecting the next consecutive data item. When the target accepts the retried data, the same data will have been accepted twice. This potential problem is solved with the data toggle procedure discussed in “Data Toggle Errors” on page 175.

During IN Transactions. Note that a similar circumstance can occur during an IN transaction where data has successfully transferred between the target and host. The host returns ACK to the target, but an ACK packet error is detected by the target. The target fails to get confirmation of the transfer, but the host has successfully received the data.

The host, recognizing that the transfer has completed successfully, requests the next data item in the transfer. However, the target believes that the transaction has failed and therefore sends the same data again.

This type of disagreement between the target and host must be handled through the use of the data toggle mechanism. See the section entitled “Data Toggle Errors” on page 175.

Bus Time-Out

The transmitter and receiver involved in a transaction must know how long they must wait for a response. For example, transmitters expect responses from target devices after sending token and data packets. Similarly, a target device expects a response from the host after it transmits data to the host. However, if the response is not returned within the specified bus turn-around time, an error is detected.

172

Chapter 8: Error Recovery

No response from a target is defined by the specification as the method of notifying the sender of a packet that was not received correctly. That is, if errors are detected within the packet being received, no response is sent as expected. Since no response is sent, the transmitter of the packet will detect a bus time-out, thereby recognizing that some error has occurred during the packet transfer.

The bus time-out defines the maximum number of cable segments supported downstream from the host. The delays associated with transferring data from the host to a downstream port include:

•Cable delay = 30ns maximum

•Hub delay = 40ns maximum

The total delay from the downstream port of the root hub to the downstream port of the first hub is a maximum value of 70ns. The worst case timing occurs when six cable segments are supported via a single downstream path as illustrated in Figure 8-2. The total round-trip delay between the host port and the upstream end of the device’s cable is 700ns. Additional delays occur as the signal propagates over the target device cable. The target then decodes the token packet, accesses the selected endpoint, and initiates the return packet back to the upstream end of the cable. This 7.5 bit time delay is specifically defined as the time from the end of packet (EOP to idle transition) seen on the upstream end of the functions cable until the SOP transition from the device is returned to the upstream end of the target cable.

Figure 8-2: Total Trip Delay

173