Chapter 8: Error Recovery

Note that DATA1 is always used during the status stage of a control transfer. The previous illustration might leave the impression that if the last transaction of the data stage happened to use DATA1 that the status stage would use DATA0, which is not the case.

Babbling Devices

Bus failures can occur if a device on the bus fails to end its transaction (i.e., it continues to babble on and on). This type of endless babbling has the potential of deadlocking the entire bus, and therefore must be prevented. Babble is detected at the end of a frame, and is characterized by an upstream SOP followed by bus activity would continue past the end of the frame if not stopped. If an upstream packet has not ended by the end of the frame due to a babbling device, the babbling device must be isolated by disabling the hub port to which it attaches.

Loss of Activity (LOA)

Another form of potential bus failure is loss of activity, or LOA. LOA is characterized by a device starting a packet transfer, followed by a constant J or K state on the bus and no EOP. LOA, like babble, has the potential to deadlock the bus and must be prevented. Also, like a babble error, the LOA error is detected at the end of a frame by hubs.

Babble/LOA Detection and Recovery

Hubs are responsible for detecting and recovering from babble and LOA errors. These errors are characterized by expected conditions at the end of frame. The host discontinues transactions prior to the end of packet to ensure that no bus activity occurs by the end of frame. In a normal condition, the last transaction ends with an EOP followed by idle. An error condition exists if the hub repeater has not detected EOP by the end of frame.

Frame Timer

Hubs are responsible for tracking each frame and sampling bus activity near the end of each frame. A frame timer within each hub is synchronized by the SOF packets that are broadcast at the beginning of each frame. These timers must be

189

USB System Architecture

able to maintain synchronization in the absence of two consecutive SOF tokens.

Figure 8-10 illustrates two sample windows near the end of frame (EOF). If the hub detects bus activity (babble) or finds the bus is stuck in a non-idle state after EOF1, it must terminate upstream traffic and float the bus. All hubs in the upstream direction will detect the EOP. If, however, a hub fails to detect EOP at the EOF2 sample point, it must disable the port to which the offending device is attached. In this way, hubs assure that the bus will be in the idle state when the next frame begins.

Figure 8-10: Hub EOF Points

Host to Hub Skew

Timing skew exists between the host-generated frame and the hub frame timer. Sources of skew include the following:

•The hub may miss up to two consecutive SOFs and from the host for a maximum timing wander of ± 3 clocks.

•The host clock can be adjusted by up to one bit time per frame, resulting in a wander of 1+2+3=6 clocks. This adjustment is requested by a “master client” that wishes to adjust the clock so that it synchronizes to the client device’s sample clock. Note that this ability has been removed by the 2.0 specification.

This results in a maximum host-hub skew of ± 9 clocks.

To support the detection and recovery of babble and LOA, the second EOF point must be separated from the next SOF point. All hub EOF2 points must occur at least one bit time before the host issues SOF. If, due to skew problems, an EOP from downstream fails to reach a hub before it detects its EOF2 point, an inadvertent error will be detected by the hub.

190

Chapter 8: Error Recovery

Figure 8-11 illustrates the EOF1 and EOF2 ranges that relate to the latest EOP that can be issued by a hub. The specification defines the EOF1 point as occurring at 32 bit times before the next SOF. The earliest that a hub might start sending EOP is 9 bit times before the first EOF point, or at bit time 41, and at the latest at bit time 23. The EOP must complete at least 19 bit times before the next SOF, or 9 bit times prior to the median EOF2 point (10 bit times before SOF). EOF2 must occur no later than one bit time before SOF.

Figure 8-11: EOF Timing Ranges

SOF

Hub Repeater State Machine

Figure 8-12 illustrates the state machine for the hub’s repeater. Note that this figure is based on the state machine descriptions from the 2.0 USB specification. Babble detect functions only when downstream hubs are synchronized to the host frame timing (i.e., SOF packets). Following Reset, the repeater is in its Wait For SOP from Upstream (WFSOPFU). The first SOP is that of the SOF packet, which causes a transition to the Wait For EOP from Upstream (WFEOPFU). When the upstream EOP occurs the transition will be either back to WFSOPFU or on to WFSOP (from either direction). The transition is back to WFWOPFU occurs if the hub frame timer is not synchronized or locked (!Lock) to the SOF timing. When a lock is established the transition is to WFSOP.

The behavior of the hub near the end of frame is crucial for LOA and babble detection. The hub repeater is in its Wait For Start Of Packet (WFSOP) state during bus idle and when the hub is synchronized to the SOF packets (i.e., Lock is

191