Part 1
Part 2
Part 3
Part 4
Part 5
Part 6
Part 7

Part 3 - Data Flow

The following discussion on data flow covers full and low speed. High speed signalling will be covered in a later part.

USB is a Bus

Picture a setup of plugged-in hubs and devices such as that on the right. What we need to remember is that, at any point in time, only the host OR one device can be transmitting at a time.

When the host is transmitting a packet of data, it is sent to every device connected to an enabled port. It travels downwards via each hub in the chain which resynchronises the data transitions as it relays it. Only one device, the addressed one, actually accepts the data. (The others all receive it but the address is wrong for them.)

One device at a time is able to transmit to the host, in response to a direct request from the host. Each hub repeats any data it receives from a lower device in an upward only direction.

Downstream direction ports are only enabled once the device connected to them is addressed, except that one other port at a time can reset a device to address 0 and then set its address to a unique value.



At each end of the data link between host and device is a transceiver circuit. The transceivers are similar, differing mainly in the associated resistors.

A typical upstream end transceiver is shown to the right with high speed components omitted for clarity. By upstream, we mean the end nearer to the host. The upstream end has two 15K pull-down resistors.

Each line can be driven low individually, or a differential data signal can be applied. The maximum 'high' level is 3.3V.



The equivalent downstream end transceiver, as found in a device, is shown to the right.

When receiving, individual receivers on each line are able to detect single ended signals, so that the so-called Single Ended Zero (SE0) condition, where both lines are low, can be detected. There is also a differential receiver for reliable reception of data.


Not shown in these simplified drawings is the rise and fall time control on the differential transmitters. Low speed devices need longer rise and fall times, so a full speed / low speed hub must be able to switch between these rise and fall times.



Upstream End Transceiver
Downstream End Transceiver (Full Speed)

Speed Identification

At the device end of the link a 1.5 kohm resistor pulls one of the lines up to a 3.3V supply derived from VBUS.

This is on D- for a low speed device, and on D+ for a full speed device.

(A high speed device will initially present itself as a full speed device with the pull-up resistor on D+.)

The host can determine the required speed by observing which line is pulled high.


Line States

Given that there are just 2 data lines to use, it is surprising just how many different conditions are signaled using them:


When no device is plugged in, the host will see both data lines low, as its 15 kohm resistors are pulling each data line low.



When the device is plugged in to the host, the host will see either D+ or D- go to a '1' level, and will know that a device has been plugged in.

The '1' level will be on D- for a low speed device, and D+ for a full (or high) speed device.


The state of the data lines when the pulled up line is high, and the other line is low, is called the idle state. This is the state of the lines before and after a packet is sent.


J, K and SEO States

To make it easier to talk about the states of the data lines, some special terminology is used. The 'J State' is the same polarity as the idle state (the line with the pull-up resistor is high, and the other line is low), but is being driven to that state by either host or device.

The K state is just the opposite polarity to the J state.

The Single Ended Zero (SE0) is when both lines are being pulled low.

The J and K terms are used because for Full Speed and Low Speed links they are actually of opposite polarity.

Bus State
Differential '1'
D+ high, D- low
Differential '0'
D- high, D+ low
Single Ended Zero (SE0)
D+ and D- low
Single Ended One (SE1)
D+ and D- high
Data J State:
Differential '0'
Differential '1'
Data K State:
Differential '1'
Differential '0'
Idle State:

D- high, D+- low
D+ high, D- low
Resume State
Data K state
Start of Packet (SOP)
Data lines switch from idle to K state
End of Packet (EOP)
SE0 for 2 bit times followed by J state for 1 bit time
SE0 for >= 2us
Connect Idle for 2.5us
SE0 for >= 2.5 us
Bus States

This table has been simplified from the original in the USB specification. Please read the original table for complete information.

Single Ended One (SE1)

This is the illegal condition where both lines are high. It should never occur on a properly functioning link.



When the host wants to start communicating with a device it will start by applying a 'Reset' condition which sets the device to its default unconfigured state.

The Reset condition involves the host pulling down both data lines to low levels (SE0) for at least 10 ms. The device may recognise the reset condition after 2.5 us.

This 'Reset' should not be confused with a micro-controller power-on type reset. It is a USB protocol reset to ensure that the device USB signaling starts from a known state.


EOP signal

The End of Packet (EOP) is an SE0 state for 2 bit times, followed by a J state for 1 bit time.



One of the features of USB which is an essential part of today's emphasis of 'green' products is its ability to power down an unused device. It does this by suspending the device, which is achieved by not sending anything to the device for 3 ms.

Normally a SOF packet (at full speed) or a Keep Alive signal (at low speed) is sent by the host every 1 ms, and this is what keeps the device awake.

A suspended device may draw no more than 0.5 mA from Vbus.

A suspended device must recognise the resume signal, and also the reset signal.




If a device is configured for high power (up to 500 mA), and has its remote wakeup feature enabled, it is allowed to draw up to 2.5mA during suspend.



When the host wants to wake the device up after a suspend, it does so by reversing the polarity of the signal on the data lines for at least 20ms. The signal is completed with a low speed end of packet signal.

It is also possible for a device with its remote wakeup feature set, to initiate a resume itself. It must have been in the idle state for at least 5ms, and must apply the wakeup K condition for between 1 and 15 ms. The host takes over the driving of the resume signal within 1 ms.


Keep Alive Signal

This is represented by a Low speed EOP. It is sent at least once every millisecond on a low speed link, in order to keep the device from suspending.



The packet could be thought of as the smallest element of data transmission. Each packet conveys an integral number of bytes at the current transmission rate. Before and after the packet, the bus is in the idle state.


You need not be concerned with the detail of syncs, bit stuffing, and End Of Packet conditions, unless you are designing at the silicon level, as the Serial Interface Engine (SIE) will deal with the details for you. You should just be aware that the SIE can recognise the start and end of a packet, and that the packet contains a whole number of bytes.

In spite of this packets often expect fields of data to cross byte boundaries. The important rule to remember is that all usb fields are transmitted least significant bit first. So if, for example, a field is defined by 2 successive bytes, the first byte will be the least significant, and the second byte transmitted will be the most significant.


Serial Interface Engine (SIE)

The complexities and speed of the USB protocol are such that it is not practical to expect a general purpose micro-controller to be able to implement the protocol using an instruction-driven basis. Dedicated hardware is required to deal with the time-critical portions of the specification, and the circuitry grouping which performs this function is referred to as the Serial Interface Engine (SIE).


Data Fields are Transmitted Least Significant Bit First

The first time when you need to know this is when you are defining 'descriptors' in your firmware code. Many of these values are word sized and you need to add the bytes in the low byte, high byte order.

A packet starts with a sync pattern to allow the receiver bit clock to synchronise with the data. It is followed, by the data bytes of the packet, and concluded with an End of Packet (EOP) signal. The data is actually NRZI encoded, and in order to ensure sufficiently frequent transitions, a zero is inserted after 6 successive 1's (this is known as bit stuffing).  

A Single Packet

Before we continue, some definitions...


Each USB device has a number of endpoints. Each endpoint is a source or sink of data. A device can have up to 16 OUT and 16 IN endpoints.

OUT always means from host to device.

IN always means from device to host.

Endpoint 0 is a special case which is a combination of endpoint 0 OUT and endpoint 0 IN, and is used for controlling the device.


A logical data connection between the host and a particular endpoint, in which we ignore the lower level mechanisms for actually achieving the data transfers.


Simple transfers of data called 'Transactions' are built up using packets.


Packet Formats

The first byte in every packet is a Packet Identifier (PID) byte. This byte needs to be recognised quickly by the SIE and so is not included in any CRC checks. It therefore has its own validity check. The PID itself is 4 bits long, and the 4 bits are repeated in an complemented form.

lsb             msb

The PID is shown here in the order of transmission; lsb first.

Cyclic Redundancy Code (CRC)

A CRC is a value calculated from a number of data bytes to form a unique value which is transmitted along with the data bytes, and then used to validate the correct reception of the data.

USB uses two different CRCs, one 5 bits long (CRC5) and one 16 bits long (CRC16).

See the USB specification for details of the algorithms used.


There are 17 different PID values defined. This includes one reserved value, and one value which has been used twice with different meanings for two different situations.

Notice that the first 2 bits of a token which are transmitted, determine which of the 4 groups it falls into. This is why SOF is officially considered to be a token PID.



PID Type PID Name PID<3:0>*
Token OUT 0001b
IN 1001b
SOF 0101b
SETUP 1101b
Data DATA0 0011b
DATA1 1011b
DATA2 0111b
MDATA 1111b
Handshake ACK 0010b
NAK 1010b
STALL 1110b
NYET 0110b
Special PRE 1100b
ERR 1100b
SPLIT 1000b
PING 0100b
Reserved 0000b

* Bits are transmitted lsb first

There are four different packet formats based on which PID the packet starts with.    
Token Packet
8 bits
7 bits
4 bits
5 bits

Used for SETUP, OUT and IN packets. They are always the first packet in a transaction, identifying the targeted endpoint, and the purpose of the transaction.

The SOF packet is also defined as a Token packet, but has a slightly different format and purpose, which is described below.


The token packet contains two addressing elements:

Address (7 bits)

This device address can address up to 127 devices. Address 0 is reserved for a device which has not yet had its address set.

Endpoint number (4 bits)

There can be up to 16 possible endpoints in a device in each direction. The direction is implicit in the PID. OUT and SETUP PIDs will refer to the OUT endpoint, and an IN PID will refer to the IN endpoint.

Data Packet
8 bits
x 8 bits
16 bits


Used for DATA0, DATA1, DATA2 and MDATA packets. If a transaction has a data stage this is the packet format used.


DATA0 and DATA1 PIDs are used in Low and Full speed links as part of an error-checking system. When used, all data packets on a particular endpoint use an alternating DATA0 / DATA1 so that the endpoint knows if a received packet is the one it is expecting. If it is not it will still acknowledge (ACK) the packet as it is correctly received, but will then discard the data, assuming that it has been re-sent because the host missed seeing the ACK the first time it sent the data packet.

DATA2 and MDATA are only used for high speed links.

Handshake Packet
8 bits


Used for ACK, NAK, STALL and NYET packets. This is the packet format used in the status stage of a transaction, when required.


Receiver acknowledges receiving error free packet.


Receiving device cannot accept data or transmitting device cannot send data.


Endpoint is halted, or control pipe request is not supported.


No response yet from receiver (high speed only)

SOF Packet
Frame No.
8 bits
11 bits
5 bits


The Start of Frame packet is sent every 1 ms on full speed links. The frame is used as a time frame in which to schedule the data transfers which are required. For example, an isochronous endpoint will be assigned one transfer per frame.


On a low speed link, to preserve bandwidth, a Keep Alive signal is sent every millisecond, instead of a Start of Frame packet. In fact Keep Alives may be sent by a hub on a low speed link whenever the hub sees a full speed token packet.

At high speed the 1 ms frame is divided into 8 microframes of 125 us. A SOF is sent at the start of each of these 8 microframes, each having the same frame number, which then increments every 1 ms frame.


A successful transaction is a sequence of three packets which performs a simple but secure transfer of data.

For IN and OUT transactions used for isochronous transfers, there are only 2 packets; the handshake packet on the end is omitted. This is because error-checking is not required.

There are three types of transaction. In each of the illustrations below, the packets from the host are shaded, and the packets from the device are not.






OUT Transaction

A successful OUT transaction comprises two or three sequential packets. If it were being used in an Isochronous Transfer there would not be a handshake packet from the device.

On a low or full speed link, the PID shown as DATAx will be either a DATA0 or a DATA1. An alternating DATA0/DATA1 is used as a part of the error control protocol to (or from) a particular endpoint.

IN Transaction

A successful IN transaction comprises two or three sequential packets. If it were being used in an Isochronous Transfer there would not be a handshake packet from the host.

Here again, the DATAx is either a DATA0 or a DATA1.

SETUP Transaction

A successful SETUP transaction comprises three sequential packets. This is similar to an OUT transaction, but the data payload is exactly 8 bytes long, and the SETUP PID in the token packet informs the device that this is the first transaction in a Control Transfer (see below).

As will be seen below, the SETUP transaction always uses a DATA0 to start the data packet.

Data Flow Types

There are four different ways to transfer data on a USB bus. Each has its own purposes and characteristics. Each one is built up using one or more transaction type.

Data Flow Type Description
Control Transfer Mandatory using Endpoint 0 OUT and Endpoint 0 IN.
Bulk Transfer Error-free high volume throughput when bandwidth available.
Interrupt Transfer

Regular Opportunity for status updates, etc.
Low throughput

Isochronous Transfer

Guaranteed fixed bandwidth.
Not error-checked.

Bulk Transfers

Bulk transfers are designed to transfer large amounts of data with error-free delivery, but with no guarantee of bandwidth. The host will schedule bulk transfers after the other transfer types have been allocated.

If an OUT endpoint is defined as using Bulk transfers, then the host will transfer data to it using OUT transactions.

If an IN endpoint is defined as using Bulk transfers, then the host will transfer data from it using IN transactions.

The max packet size is 8, 16, 32 or 64 at full Speed and 512 for high speed. Bulk transfers are not allowed at low speed.

Use Bulk transfers when you have a lot of data to shift, as fast as possible, but where you would not have a large problem if there is a delay caused by insufficient bandwidth.


Example Bulk Transfer


The diagrams to the right illustrate the possible flow of events in the face of errors.

Error Control - IN

If the IN token packet is not recognised, the device will not respond at all. Otherwise, if it has data to send it will send it in a DATA0 or DATA1 packet, If it is not ready to send data it will send a NAK packet. If the endpoint is currently 'halted' then it will respond with a STALL packet.

In the case of DATA0/1 being sent, the host will acknowledge with an ACK, unless the data is not validly received, in which case it does not send an ACK. (Note: the host never sends NAK!)

Error Control - OUT

If the OUT token packet is not recognised, the device will not respond at all. It will then ignore the DATAx packet because it does not know that it has been addressed.

If the OUT token is recognised but the DATAx packet is not recognised, then the device will not respond.

If the data is received but the device can't accept it at this time, it will send a NAK, and if the endpoint is currently halted, it will send a STALL.


BULK Transfer Error Control Flow


Interrupt Transfers

Interrupt transfers have nothing to do with interrupts. The name is chosen because they are used for the sort of purpose where an interrupt would have been used in earlier connection types.

Interrupt transfers are regularly scheduled IN or OUT transactions, although the IN direction is the more common usage.

Typically the host will only fetch one packet, at an interval specified in the endpoint descriptor (see below). The host guarantees to perform the IN transaction at least that often, but it may actually do it more frequently.

Interrupt packets can have any size from 1 to 8 bytes at low speed, from 1 to 64 at full speed or up to 1024 bytes at high speed.

Use an interrupt transfer when you need to be regularly kept up to date of any changes of status in a device. Examples of their use are for a mouse or a keyboard.

Error control is very similar to that for bulk transfers.


Example Interrupt Transfer

Error Control Flow

Isochronous Transfers

Isochronous transfers have a guaranteed bandwidth, but error-free delivery is not guaranteed.

The main purpose of isochronous transfers is applications such as audio data transfer, where it is important to maintain the data flow, but not so important if some data gets missed or corrupted.

An isochronous transfer uses either an IN transaction or an OUT transaction depending on the type of endpoint. The special feature of these transactions is that there is no handshake packet at the end.

An isochronous packet may contain up to 1023 bytes at full speed, or up to 1024 at high speed. Isochronous transfers are not allowed at low speed.


Example Isochronous Transfer

Error Control Flow

Control Transfer

This is a bi-directional transfer which uses both an IN and an OUT endpoint. Each control transfer is made up of from 2 to several transactions.

It is divided into three stages.

The SETUP stage carries 8 bytes called the Setup packet. This defines the request, and specifies whether and how much data should be transferred in the DATA stage.

The DATA stage is optional. If present, it always starts with a transaction containing a DATA1. The type of transaction then alternates between DATA0 and DATA1 until all the required data has been transferred.

The STATUS stage is a transaction containing a zero-length DATA1 packet. If the DATA stage was IN then the STATUS stage is OUT, and vice versa.

Control transfers are used for initial configuration of the device by the host, using Endpoint 0 OUT and Endpoint 0 IN, which are reserved for this purpose. They may be used (on the same endpoints) after configuration as part of the device-specific control protocol, if required.

The max packet size for the data stage is 8 bytes at low speed, 8, 16, 32 or 64 at full Speed and 64 for high speed.


Example Control Read

Error Control Flow


Notice that it is not permitted for a device to respond to a SETUP with a NAK or a STALL.


(same as for bulk transfer)


(same as for bulk transfer)



We have examined 4 different types of data transfer, each of which uses different combinations of packets.

We have seen Control Transfers which every device uses to implement a Standard set of requests. And we have seen three other data transfer types, which a device might use depending on its purpose.


Coming up...

Next we will examine the standard set of requests which every USB device has to implement.

Copyright © 2006-2008 MQP Electronics Ltd
Packet-Master USB Bus Analysers and Generators from MQP Electronics
  • Radically cut development time
  • Intuitive graphical interface
  • Detailed timing information
  • Full analysis of all standard events
  • Results can be printed
  • Optional class analysis modules