Ch.

1: Introduction
At over two billion new installed units per year, USB is the most
successful personal-computer interface ever. Every recent PC has
USB ports that can connect to keyboards, mice, game controllers,
scanners, cameras, printers, drives, and more. USB is reliable, fast,
versatile, power conserving, inexpensive, and supported by major
operating systems. USB 3.0s new SuperSpeed bus means USB is
likely to continue to dominate as the interface of choice for an ever-
expanding selection of peripherals.

This chapter introduces USB, including its advantages and limits,

some history about the interface and recent enhancements to it, and
a look at whats involved in designing and programming a device with
a USB interface.

Lets start
The Universal Serial Bus (USB) is a standard for peripheral devices. It
began development in 1994 by a group of seven companies:
Compaq, DEC, IBM, Intel, Microsoft, NEC and Nortel. USB was
intended to make it fundamentally easier to connect external devices
to PCs by replacing the multitude of connectors at the back of PCs,
addressing the usability issues of existing interfaces, and simplifying
software configuration of all devices connected to USB, as well as
permitting greater bandwidths for external devices. The first silicon
for USB was made available by Intel in 1995.

A USB (Universal Serial Bus) system has an asymmetric design,

consisting of a host, a multitude of downstream USB ports, and
multiple peripheral devices connected in a tiered-star topology as
shown in figure 1-1. Additional USB hubs may be included in the
tiers, allowing branching into a tree structure with up to five tier
 levels. A USB host may have multiple host controllers and each host
controller may provide one or more USB ports. Up to 127 devices,
including hub devices if present, may be connected to a single host
controller.

USB devices are linked in series through hubs. There always exists
one hub known as the root hub, which is built into the host
controller. So-called sharing hubs, which allow multiple computers to
access the same peripheral device(s), also exist and work by
switching access between PCs, either automatically or manually.
Sharing hubs are popular in small-office environments. In network
terms, they converge rather than diverge branches.

A physical USB device may consist of several logical sub-devices that

are referred to as device functions. A single device may provide
several functions, for example, a webcam (video device function)
with a built-in microphone (audio device function). Such a device is
called a compound device in which each logical device is assigned a
distinctive address by the host and all logical devices are connected
to a built-in hub to which the physical USB wire is connected. A host
assigns one and only one device address to a function.

USB device communication is based on pipes (logical channels). A

pipe is a connection from the host controller to a logical entity, found
on a device, and named an endpoint. The term endpoint is
occasionally incorrectly used for referring to the pipe. However,
while an endpoint exists on the device permanently, a pipe is only
formed when the host makes a connection to the endpoint.
Therefore, when referring to the connection between a host and an
endpoint, the term pipe should be used. A USB device can have up to
32 active pipes: 16 into the host controller and 16 out of the host
controller. (for more information see ch.______)

USB is the best

From the users perspective, the benefits of USB are ease of use, fast
and reliable data transfers, low cost, and power conservation.
Table 1-1 compares USB with other interfaces.

Easy to use
Ease of use was a major design goal for USB, and the result is an
interface thats a pleasure to use for many reasons:

1. One interface for many devices.

2. Automatic configuration. When a user connects a USB device
to a PC, the operating system detects the device and loads the
appropriate software driver.
3. Easy to connect.
4. Convenient cables. USB connectors are small and compact
compared to connectors used by other interfaces such as RS-
232.
 5. Wireless options.
6. Hot pluggable. Users can connect and disconnect a USB
device whenever they want, whether or not the system and
device are powered, without damaging the PC or device.
7. No user settings. USB devices dont have user-selectable
settings such as port addresses and interrupt-request (IRQ)
lines, so users have no jumpers to set or configuration utilities
to run.

Evolution of USB
USB 1.0
The Universal Serial Bus Specification Revision 1.0 was
released in January 1996. USB capability first became available
on PCs with the release of Windows 95s OEM Service Release
2, available only to vendors installing Windows 95 on PCs they
sold. The USB support in these versions was limited and buggy,
and there werent many USB peripherals available, so use of
USB was limited in this era.

USB 1.1
The Universal Serial Bus Specification Revision 1.1 (September
1998) added one new transfer type (interrupt OUT).

USB 2.0
As USB gained in popularity and PCs became more powerful,
demand grew for a faster bus speed. Investigation showed that
a bus speed 40 faster than full speed could remain
backwards-compatible with the low- and full-speed interfaces.
April 2000 saw the release of the Universal Serial Bus
Specification Revision 2.0, which added high speed at 480
 Mbps. High speed made USB more attractive for peripherals
such as printers, disk drives, and video cameras. Windows
added support for USB 2.0 in Windows XP SP2. The USB 2.0
specification replaced USB 1.1.

Except for hubs, a USB 2.0 device can support low speed, full
speed, or high speed, and a high-speed-capable device can
support full speed when connected to a USB 1.x bus. USB 1.x
refers to USB 1.0 and 1.1.

A USB 2.0 hub must support all three USB 2.0 speeds. The
ability to communicate at any speed increases the complexity
of the hubs but conserves bus bandwidth and eliminates a
need to use different hubs for different speeds.

USB 3.0
The Universal Serial Bus 3.0 Specification Revision 1.0 was
released in November 2008, with the first USB 3.0 device-
controller hardware expected to follow about a year later.
Windows will likely support USB 3.0 sometime after the
release of Windows 7, the successor to Windows Vista.

USB 3.0 defines a new dual-bus architecture with two physical

buses that operate in parallel. USB 3.0 provides a pair of wires
for USB 2.0 traffic and additional wires to support the new
SuperSpeed bus at 5 Gbps. SuperSpeed offers a more than 10
increase over USB 2.0s high speed. Plus, unlike USB 2.0,
SuperSpeed has a pair of wires for each direction and can
transfer data in both directions at the same time. USB 3.0 also
increases the amount of bus current devices can draw and
defines protocols for more aggressive power saving and more
efficient transfers.
 USB On-The-Go
As USB became the interface of choice for all kinds of
peripherals, developers began to ask for a way for USB
peripherals to access other USB devices. For example, a user
might want to attach a printer to a camera or a keyboard to a
PDA. The On-The-Go (OTG) Supplement to the USB 2.0
Specification defines a limited-capability host function that
devices can implement to enable communicating with USB
peripherals.

Wireless USB
Developers who want to design devices with wireless
interfaces have several choices. The Wireless USB Promoter
Groups Wireless Universal Serial Bus Specification defines the
Certified Wireless USB (WUSB) interface for communicating at
up to 480 Mbps. Cypress Semiconductor's WirelessUSB
enables implementing wireless devices that function as low-
speed USB devices. Another option is to use an adapter that
converts between USB and a wireless interface such as Zigbee,
Bluetooth, or WiFi.

Mass Storage Basics

Introduction
A mass-storage device is electronic hardware that stores information
and supports a protocol for sending and retrieving the information
over a hardware interface. The information can be anything that can
be stored electronically: executable programs, source code,
 documents, images, spreadsheet numbers, database entries, data
logger output, configuration data, or other text or numeric data.
Mass-storage devices typically store information in files. A file system
defines how the files are organized in the storage media.

When to use mass storage device

Implementing a mass-storage function is a solution for systems that
need to read or write moderate to large amounts of data.

If the device has a Universal Serial Bus (USB) interface, any PC or

other USB host can access the storage media. Generic USB mass-
storage devices include the hard drives, flash drives, CD drives, and
DVD drives available from any computer-hardware store. These
devices have just one function: to provide storage space for the
systems they connect to.

Another type of USB mass-storage device (or storage device for

short) is the special-purpose device with storage capabilities. For
example, a camera can capture images and store the images in files.

Benefits
Adding storage-device capabilities to a system has several benefits:
1. With a USB device controller, a system can make the contents
of its storage media available to any PC or other USB host
computer.
2. File systems provide a standard way to store and access data.
A PC or other USB host can format the media in a USB storage
device to use the FAT16 or FAT32 file system.
3. Storage media is readily available. Flash-memory cards are
convenient and have enough capacity for many applications.

Requirements
Adding storage capabilities and a USB interface to an embedded
system requires hardware and firmware to support accessing the
storage media and communicating over the USB interface.

Devices
An embedded system that functions as a USB mass-storage
device requires the following hardware: (See figure 1-2)

A microcontroller or other CPU or intelligent hardware

to manage the embedded systems operation.
A USB device controller, which can be embedded in a
microcontroller chip or on a separate chip that
interfaces to a CPU or microcontroller.
A generic hard drive, flash drive, or other media that
interfaces to the devices CPU.

In a USB mass-storage device, the hardware or firmware must

perform the following functions:

Detect and respond to generic USB requests and other

events on the bus.
Detect and respond to USB mass-storage requests for
information or actions from the device.
Detect and respond to SCSI commands received in USB
transfers.

In addition, devices that create, read, or write to files and directories

on their own (not via a USB host) must implement a file system. A file
is a named collection of data. A directory structure provides an index
to the files. Popular file systems for embedded systems include
FAT16 and FAT32.
 Popular types of storage media
Two popular types of storage media for embedded systems are
flash-memory cards and hard drives. A flash-memory card contains
flash-memory chips to provide storage, a controller that manages
reading and writing to the memory, and an interface to the outside
world.

Common types of flash-memory cards include the MultimediaCard

(MMC), Secure Digital (SD) Card, and CompactFlash (CF) card.

A hard drive contains a hard disk that provides storage, drive

components to perform functions such as spinning the disk and
positioning the heads, a drive controller, and an interface to the
outside world. An embedded system that accesses flash-memory
cards or hard drives must have a microcontroller or other CPU or
intelligent hardware to manage communications with the cards or
drives.

Embedded Hosts
An embedded system that functions as a USB host for flash or hard
drives requires the following hardware: (See figure 1-3)
 A microcontroller or other CPU or intelligent hardware to
manage the embedded systems operation.
A USB host controller, which can be embedded in a
microcontroller chip or on a separate chip that interfaces to
the CPU, microcontroller, or other intelligent hardware.
A generic hard drive, flash drive, or other media connected to
a USB port on the host.

The hardware or firmware in an embedded USB mass-storage host

must provide the following functions:

Issue USB requests and initiate other events on the bus to

identify attached devices and manage traffic and power on the
bus.
Issue USB mass-storage requests that ask for status
information or specify actions for the device to perform.
Issue SCSI commands in USB transfers.
Support a file system to access files in the media.
Ch.2 First step toward the USB System
Many mass-storage devices store files that PCs or other computers
must access. To make files available to any PC or other USB host, a device
can use either of these approaches:

Include a USB device controller and support for USBs mass-

storage class. The files can be stored in any media. To access
the files from a USB host, attach the device to a USB port on
the host.
Include a USB host controller and a mass-storage driver. The
device can then store files on the same USB drives that PCs and
other USB hosts can access. To access the files from another
USB host, remove the drive from the device and attach the
drive to the other host.

The user looks at the USB system as host, hub and device:
Hosts and Devices
Every USB communication is between a host and a device. The host is
in charge of the bus. Devices communicate only when requested to
do so by the host.

Hosts
A USB host is a computer that contains USB host-controller hardware,
a root hub with one or more USB ports, and program code to manage
communications and events on the bus.

The host-controller hardware formats data for transmitting on the

bus and converts received data to a format that host software can
understand. The host controller also performs functions related to
managing communications on the bus.

The root hub has one or more connectors for attaching devices.

Program code in a USB device is typically firmware stored in non-

volatile memory

A USB host can be a desktop or notebook computer, a handheld, or

any embedded system that contains host-controller hardware and
software. To communicate with mass-storage devices, the host must
have a driver that supports the protocols defined for USBs mass-
storage class. The hardware that implements the low-level USB
protocols in the device controller is called the Serial Interface Engine
(SIE).

A USB device can connect to a hosts root hub or to an external hub.

The device can have a standard USB series-B or mini-B receptacle, a
vendor-specific connector, or a permanently attached USB cable. The
upstream (toward the host) end of the devices cable has a series-A
plug that attaches to a host or hub or a mini-A plug that attaches to
an On-The-Go device. Figure 2-1 shows the different plug types.
Host Responsibilities
1-Detect Devices: On power-up, hubs make the host aware of all
attached USB devices. In a process called enumeration, the host
assigns an address and requests a series of data structures called
descriptors from each device.

2-Provide Power: The host provides power to all devices on power-

up or attachment and works with the devices to conserve power
when possible. Some devices draw all of the power they need from
the bus, while others have their own power supplies to supplement
or replace the bus power.

3-Manage Traffic on the Bus: The host manages the flow of data on
the bus. Multiple peripherals may want to transfer data at the same
time. The host controller divides the available time into segments
 called frames (on a full-speed host) or microframes (on a high-speed
host).

4-Handle Error Checking: When transmitting data, the host adds

error checking bits. When receiving data, the host uses received
error-checking bits to detect errors.

Device Responsibilities
In many ways, a devices responsibilities mirror the hosts, but
devices also have unique duties and a USB device has these
responsibilities:

1-Detect the Bus Voltage: A device must be able to detect voltage on

the buss power-supply line and on detecting the voltage, switch in a
pull-up resistor to announce the devices presence to the host.

2-Manage Power: In normal operation, a device must limit the bus

current consumed to either 100 mA or a higher amount, up to 500
mA, approved by the host during enumeration. While in the Suspend
state, the device must monitor the bus and exit the Suspend state
when bus activity resumes.

3-Respond to Standard Requests: On power-up or on attachment to

a powered host, a device must respond to standard requests sent by
the host during enumeration. The host may also send requests any
time after enumeration completes.

4-Handle Error Checking: When transmitting data, the device adds

error-checking bits. When receiving data, the device uses received
error-checking bits to detect errors.

All of the above tasks support the hosts & devices main job, which is
to exchange data.
OTG On-The-Go
An On-The-Go (OTG) device is a special kind of USB device that can
function as a limited-capability host or as a device. An On-The-Go
device has a mini-AB receptacle that can accept a mini-A plug or a
mini-B plug. An example of a USB On-The-Go device is a camera that
can function as a mass-storage device that stores images that PCs can
access via USB and as a host that sends images to a USB printer.

Bus speed
The bus speeds describe the rate that information travels on the bus.
In addition to data, the bus must carry status, control, and error-
checking signals. Plus, all peripherals must share the bus. So the data
throughput for a device is always less than the bit rate on the bus.
This table shows the differences between bus speeds:

Bus speed Speed (megabits/sec.)

High speed 480
Full speed 12
Low speed 1.5

A USB mass-storage device must support full speed, high speed, or

both. USB hosts in recent PCs support all three speeds. An On-The-Go
host or an embedded host with mass-storage support can support
full speed, high speed, or both.

In theory, on an otherwise idle bus, a full-speed device can transfer

just over 1.2 megabytes/sec., and a high-speed device can transfer
more than 53 megabytes/sec. Some full-speed hosts can achieve the
maximum speed or close to it. At this writing, some high-speed hosts
can transfer close to 40 megabytes/sec.
 The actual rate of data transfer varies depending on:

The efficiency of the hosts and devices programming.

How busy the bus is.
Hardware capabilities of the host and drive.

Device Endpoints
Each USB logical device is composed of a collection of independent
endpoints. Each logical device has a unique address assigned by the
system at device attachment time. Each endpoint on a device is given
at design time a unique device-determined identifier called the
endpoint number. Each endpoint has a device-determined direction
of data flow (IN/OUT). A device can have up to 30 additional
endpoint addresses. Each of these endpoint addresses has a number
(1 to 15) and direction (IN or OUT).The combination of the device
address, endpoint number, and direction allows each endpoint to be
uniquely referenced. Each endpoint is a simplex connection that
supports data flow in one direction: either input (from device to
host) or output (from host to device).Endpoints other than those
with endpoint number zero are in an unknown state before being
configured and may not be accessed by the host before being
configured.

An endpoint describes itself by:

1. Bus access frequency/latency requirement.
2. Bandwidth requirement.
3. Endpoint number.
4. Error handling behavior requirements.
5. Maximum packet size that the endpoint is capable of sending or
receiving.
6. The transfer type for the endpoint.
7. The direction in which data is transferred between the endpoint
and the host.
Endpoint Zero
Every device must have endpoint zero, which is the default control
pipe used for control transfers and to initialize the device. Endpoint
zero is bidirectional. After the device received the bus reset, the
endpoint zero is then available.

Note that: The high-speed device may or may not be able to support
its intended functionality when operating at full speed.

Pipes
Pipes represent the ability to move data between software on the
host via a memory buffer and an endpoint on a device. The USB does
not interpret the content of data it delivers through a pipe. Even
though a message pipe requires that data be structured according to
USB definitions, the content of the data is not interpreted by the
USB.

Pipes have the following associated with them:

1. A claim on USB bus access and bandwidth usage.

2. A transfer type.
3. The associated endpoints characteristics, such as directionality
and maximum data payload sizes.

The default control pipe is used to send control information between

host and device, configure device. The Default Control Pipe can also
be used by device-specific software after the device is configured.
Software systems control the default control pipe and any other
software can use this pipe through the software system. A software
client normally requests data transfers via I/O Request Packets (IRPs)
to a pipe and then either waits or is notified when they are
completed.
Software client is notified that an IRP has completed when the bus
transactions associated with it have completed either successfully or
due to errors. If there are no IRPs pending or in progress for a pipe,
the pipe is idle and the Host Controller will take no action with regard
to the pipe. The endpoint for such a pipe will not see any bus
transactions directed to it. The only time bus activity is present for a
pipe is when IRPs are pending for that pipe. An IRP may require
multiple data payloads to move the client data over the bus. The data
payloads for such a multiple data payload IRP are expected to be of
the maximum packet size until the last data payload that contains the
remainder of the overall IRP.

For such an IRP, short packets on input that do not completely fill an
IRP data buffer can have one of two possible meanings, depending
upon the expectations of a client:

1. A client can expect a variable-sized amount of data in an IRP. In

this case, a short packet that does not fill an IRP data buffer can
be used simply as an in-band delimiter to indicate end of unit of
data .The IRP should be retired without error and the Host
Controller should advance to the next IRP.
2. A client can expect a specific-sized amount of data. In this case, a
short packet that does not fill an IRP data buffer is an indication of
an error. The IRP should be retired, the pipe should be stalled, and
any pending IRPs associated with the pipe should also be retired.

Because the Host Controller must behave differently in the two cases
and cannot know on its own which way to behave for a given IRP; it is
possible to indicate per IRP which behavior the client desires. There
are two mutually exclusive pipe communication modes:
1. Stream: Data moving through a pipe has no USB-defined
structure.
2. Message: Data moving through a pipe has some USB-defined
structure.
Stream pipes
Stream pipes deliver data in data packet portion of bus transactions
with no USB-required structure on the data content. Stream pipes
are always unidirectional in their communication flow. A stream pipe
to a device is bound to a single device endpoint number in the
appropriate direction. The device endpoint number for the opposite
direction can be used for some other stream pipe to the device.
Stream pipes support bulk, isochronous, and interrupt transfer types.

Message pipes
Message pipes interact with the endpoint in a different manner than
stream pipes:
1. A request is sent to the USB device from the host.
2. This request is followed by data transfer(s) in the appropriate
direction.
3. A Status stage follows at some later time.

In order to accommodate the request/data/status paradigm,

message pipes impose a structure on the communication flow that
allows commands to be reliably identified. Message pipes allow
communication flow in both directions. The Default Control Pipe is
always a message pipe. Message pipes serve one request at a time,
so any other requests are queued. If there is an error in one IRP, it
will be aborted and also all the queued IRPs and then, the client
software will be informed about the error. The USB does not allow a
message pipe to be associated with different endpoint numbers for
each direction. Message pipes support the control transfer type.

Transfer Types
One reason why USB is suitable for a wide range of devices is its
support for four types of data transfers:
Control transfer. Bulk transfers.
Interrupt transfer. Isochronous transfer.
 Note that:
Mass-storage devices rarely use interrupt transfers except for some
full-speed floppy drives. Mass-storage devices dont use isochronous
transfers.

Control transfer
Control transfers enable the host to learn about a device, set a
devices address, and select configurations and other settings.
Control transfers can also send vendor-specific requests that transfer
data for any purpose. Control transfers always use the default
control pipe and it is a message pipe. All USB devices must support
control transfers.

A control transfer has two or three stages. In the Setup stage, the
host sends a request. In the Data stage, the host or device sends
data. Some requests dont have a Data stage. In the Status stage, the
receiver of data in the Data stage returns status information. If there
is no Data stage, the device returns the status information.

Control Transfer Packet Size Constraints

The allowable maximum control transfer data payload sizes for full-
speed devices are 8, 16, 32, or 64 bytes. All Host Controllers are
required to have support for 8-, 16-, 32-, and 64-bytes maximum
data payload sizes for full-speed control endpoints. The USB does not
require that data payloads transmitted be exactly the maximum size,
if a data payload is less than the maximum, it does not need to be
padded to the maximum size. This maximum applies to the data
payloads of the Data packets following a Setup.
A Setup packet is always eight bytes. The size specified is for the data
field of the packet not including other information that is required by
the protocol. A control pipe (including the Default Control Pipe)
always uses its wMaxPacketSize value in Device Descriptor for data
 payloads. Device always send at least the first 8 bytes of the device
descriptor so, if the host reads these 8 bytes, it will know what is the
maximum size needed in the control pipe. When the device sends
more data than maximum size, the payload will need to be
transferred over more than data packet then, all packets are at
maximum size and the last one is less than maximum size.

The Data stage of a control transfer from an endpoint to the host is

complete when the endpoint does one of the following:
1. Has transferred exactly the amount of data specified during
the Setup stage.
2. Transfers a packet with a payload size less than
wMaxPacketSize or transfers a zero-length packet.

When a Data stage is complete, the Host Controller advances to the

Status stage.
The Host Controller does not advance to the Status stage when the
Data stage is complete, the endpoint halts the pipe.
If a larger-than-expected data payload is received from the endpoint,
the IRP for the control transfer will be aborted/retired.

Control Transfer Bus Access Constraints

If control transfers (low/full) consumes less than 10% of the frame
time and remaining time used by bulk transfers. If there are control
transfers pending for multiple endpoints, control transfers for the
different endpoints are selected according to a fair access policy that
is Host Controller implementation-dependent. A transaction of a
control transfer that is frequently being retried should not be
expected to consume an unfair share of the bus time. The USB
System Software can vary the rate of control transfers to a particular
endpoint.

The bus frequency and frame timing limit the maximum number of
successful control transfers within a frame for any USB system:
 1. For full speed buses, the number of successful control
transfers per frame is limited to less than 29 full-speed eight-
byte data payloads.
2. For low-speed buses, the number of successful control
transfers per frame is limited to less than 4 low speed eight-
byte data payloads.
Tables 2-1 &2-2 show low speed and full speed control transfer
limits.

Control Transfer Data Sequences

1. A setup transaction will be sent to describe the control access that
the device should perform.
2. The setup transaction will be followed by a data transaction that will
carry information about the bus access.
3. Status transaction will be sent from the endpoint to host to complete
the control transfer and inform with transfer status.
4. After the Status transaction for a control transfer is completed, the
host can advance to the next control transfer for the endpoint.

If endpoint returned busy status and the host wanted to send data or
status transaction, the host will retry sending at different time. If the a
setup transaction was sent to endpoint before completing a previous
initiated control transaction, the current control transaction will be
aborted and the endpoint will serve the new control transaction. If an
error occurred, a halt condition will be initiated. The halt condition will
be removed by accepting the next setup PID. For the Default Control
Pipe, a device reset will ultimately be required to clear the halt or error
condition if the next Setup PID is not accepted. USB protocol provides
good error detection and recovery during control transfers. A
transmitter can determine that its corresponding receiver has
successfully accepted a transmitted packet by information returned in a
handshake. Setup packets may be retransmitted due to a transmission
error however, Setup packets cannot indicate that a packet is an original
or a retried transmission.
Bulk Transfers
Bulk transfers used to transfer relatively large amount of data over variable
time. Requesting a pipe with bulk transfer type provides the requester with
the following:

1. Access to the USB on a bandwidth-available basis

2. Retry of transfers, in the case of occasional delivery failure due to
errors on the bus
3. Guaranteed delivery of data but no guarantee of bandwidth or
latency
Bulk transfers occur only on a bandwidth-available basis. For a USB
with large amounts of free bandwidth, bulk transfers may happen
relatively quickly; for a USB with little bandwidth available, bulk
transfers may trickle out over a relatively long period of time.
Bulk transfers always uses stream pipes, if it needs bidirectional
communication, it will use two endpoints.

Table 2-3 shows full speed Bulk transaction limits.

Transactions
Each transfer consists of one or more transactions. Each transaction
contains a token packet, a data packet, and a handshake packet.
(The handshake packet isnt present in isochronous transfers.) Each
packet begins with a packet ID (PID). The function of the PID varies
with the packet type.

The token packet contains the device address and the endpoint
number the transaction is directed to. The token packets PID
identifies the packet as one of these types: SETUP (first packet in a
control transfer), OUT (other host-to-device packet), IN (device-to-
host packet), or SOF (start-of-frame marker). See fig. 2-2

The data packet contains any data the host or device is sending in
the transaction. For control transfers, the transfer stage and the
request determine who sends the data. For other transfers, the
endpoints direction determines who sends the data. The PID
contains the data-toggle value, as explained below. See fig. 2-3

The handshake packet is sent by the receiver of the data packet. The
PID contains a code to indicate whether the data was received
without error. A code of ACK means success, NAK means busy and
STALL means either that the device doesnt support a received
request in a control transfer or that the endpoints Halt feature is set.
High-speed bulk OUT endpoints can also return a NYET handshake
code, which means that the endpoint accepted the data in the
current transaction but isnt yet ready for more data. See fig. 2-4
The Data Toggle
The data toggle is a data-sequencing value that guards against lost or
duplicated data.
Each endpoint maintains its own data-toggle value, which alternates
between DATA0 and DATA1. Devices typically store the value in a
register bit. When the host configures a device on power up or
attachment, the host and device each set their data toggles to
DATA0. On detecting an incoming data packet, the host or device
compares the state of its data toggle with the data toggle in the
received data packet. If the values match, the data packets receiver
toggles its value for the next transaction and returns an ACK. On
receiving the ACK, the data packets sender toggles its value for the
next transaction. The next received packet should contain a data
toggle of DATA1, and again the receiver toggles its bit and returns an
ACK. In additional transactions the data toggle continues to alternate
between DATA0 and DATA1. An exception is control transfers, where
the Status stage always uses DATA1.
If the receiver is busy and returns a NAK, or if the receiver detects
corrupted data and returns no response, the sender doesnt toggle
its bit and tries again with the same data and data toggle.