Cypress EX-USB FX3 Operating and maintenance manual

2 FX3 Programmers Manual, Doc. # 001-64707 Rev. *C
Copyrights
Copyrights
© Cypress Semiconductor Corporation, 2011-2012. The information contained herein is subject to change without notice.
Cypress Semiconductor Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a
Cypress product. Nor does it convey or imply any license under patent or other rights. Cypress products are not warranted
nor intended to be used for medical, life support, life saving, critical control or safety applications, unless pursuant to an
express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as critical components
in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user.
The inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such
use and in doing so indemnifies Cypress against all charges.
Any Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by
and subject to worldwide patent protection (United States and foreign), United States copyright laws and international treaty
provisions. Cypress hereby grants to licensee a personal, non-exclusive, non-transferable license to copy, use, modify, create
derivative works of, and compile the Cypress Source Code and derivative works for the sole purpose of creating custom soft-
ware and or firmware in support of licensee product to be used only in conjunction with a Cypress integrated circuit as speci-
fied in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source
Code except as specified above is prohibited without the express written permission of Cypress.
Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATE-
RIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE. Cypress reserves the right to make changes without further notice to the materials described
herein. Cypress does not assume any liability arising out of the application or use of any product or circuit described herein.
Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure
may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support sys-
tems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all
charges.
Use may be limited by and subject to the applicable Cypress software license agreement.
All trademarks or registered trademarks referenced herein are property of the respective corporations.

FX3 Programmers Manual, Doc. # 001-64707 Rev. *C 3
Contents
1. Introduction 9
1.1 Chapter Overview ......................................................................................................10
1.2 Document Revision History ......................................................................................10
1.3 Documentation Conventions .....................................................................................11
2. Introduction to USB 13
2.1 USB 2.0 System Basics.............................................................................................13
2.1.1 Host, Devices, and Hubs................................................................................13
2.1.2 Signaling Rates ..............................................................................................13
2.1.3 Layers of Communication Flow......................................................................13
2.1.4 Device Detection and Enumeration................................................................17
2.1.5 Power Distribution and Management .............................................................18
2.1.6 Device Classes ..............................................................................................18
2.2 USB 3.0: Differences and Enhancements over USB 2.0...........................................18
2.2.1 USB 3.0 Motivation ........................................................................................18
2.2.2 Protocol Layer ................................................................................................19
2.2.3 Link Layer.......................................................................................................21
2.2.4 Physical Layer................................................................................................21
2.2.5 Power Management .......................................................................................22
2.3 Reference Documents ...............................................................................................22
3. FX3 Overview 23
3.1 CPU ...........................................................................................................................23
3.2 Interconnect Fabric ....................................................................................................24
3.3 Memory......................................................................................................................25
3.4 Interrupts....................................................................................................................26
3.5 JTAG Debugger Interface..........................................................................................27
3.6 Peripherals.................................................................................................................28
3.6.1 I2S..................................................................................................................28
3.6.2 I2C..................................................................................................................30
3.6.3 UART .............................................................................................................31
3.6.4 SPI .................................................................................................................32
3.6.5 GPIO/Pins ......................................................................................................33
3.6.6 GPIF...............................................................................................................38
3.7 DMA Mechanism .......................................................................................................39
3.8 Memory Map and Registers.......................................................................................42
3.9 Reset, Booting, and Renum.......................................................................................43
3.10 Clocking .....................................................................................................................44
3.11 Power.........................................................................................................................46
3.11.1 Power Domains..............................................................................................46
3.11.2 Power Management .......................................................................................46

4 FX3 Programmers Manual, Doc. # 001-64707 Rev. *C
Contents
4. FX3 Software 49
4.1 System Overview.......................................................................................................49
4.2 FX3 Software Development Kit (SDK).......................................................................50
4.3 FX3 Firmware Stack ..................................................................................................50
4.3.1 Firmware Framework .....................................................................................50
4.3.2 Firmware API Library .....................................................................................50
4.3.3 FX3 Firmware Examples................................................................................51
4.4 FX3 Host Software ....................................................................................................51
4.4.1 Cypress Generic USB 3.0 Driver ...................................................................51
4.4.2 Convenience APIs .........................................................................................51
4.4.3 USB Control Center .......................................................................................51
4.4.4 Bulkloop .........................................................................................................51
4.4.5 Streamer ........................................................................................................51
4.5 FX3 Development Tools ............................................................................................ 52
4.5.1 Firmware Development Environment.............................................................52
4.5.2 GPIF II Designer ............................................................................................52
5. FX3 Firmware 53
5.1 Initialization................................................................................................................53
5.1.1 Device Boot ...................................................................................................55
5.1.2 FX3 Memory Organization .............................................................................55
5.1.3 FX3 Memory Map ..........................................................................................55
5.2 API Library.................................................................................................................59
5.2.1 USB Block......................................................................................................59
5.2.2 GPIF II Block.................................................................................................. 62
5.2.3 Serial Interfaces .............................................................................................64
5.2.4 DMA Engine...................................................................................................66
5.2.5 RTOS and OS primitives................................................................................71
5.2.6 Debug Support...............................................................................................72
5.2.7 Power Management.......................................................................................73
5.2.8 Low Level DMA..............................................................................................73
6. FX3 APIs 75
7. FX3 Application Examples 77
7.1 DMA examples .......................................................................................................... 77
7.1.1 cyfxbulklpauto – AUTO Channel....................................................................77
7.1.2 cyfxbulklpautosig – AUTO_SIGNAL Channel ................................................77
7.1.3 cyfxbulklpmanual – MANUAL Channel ..........................................................77
7.1.4 cyfxbulklpmaninout – MANUAL_IN and MANUAL_OUT Channels ...............78
7.1.5 cyfxbulklpautomanytoone – AUTO_MANY_TO_ONE Channel.....................78
7.1.6 cyfxbulklpmanmanytoone – MANUAL_MANY_TO_ONE Channel................78
7.1.7 cyfxbulklpautoonetomany – AUTO_ONE_TO_MANY Channel.....................78
7.1.8 cyfxbulklpmanonetomany – MANUAL_ONE_TO_MANY Channel................78
7.1.9 cyfxbulklpmulticast – MULTICAST Channel ..................................................78
7.1.10 cyfxbulklpman_addition – MANUAL Channel with Header / Footer Addition.78
7.1.11 cyfxbulklpman_removal – MANUAL Channel with Header / Footer Deletion 78
7.1.12 cyfxbulklplowlevel – Descriptor and Socket APIs ..........................................79
7.1.13 cyfxbulklpmandcache – MANUAL Channel with D-cache Enabled ...............79
7.1.14 cyfxbulklpmanual_rvds – Real View Tool Chain Project Configuration..........79
7.2 Basic Examples ......................................................................................................... 79
7.2.1 cyfxbulklpautoenum – USB Enumeration ......................................................79

FX3 Programmers Manual, Doc. # 001-64707 Rev. *C 5
Contents
7.2.2 cyfxbulksrcsink – Bulk Source and Sink.........................................................79
7.2.3 cyfxbulkstreams – Bulk Streams ....................................................................79
7.2.4 cyfxisolpauto – ISO loopback using AUTOchannel........................................79
7.2.5 cyfxisolpmaninout – ISO loopback using MANUAL_IN and MANUAL_OUT
Channels80
7.2.6 cyfxisosrcsink – ISO Source Sink ..................................................................80
7.2.7 cyfxflashprog – Boot Flash Programmer........................................................80
7.2.8 cyfxusbdebug – USB Debug Logging ............................................................80
7.2.9 cyfxbulklpauto_cpp – Bulkloop Back Example using C++ .............................80
7.2.10 cyfxusbhost – Mouse and MSC driver for FX3 USB Host..............................80
7.2.11 cyfxusbotg – FX3 as an OTG Device.............................................................80
7.2.12 cyfxbulklpotg – FX3 Connected to FX3 as OTG Device ................................80
7.3 Serial Interface Examples ..........................................................................................80
7.3.1 cyfxgpioapp – Simple GPIO ...........................................................................81
7.3.2 cyfxgpiocomplexapp – Complex GPIO ..........................................................81
7.3.3 cyfxuartlpregmode – UART in Register Mode................................................81
7.3.4 cyfxuartlpdmamode – UART in DMA Mode ...................................................81
7.3.5 cyfxusbi2cregmode – I2C in Register Mode ..................................................81
7.3.6 cyfxusbi2cdmamode – I2C in DMA Mode ......................................................81
7.3.7 cyfxusbspiregmode – SPI in Register Mode ..................................................81
7.3.8 cyfxusbspidmamode – SPI in DMA Mode......................................................81
7.3.9 cyfxusbspigpiomode – SPI using GPIO .........................................................81
7.3.10 cyfxusbi2sdmamode – I2S in DMA Mode ......................................................81
7.4 UVC examples...........................................................................................................82
7.4.1 cyfxuvcinmem – UVC from System Memory..................................................82
7.4.2 cyfxuvcinmem_bulk – Bulk Endpoint Based UVC from System Memory.......82
7.5 Slave FIFO Examples................................................................................................82
7.5.1 slfifoasync – Asynchronous Slave FIFO ........................................................82
7.5.2 slfifosync – Synchronous Slave FIFO ............................................................82
7.5.3 slfifoasync5bit: Async Slave Fifo 5 Bit Example.............................................82
7.5.4 slfifosync5bit: Sync Slave Fifo 5 Bit Example ................................................82
7.6 Mass Storage Example..............................................................................................82
7.7 USB Audio Class Example ........................................................................................83
7.8 Two Stage Booter Example (boot_fw) .......................................................................83
8. FX3 Application Structure 85
8.1 Application code structure .........................................................................................85
8.1.1 Initialization Code...........................................................................................85
8.1.2 Application Code ............................................................................................89
9. FX3 Serial Peripheral Register Access 99
9.1 Serial Peripheral (LPP) Registers ..............................................................................99
9.1.1 I2S Registers..................................................................................................99
9.1.2 I2C Registers ...............................................................................................105
9.1.3 UART Registers ...........................................................................................113
9.1.4 SPI Registers ...............................................................................................119
9.2 FX3 GPIO Register Interface...................................................................................125
9.2.1 Simple GPIO Registers ................................................................................125
9.2.2 GPIO_SIMPLE Register...............................................................................126
9.2.3 GPIO_INVALUE0 Register...........................................................................126
9.2.4 Gpio_invalue1 Register................................................................................127
9.2.5 GPIO_INTR0 Register .................................................................................127

6 FX3 Programmers Manual, Doc. # 001-64707 Rev. *C
Contents
9.2.6 GPIO_INTR1 Register .................................................................................127
9.3 Complex GPIO (PIN) Registers...............................................................................127
9.3.1 PIN_STATUS Register.................................................................................128
9.3.2 PIN_TIMER Register ...................................................................................130
9.3.3 PIN_PERIOD Register.................................................................................130
9.3.4 PIN_THRESHOLD Register ........................................................................130
9.3.5 GPIO_PIN_INTR..........................................................................................130
10. FX3 P-Port Register Access 131
10.1 Glossary ..................................................................................................................131
10.2 Externally Visible PP Registers ...............................................................................132
10.2.1 PP_ID Register ............................................................................................132
10.2.2 PP_INIT Register .........................................................................................133
10.2.3 PP_CONFIG Register..................................................................................134
10.2.4 PP_INTR_MASK Register ...........................................................................135
10.2.5 PP_DRQR5_MASK .....................................................................................135
10.2.6 PP_SOCK_MASK........................................................................................135
10.2.7 PP_ERROR .................................................................................................136
10.2.8 PP_DMA_XFER...........................................................................................136
10.2.9 PP_DMA_SIZE ............................................................................................137
10.2.10PP_WR_MAILBOX......................................................................................137
10.2.11PP_EVENT ..................................................................................................137
10.2.12PP_RD_MAILBOX.......................................................................................138
10.2.13PP_SOCK_STAT.........................................................................................138
10.3 INTR and DRQ signaling .........................................................................................138
10.4 Transferring Data into and out of Sockets ...............................................................139
10.4.1 Bursting and DMA_WMARK........................................................................139
10.4.3 Short Transfer – Partial Buffer .....................................................................141
10.4.4 Short Transfer – Zero Length Buffers ..........................................................142
10.4.5 Long Transfer – Integral Number of Buffers.................................................143
10.4.6 Long Transfer – Aborted by AP ...................................................................144
10.4.7 Long Transfer – Partial Last Buffer on Ingress ............................................145
10.4.8 Long Transfer – Partial Last Buffer on Egress.............................................145
10.4.9 Odd sized transfers......................................................................................146
10.4.10DMA transfer signalING on ADMUX interface.............................................146
11. FX3 Boot Image Format 149
11.1 Firmware Image Storage Format.............................................................................149
12. FX3 Development Tools 151
12.1 GNU Toolchain ........................................................................................................151
12.2 Eclipse IDE ..............................................................................................................151
12.2.1 JTAG Probe .................................................................................................151
12.2.2 Eclipse Projects ...........................................................................................151
12.2.3 Attaching Debugger to a Running Process..................................................179
12.2.4 Using Makefiles............................................................................................184
12.2.5 Eclipse IDE settings .....................................................................................184
13. FX3 Host Software 189
13.1 FX3 Host Software ..................................................................................................189
13.1.1 Cypress Generic Driver................................................................................189
13.1.2 CYAPI Programmer’s reference...................................................................189

8 FX3 Programmers Manual, Doc. # 001-64707 Rev. *C
Contents

FX3 Programmers Manual, Doc. # 001-64707 Rev. *C 9
1. Introduction
Cypress EZ-USB®FX3™ is the next-generation USB 3.0 peripheral controller providing highly
integrated and flexible features that enable developers to add USB 3.0 functionality to any system.
Figure 1-1. EZ USB FX3 System Diagram
EZ-USB FX3 has a fully configurable, parallel, general programmable interface called GPIF™ II,
which can connect to any processor, ASIC, DSP, image sensor, or FPGA. It has an integrated PHY
and controller along with a 32-bit microcontroller (ARM926EJ-S) for powerful data processing and
for building custom applications. It has an interport DMA architecture that enables data transfers of
greater than 400 Mbps.
The FX3 is a fully compliant USB 3.0 and USB 2.0 peripheral. An integrated USB 2.0 OTG controller
enables applications that need dual role usage scenarios. It has 512 KB of on-chip SRAM for code
and data. It supports serial peripherals such as UART, SPI, I2C, and I2S that enable communicating
to on board peripherals; for example, the I2C interface is typically connected to an EEPROM.
GPIF II is an enhanced version of the GPIF in FX2LP™, Cypress’s flagship USB 2.0 product. It
provides easy and glueless connectivity to popular industry interfaces such as asynchronous and
synchronous Slave FIFO, asynchronous SRAM, asynchronous and synchronous Address Data
Multiplexed interface, parallel ATA, and so on. The GPIF II controller on the FX3 device supports a
total of 256 states. It can be used to implement multiple disjointed state machines.
The FX3 comes with the easy-to-use EZ-USB tools providing a complete solution for fast application
development. The software development kit includes application examples to accelerate time to
market.

10 FX3 Programmers Manual, Doc. # 001-64707 Rev. *C
Introduction
The FX3 is fully compliant with USB 3.0 V1.0 Specification and is also backward compatible with
USB 2.0. It is also complaint with the Battery Charging Specification V1.1 and USB 2.0 OTG
Specification.
1.1 Chapter Overview
The following chapters describe in greater details each of the components of the Programmers
Manual.
Introduction to USB on page 13 presents an overview of the USB standard.
FX3 Overview on page 23 presents a hardware overview of the FX3 system.
FX3 Software on page 49 provides an overview of the SDK that is provided with the FX3.
FX3 Firmware on page 53 provides a brief description of each programmable firmware block. This
includes the system boot and initialization, USB, GPIF 2, serial interfaces, DMA, power
management, and debug infrastructure.
FX3 APIs on page 75 provides the description of the APIs for USB, GPIF2, serial interfaces, DMA,
RTOS, and debug.
FX3 Application Examples on page 77 presents code examples, which illustrate the API usage and
the firmware framework.
FX3 Application Structure on page 85 describes the FX3 application framework and usage model for
FX3 APIs.
FX3 Serial Peripheral Register Access chapter on page 99 describes the register based access from
an application processor when FX3 device is configured for PP mode slave operation.
FX3 Boot Image Format chapter on page 149 describes the FX3 image (img) format as required by
the FX3 boot-loader.
FX3 Development Tools on page 151 describes the available options for the firmware development
environment, including JTAG based debugging.
FX3 Host Software on page 189 describes the Cypress generic USB 3.0 WDF driver, the
convenience APIs, and the USB control center.
GPIF™ II Designer on page 191 provides a guide to the GPIF II Designer tool.
1.2 Document Revision History
Table 1-1. Revision History
Revision PDF
Creation Date Originof
Change Description of Change
** 05/10/2011 SHRS New user guide
*A 07/14/2011 SHRS FX3 Programmers Manual update for beta release.
*B 03/27/2012 SHRS FX3 Programmers Manual update for FX3 SDK 1.1 release.
*C 08/10/2012 SHRS FX3 Programmers Manual update for SDK 1.2 release.

FX3 Programmers Manual, Doc. # 001-64707 Rev. *C 11
Introduction
1.3 Documentation Conventions
Table 1-2. Document Conventions for Guides
Convention Usage
Courier New Displays file locations, user entered text, and source code:
C:\ ...cd\icc\
Italics Displays file names and reference documentation:
Read about the sourcefile.hex file in the PSoC Designer User Guide.
[Bracketed, Bold]Displays keyboard commands in procedures:
[Enter] or [Ctrl] [C]
File > Open Represents menu paths:
File > Open > New Project
Bold Displays commands, menu paths, and icon names in procedures:
Click the File icon and then click Open.
Times New Roman Displays an equation:
2 + 2 = 4
Text in gray boxes Describes Cautions or unique functionality of the product.

12 FX3 Programmers Manual, Doc. # 001-64707 Rev. *C
Introduction

FX3 Programmers Manual, Doc. # 001-64707 Rev. *C 13
2. Introduction to USB
The universal serial bus (USB) has gained wide acceptance as the connection method of choice for
PC peripherals. Equally successful in the Windows and Macintosh worlds, USB has delivered on its
promises of easy attachment, an end to configuration hassles, and true plug-and-play operation. The
USB is the most successful PC peripheral interconnect ever. In 2006 alone, over 2 billion USB
devices were shipped and there are over 6 billion USB products in the installed base today.
2.1 USB 2.0 System Basics
A USB system is an asynchronous serial communication 'host-centric' design, consisting of a single
host and a myriad of devices and downstream hubs connected in a tiered-star topology. The USB
2.0 Specification supports the low-speed, full-speed, and high-speed data rates. It employs a
half-duplex two-wire signaling featuring unidirectional data flow with negotiated directional bus
transitions.
2.1.1 Host, Devices, and Hubs
The USB system has one master: the host computer. Devices implement specific functions and
transfer data to and from the host (for example: mouse, keyboard, and thumb drives). The host owns
the bus and is responsible for detecting a device as well as initiating and managing transfers
between various devices. Hubs are devices that have one upstream port and multiple down stream
ports and connect multiple devices to the host creating a tiered topology. Associated with a host is
the host controller that manages the communication between the host and various devices. Every
host controller has a root hub associated with it. A maximum of 127 devices may be connected to a
host controller with not more than seven tiers (including root hubs). Because the host is always the
bus master, the USB direction OUT refers to the direction from the host to the device, and IN refers
to the device to host direction.
2.1.2 Signaling Rates
USB 2.0 supports following signaling rates:
■A low-speed rate of 1.5 Mbit/s is defined by USB 1.0.
■A full-speed rate of 12 Mbit/s is the basic USB data rate defined by USB 1.1. All USB hubs
support full speed.
■A high-speed (USB 2.0) rate of 480 Mbit/s introduced in 2001. All high-speed devices are
capable of falling back to full-speed operation if necessary; they are backward compatible.
2.1.3 Layers of Communication Flow
A layered communication model view is adopted to describe the USB system because of its
complexity and generic nature. The components that make up the layers are presented here.

14 FX3 Programmers Manual, Doc. # 001-64707 Rev. *C
Introduction to USB
2.1.3.1 Pipes, Endpoints
USB data transfer can occur between the host software and a logical entity on the device called an
endpoint through a logical channel called pipe. A USB device can have up to 32 active pipes, 16 for
data transfers to the host, and 16 from it. An interface is a collection of endpoints working together to
implement a specific function.
2.1.3.2 Descriptors
USB devices describe themselves to the host using a chain of information (bytes) known as
descriptors. Descriptors contain information such as the function the device implements, the
manufacturer of the device, number of endpoints, and class specific information. The first two bytes
of any descriptor specify the length and type of descriptor respectively.
All devices generally have the following descriptors.
■Device descriptors
■Configuration descriptors
■Interface descriptors
■Endpoint descriptors
■String descriptors
A device descriptor specifies the Product ID (PID) and Vendor ID (VID) of the device as well as the
USB revision that the device complies with. Among other information listed are the number of
configurations and the maximum packet size for endpoint 0. The host system loads looks at the VID
and PID to load the appropriate device drivers. A USB device can have only one device descriptor
associated with it.
The configuration descriptor contains information such as the device's remote wake up feature,
number of interfaces that can exist for the configuration, and the maximum power a particular
configuration uses. Only one configuration of a device can be active at any time.
Each function of the device has an interface descriptor associated with it. An interface descriptor
specifies the number of endpoints associated with that interface and other alternate settings.
Functions that fall under a predefined category are indicated using the interface class code and sub
class code fields. This enables the host to load standard device drivers associated with that function.
More than one interface can be active at any time.
The endpoint descriptor specifies the type of transfer, direction, polling interval, and maximum
packet size for each endpoint. Endpoint 0 is an exception; it does not have any descriptor and is
always configured to be a control endpoint.
2.1.3.3 Transfer Types
USB defines four transfer types through its pipes. These match the requirements of different data
types that need to be delivered over the bus.
Bulk data is 'bursty,' traveling in packets of 8, 16, 32, or 64 bytes at full speed or 512 bytes at high
speed. Bulk data has guaranteed accuracy, due to an automatic retry mechanism for erroneous
data. The host schedules bulk packets when there is available bus time. Bulk transfers are typically
used for printer, scanner, modem data, and storage devices. Bulk data has built-in flow control
provided by handshake packets.
Interrupt data is similar to bulk data; it can have packet sizes of 1 through 64 bytes at full-speed or up
to 1024 bytes at high-speed. Interrupt endpoints have an associated polling interval that ensures
they are polled (receive an IN token) by the host on a regular basis.

FX3 Programmers Manual, Doc. # 001-64707 Rev. *C 15
Introduction to USB
Isochronous data is time-critical and used to stream data similar to audio and video. An isochronous
packet may contain up to 1023 bytes at full-speed, or up to 1024 bytes at high-speed. Time of
delivery is the most important requirement for isochronous data. In every USB frame, a certain
amount of USB bandwidth is allocated to isochronous transfers. To lighten the overhead,
isochronous transfers have no handshake and no retries; error detection is limited to a 16-bit CRC.
Control transfers configure and send commands to a device. Because they are so important, they
employ the most extensive USB error checking. The host reserves a portion of each USB frame for
control transfers.
2.1.3.4 Protocol Layer
The function of the protocol layer is to understand the type of transfer, create the necessary packet
IDs and headers, packet long data and generate CRCs, and pass them on to the link layer. Protocol
level decisions similar to packet retry are also handled in this layer.
All communication over USB happen in the form of packets. Every USB packet, consist of a Packet
ID (PID). These PIDs may fall into one of the four different categories and are listed here.
The PIDs shown in bold are additions that happened in the USB 2.0 specification.
Figure 2-1. USB Packets
A regular pay load data transfer requires at least three packets: Token, Data, and Ack. Figure 2-1
illustrates a USB OUT transfer. Host traffic is shown in solid shading, while device traffic is shown
cross-hatched. Packet 1 is an OUT token, indicated by the OUT PID. The OUT token signifies that
data from the host is about to be transmitted over the bus. Packet 2 contains data, as indicated by
the DATA1 PID. Packet 3 is a hand-shake packet, sent by the device using the ACK (acknowledge)
PID to signify to the host that the device received the data error-free. Continuing with Figure 2-1, a
second transaction begins with another OUT token 4, followed by more data 5, this time using the
DATA0 PID. Finally, the device again indicates success by transmitting the ACK PID in a handshake
packet 6.
SETUP tokens are unique to CONTROL transfers. They preface eight bytes of data from which the
peripheral decodes host device requests. At full-speed, start of frame (SOF) tokens occur once per
millisecond. At high speed, each frame contains eight SOF tokens, each denoting a 125-µs
microframe.
Four handshake PIDs indicate the status of a USB transfer: ACK (Acknowledge) means 'success';
the data is received error-free. NAK (Negative Acknowledge) means 'busy, try again.' It is tempting to
assume that NAK means 'error,' but it does not; a USB device indicates an error by not responding.
PID Type PID Name
Tok en IN , O UT, S OF, SE TUP
Data DATA0, DATA1, DATA2, MDATA
Handshake ACK, NAK, STALL, NYET
Special PRE, ERR, SPLIT, PING

16 FX3 Programmers Manual, Doc. # 001-64707 Rev. *C
Introduction to USB
STALL means that something is wrong (probably as a result of miscommunication or lack of
cooperation between the host and device software). A device sends the STALL handshake to
indicate that it does not understand a device request, that something went wrong on the peripheral
end, or that the host tried to access a resource that was not there. It is similar to HALT, but better,
because USB provides a way to recover from a stall. NYET (Not Yet) has the same meaning as ACK
- the data was received error-free - but also indicates that the endpoint is not yet ready to receive
another OUT transfer. NYET PIDs occur only in high-speed mode. A PRE (Preamble) PID precedes
a low-speed (1.5 Mbps) USB transmission.
One notable feature of the USB 2.0 protocol is the data toggle mechanism. There are two DATA
PIDs (DATA0 and DATA1) in Figure 2-1. As mentioned previously, the ACK handshake is an
indication to the host that the peripheral received data with-out error (the CRC portion of the packet
is used to detect errors). However, the handshake packet can get garbled during transmission. To
detect this, each side (host and device) maintains a 'data toggle' bit, which is toggled between data
packet transfers. The state of this internal toggle bit is compared with the PID that arrives with the
data, either DATA0 or DATA1. When sending data, the host or device sends alternating DATA0-
DATA1 PIDs. By comparing the received Data PID with the state of its own internal toggle bit, the
receiver can detect a corrupted handshake packet.
The PING protocol was introduced in the USB 2.0 specification to avoid wasting bus bandwidth
under certain circumstances. When operating at full speed, every OUT transfer sends the OUT data,
even when the device is busy and cannot accept the data. Such unsuccessful repetitive bulk data
transfers resulted in significant wastage of bus bandwidth. Realizing that this could get worse at high
speed, this issue was remedied by using the new 'Ping' PID. The host first sends a short PING token
to an OUT endpoint, asking if there is room for OUT data in the peripheral device. Only when the
PING is answered by an ACK does the host send the OUT token and data.
The protocol for the interrupt, bulk, isochronous and control transfers are illustrated in the following
figures.
Figure 2-2. Two Bulk Transfers, IN and OUT
Figure 2-3. Interrupt Transfer
Figure 2-4. Isochronous Transfer

FX3 Programmers Manual, Doc. # 001-64707 Rev. *C 17
Introduction to USB
Figure 2-5. Control Transfer
2.1.3.5 Link/Physical Layer
The link layer performs additional tasks to increase the reliability of the data transfer. This includes
byte ordering, line level framing, and so on.
More commonly known as the electrical interface of USB 2.0, this layer consists of circuits to
serialize and de-serialize data, pre and post equalization circuits and circuits to drive and detect
differential signals on the D+ and D– lines. All error handling is done at the protocol layer and there
is no discernible low level link layer to manage errors.
2.1.4 Device Detection and Enumeration
One of the most important advantages of USB over other contemporary communication system is its
plug-and-play capability. A change in termination at the USB port indicates that a USB device is
connected.
When a USB device is first connected to a USB host, the host tries to learn about the device from its
descriptors; this process is called enumeration. The host goes through the following sign on
sequence
1. The host sends a Get Descriptor-Device request to address zero (all USB devices must respond
to address zero when first attached).
2. The device responds to the request by sending ID data back to the host to identify itself.
3. The host sends a Set Address request, which assigns a unique address to the just-attached
device so it may be distinguished from the other devices connected to the bus.
4. The host sends more Get Descriptor requests, asking for additional device information. From
this, it learns every-thing else about the device such as number of endpoints, power
requirements, required bus bandwidth, and what driver to load.
All high-speed devices begin the enumeration process in full-speed mode; devices switch to
high-speed operation only after the host and device have agreed to operate at high speed. The
high-speed negotiation process occurs during USB reset, via the 'Chirp' protocol.
Because the FX2 configuration is 'soft', a single chip can take on the identities of multiple distinct
USB devices. When first plugged into USB, the FX2 enumerates automatically and downloads
firmware and USB descriptor tables over the USB cable. A soft disconnect is triggered following
which, the FX2 enumerates again, this time as a device defined by the downloaded information. This
patented two-step process, called ReNumeration™, happens instantly when the device is plugged
in, with no hint that the initial download step had occurred.

18 FX3 Programmers Manual, Doc. # 001-64707 Rev. *C
Introduction to USB
2.1.5 Power Distribution and Management
Power management refers to the part of the USB Specification that spell out how power is allocated
to the devices connected downstream and how different communication layers operate to make best
use of the available bus power under different circumstances.
USB 2.0 supports both self and bus powered devices. Devices indicate this through their descriptors.
Devices, irrespective of their power requirements and capabilities are configured in their low power
state unless the software instructs the host to configure the device in its high power state. Low power
devices can draw up to 100 mA of current and high power devices can draw a maximum of 500 mA.
The USB host can 'suspend' a device to put it into a power-down mode. A 3 ms 'J' state (Differential
'1' indicated by D+ high D– low) on the USB bus triggers the host to issue a suspend request and
enter into a low power state. USB devices are required to enter a low power state in response to this
request.
When necessary, the device or the host issues a Resume. A Resume signal is initiated by driving a
'K' state on the USB bus, requesting that the host or device be taken out of its low power 'suspended'
mode. A USB device can only signal a resume if it has reported (through its Configuration
Descriptor) that it is 'remote wakeup capable', and only if the host has enabled remote wakeup from
that device.
This suspend-resume mechanism minimizes power consumed when activity on the USB bus is
absent
2.1.6 Device Classes
In an attempt to simplify the development of new devices, commonly used device functions were
identified and nominal drivers were developed to support these devices. The host uses the
information in the class code, subclass code, and protocol code of the device and interface
descriptors to identify if built-in drivers can be loaded to communicate with the device attached. The
human interface device (HID) class and mass storage class (MSC) are some of the commonly used
device classes.
The HID class refers to interactive devices such as mouse, keyboards, and joy sticks. This interface
use control and interrupt transfer types to transfer data because data transfer speeds are not critical.
Data is sent or received using HID reports. Either the device or the interface descriptor contains the
HID class code
The MSC class is primarily intended to transfer data to storage devices. This interface primarily uses
bulk transfer type to transfer data. At least two bulk endpoints for each direction is necessary. The
MSC class uses the SCSI transparent command set to read or write sectors of data on the disk
drive.
Details about other classes can be found at the Implementers forum website http://www.usb.org.
2.2 USB 3.0: Differences and Enhancements over USB 2.0
2.2.1 USB 3.0 Motivation
USB 3.0 is the next stage of USB technology. Its primary goal is to provide the same ease of use,
flexibility, and hot-plug functionality but at a much higher data rate. Another major goal of USB 3.0 is
power management. This is important for "Sync and Go" applications that need to trade off features
for battery life.
The USB 3.0 interface consists of a physical SuperSpeed bus in addition to the physical USB 2.0
bus. The USB 3.0 standard defines a dual simplex signaling mechanism at a rate of 5 Gbits/s.

FX3 Programmers Manual, Doc. # 001-64707 Rev. *C 19
Introduction to USB
Inspired by the PCI Express and the OSI 7-layer architecture, the USB 3.0 protocol is also
abstracted into different layers as illustrated in the following sections.
In this document, USB 3.0 implicitly refers to the SuperSpeed portion of USB 3.0.
Figure 2-6. USB Protocol Layers
2.2.2 Protocol Layer
USB 3.0 SuperSpeed inherits the data transfer types from its predecessor retaining the model of
pipes, endpoints and packets. Nonetheless, the type of packets used and some protocols associated
with the bulk, control, isochronous, and control transfers have undergone some changes and
enhancements. These are discussed in the sections to follow.
Link Management packets are sent between links to communicate link level issues such as link
configuration and status and hence travel predominantly between the link layers of the host and the
device. For example, U2 Inactivity Timeout LMP is used to define the timeout from the U1 state to
the U2 state. The structure of a LMP is shown here.
Figure 2-7. Link Management Packet Structure
Transaction packets reproduce the functionality provided by the Token and Handshake packets and
travel between the host and endpoints in the device. They do not carry any data but form the core of
the protocol.
For example, the ACK packet is used to acknowledge a packet received. The structure of a
transaction packet is shown in Figure 2-8.

20 FX3 Programmers Manual, Doc. # 001-64707 Rev. *C
Introduction to USB
Figure 2-8. ACK Transaction Packet
Data packets actually carry data. These are made up of two parts: a data header and the actual data.
The structure of a data packet is shown on the right.
Isochronous Time Stamp packets contain timestamps and are broadcast by the host to all active
devices. Devices use timestamps to synchronize with the host. These do not have any routing
information. The structure of an ITP is shown in Figure 2-10.
Figure 2-9. Example Data Packet
Figure 2-10. ITP Structure
OUT transfers are initiated by the host by sending a data packet on the downstream bus. The data
packet contains the device routing address and the endpoint number. If the transaction is not an
isochronous transaction, then, on receiving the data packet, the device launches an
acknowledgement packet, which also contains the next packet number in the sequence. This
process continues until all the packets are transmitted unless an endpoint responds with an error
during the transaction. In transfers are initiated by the host by sending an acknowledge packet to the
device containing the device, endpoint address and the number of packets that the host expects.
The device then starts sending the data packets to the host. The response from the host
acknowledges the previous transfer while initiating the next transfer from the device.
One important modification in the USB 3.0 specification is uni-casting in place of broadcasting.
Packets in USB 2.0 were broadcast to all devices. This necessitated every connected device to
decode the packet address to check if the packet was targeted at it. Devices had to wake up to any
USB activity regardless of its necessity in the transfer. This resulted in higher idle power. USB 3.0
packets (except ITP) are uni-casted to the target. Necessary routing information for hubs is built into
the packet.
Table of contents