An21xx TRM
An21xx TRM
An21xx TRM
Integrated Circuit
Technical Reference
The information in this document is subject to
change without notice and should not be
construed as a commitment by Cypress
Semiconductor Corporation. While reasonable
precautions have been taken, Cypress
Semiconductor Corporation assumes no
responsibility for any errors that may appear in
this document.
Technical Reference
Documentation of the EZ-USB controller. Includes details about the CPU,
memory, input/output, ReNumeration™, bulk transfers, endpoint zero, iso-
chronous transfers, interrupts, resets, power management, registers, AC/
DC parameters, and packages.
Appendices
Documentation for the 8051 enhanced core. Includes an introduction, an
architectural overview, and a hardware description.
Registers
EZ-USB register maps.
Technical Support:
Phone: (858) 613-7929
E-mail: usbapps@cypress.com
Website:
www.cypress.com
EZ-USB
Technical Reference Manual
Version 1.9
May 2000
EZ-USB
Technical Reference Manual
Table of Contents
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
1 Introducing EZ-USB ......................................................................1-1
1.1 Introduction ............................................................................................. 1-1
1.2 EZ-USB Block Diagrams ....................................................................... 1-2
1.3 The USB Specification ........................................................................... 1-3
1.4 Tokens and PIDs ..................................................................................... 1-4
1.5 Host is Master ......................................................................................... 1-5
1.5.1 Receiving Data from the Host .................................................. 1-6
1.5.2 Sending Data to the Host ......................................................... 1-6
1.6 USB Direction ......................................................................................... 1-6
1.7 Frame ...................................................................................................... 1-6
1.7.1 Bulk Transfers .......................................................................... 1-7
1.7.2 Interrupt Transfers ................................................................... 1-7
1.8 EZ-USB Transfer Types ......................................................................... 1-7
1.8.1 Isochronous Transfers ............................................................. 1-8
1.8.2 Control Transfers ..................................................................... 1-8
1.9 Enumeration ............................................................................................ 1-9
1.10 The USB Core ....................................................................................... 1-10
1.11 EZ-USB Microprocessor ...................................................................... 1-11
1.12 ReNumeration‘ ...................................................................................... 1-12
1.13 EZ-USB Endpoints ............................................................................... 1-12
1.13.1 EZ-USB Bulk Endpoints ......................................................... 1-13
1.13.2 EZ-USB Control Endpoint Zero ............................................ 1-13
1.13.3 EZ-USB Interrupt Endpoints ................................................. 1-14
1.13.4 EZ-USB Isochronous Endpoints ............................................ 1-14
1.14 Fast Transfer Modes ............................................................................. 1-14
1.15 Interrupts ............................................................................................... 1-15
Figure 1-1. AN2131S (44 pin) Simplified Block Diagram .................................................. 1-2
Figure 1-2. AN2131Q (80 pin) Simplified Block Diagram .................................................. 1-3
Figure 1-3. USB Packets ...................................................................................................... 1-4
Figure 1-4. Two Bulk Transfers, IN and OUT ..................................................................... 1-7
Figure 1-5. An Interrupt Transfer ......................................................................................... 1-7
Figure 1-6. An Isochronous Transfer ................................................................................... 1-8
Figure 1-7. A Control Transfer ............................................................................................. 1-8
Figure 1-8. What the SIE Does ........................................................................................... 1-10
Figure 1-9. 80-pin PQFP Package (AN2131Q) .................................................................. 1-18
Figure 1-10. 44-pin PQFP Package with Port B (AN2121S, AN2122S, and AN2131S) .... 1-19
Figure 1-11. 44-pin Package with Data Bus (AN2125S, AN2126S, AN2135S, and
AN2136) .......................................................................................................... 1-20
Figure 1-12. 48-pin TQFP Package (AN2122T) .................................................................. 1-21
Figure 1-13. 48-pin TQFP Package (AN2126T) .................................................................. 1-22
Figure 2-1. 8051 Registers .................................................................................................... 2-3
Figure 3-1. EZ-USB 8-KB Memory Map - Addresses are in Hexadecimal ......................... 3-1
Figure 3-2. EZ-USB 4-KB Memory Map - Addresses are in Hexadecimal ......................... 3-1
Figure 3-3. Unused Bulk Endpoint Buffers (Shaded) Used as Data Memory ..................... 3-3
Figure 3-4. EZ-USB Memory Map with EA=0 .................................................................... 3-4
Figure 3-5. EZ-USB Memory Map with EA=1 .................................................................... 3-6
Figure 3-6. 8-KB ROM, 2-KB RAM Version ...................................................................... 3-7
Figure 3-7. 32-KB ROM, 4-KB RAM Version .................................................................... 3-8
Figure 4-1. EZ-USB Input/Output Pin ................................................................................. 4-2
Figure 4-2. Alternate Function is an OUTPUT .................................................................... 4-4
Figure 4-3. Alternate Function is an INPUT ........................................................................ 4-4
Figure 4-4. Registers Associated with PORTS A, B, and C ................................................ 4-5
Figure 4-5. General I2C Transfer ......................................................................................... 4-6
Figure 4-6. General FC Transfer .......................................................................................... 4-7
Figure 4-7. FC Registers ....................................................................................................... 4-8
Figure 5-1. USB Control and Status Register ..................................................................... 5-11
Figure 5-2. Disconnect Pin Logic ....................................................................................... 5-12
Figure 5-3. Typical Disconnect Circuit (DISCOE=1) ........................................................ 5-12
Figure 6-1. Two BULK Transfers, IN and OUT .................................................................. 6-1
Figure 6-2. Registers Associated with Bulk Endpoints ........................................................ 6-3
Figure 6-3. Anatomy of a Bulk IN Transfer ......................................................................... 6-4
Figure 6-4. Anatomy of a Bulk OUT Transfer ..................................................................... 6-7
Figure 6-5. Bulk Endpoint Toggle Control ........................................................................ 6-11
Figure 6-6. Example Code for a Simple (Polled) BULK Transfer ..................................... 6-14
Figure 6-7. Interrupt Jump Table ........................................................................................ 6-18
Figure 6-8. INT2 Interrupt Vector ...................................................................................... 6-19
1.1 Introduction
• A USB device can be plugged in anytime, even when the PC is turned on.
• When the PC detects that a USB device has been plugged in, it automatically inter-
rogates the device to learn its capabilities and requirements. From this informa-
tion, the PC automatically loads the device’s driver into the operating system.
When the device is unplugged, the operating system automatically logs it off and
unloads its driver.
• USB devices do not use DIP switches, jumpers, or configuration programs. There
is never an IRQ, DMA, MEMORY, or IO conflict with a USB device.
USB is defined in the Universal Serial Bus Specification Version 1.1 (http://usb.org), a
268-page document that describes all aspects of a USB device in elaborate detail. This
EZ-USB Technical Reference Manual describes the EZ-USB chip along with USB topics
that should provide help in understanding the Specification.
• The EZ-USB family provides a soft (RAM-based) solution that allows unlimited
configuration and upgrades.
• The EZ-USB family delivers full USB throughput. Designs that use EZ-USB are
not limited by number of endpoints, buffer sizes, or transfer speeds.
• The EZ-USB family does much of the USB housekeeping in the EZ-USB core,
simplifying code and accelerating the USB learning curve.
+5V
EZ-USB
The Cypress Semiconductor EZ-USB chip packs the intelligence required by a USB
peripheral interface into a compact integrated circuit. As Figure 1-1 illustrates, an inte-
grated USB transceiver connects to the USB bus pins D+ and D-. A Serial Interface
Engine (SIE) decodes and encodes the serial data and performs error correction, bit stuff-
ing, and other signaling-level details required by USB, and ultimately transfers data bytes
to and from the USB interface.
The internal microprocessor is enhanced 8051 with fast execution time and added fea-
tures. It uses internal RAM for program and data storage, making the EZ-USB family a
soft solution. The USB host downloads 8051 program code and device personality into
RAM over the USB bus, and then the EZ-USB chip re-connects as the custom device as
defined by the loaded code.
The EZ-USB family uses an enhanced SIE/USB interface (called the “USB Core”) which
has the intelligence to function as a full USB device even before the 8051. The enhanced
core simplifies 8051 code by implementing much of the USB protocol itself.
EZ-USB chips operate at 3.3V. This simplifies the design of bus-powered USB devices,
since the 5V power available in the USB connector (which the USB specification allows
to be as low as 4.4V) can drive a 3.3V regulator to deliver clean isolated power to the EZ-
USB chip.
EZ-USB
Figure 1-2 illustrates the An2131Q, an 80-pin version of the EZ-USB family. In addition
to the 24 IO pins, it contains a 16-bit address bus and an 8-bit data bus for external mem-
ory expansion.
A special fast transfer mode moves data directly between external logic and internal USB
FIFOs. The fast transfer mode, along with abundant endpoint resources, allows the EZ-
USB family to support transfer bandwidths beyond the maximum required by the Univer-
sal Serial Bus Specification Version 1.1.
The Universal Serial Bus Specification Version 1.1 is available on the Internet at http://
usb.org. Published in January 1998, the specification is the work of a founding commit-
tee of seven industry heavyweights: Compaq, DEC, IBM, Intel, Microsoft, NEC, and
Northern Telecom. This impressive list of implementers secures USB as the low to
medium speed PC connection method of the future.
A glance at the USB Specification makes it immediately apparent that USB is not nearly
as simple as the customary serial or parallel port. The specification uses new terms like
“endpoint,” isochronous,” and “enumeration,” and finds new uses for old terms like “con-
figuration,” “interface,” and “interrupt.” Woven into the USB fabric is a software abstrac-
tion model that deals with things such as “pipes.” The specification also contains detail
about the connector types and wire colors.
In this manual, you will read statements like, “When the host sends an IN token...” or “The
device responds with an ACK.” What do these terms mean? A USB transaction consists
of data packets identified by special codes called Packet IDs or PIDs. A PID signifies
what kind of packet is being transmitted. There are four PID types, as shown in Table 1-1.
D C D C
A E C A E C
O A R A O A R A
D N R Payload D N R Payload
U T C C U T C C
D D C Data D D C Data
T A 1 K T A 1 K
R P 5 R P 5
1 6 0 6
Token Packet Data Packet H/S Pkt Token Packet Data Packet H/S Pkt
1 2 3 4 5 6
Figure 1-3 illustrates a USB transfer. Packet j 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 !k contains data, as indicated by the DATA1 PID. Packet l is a handshake
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 1-3, a second transaction begins with another OUT token m, fol-
lowed by more data n, this time using the DATA0 PID. Finally, the device again indicates
success by transmitting the ACK PID in a handshake packet o.
Why two DATA PIDs, DATA0 and DATA1? It’s because the USB architects took error
correction very seriously. As mentioned previously, the ACK handshake is a signal to the
host that the peripheral received data without error (the CRC portion of the packet is used
to detect errors). But what if a handshake packet itself is garbled in 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
SETUP tokens are unique to CONTROL transfers. They preface eight bytes of data from
which the peripheral decodes host Device Requests.
• NAK means “busy, try again.” It’s tempting to assume that NAK means “error,”
but it doesn’t. A USB device indicates an error by not responding.
• STALL means that something unforeseen went wrong (probably as a result of mis-
communication or lack of cooperation between the software and firmware writers).
A device sends the STALL handshake to indicate that it doesn’t understand a
device request, that something went wrong on the peripheral end, or that the host
tried to access a resource that isn’t there. It’s like “halt,” but better, because USB
provides a way to recover from a stall.
A PRE (Preamble) PID precedes a low-speed (1.5 Mbps) USB transmission. The EZ-
USB family supports high-speed (12 Mbps) USB transfers only, so it ignores PRE packets
and the subsequent low-speed transfer.
This is a fundamental USB concept. There is exactly one master in a USB system: the
host computer. USB devices respond to host requests. USB devices cannot send informa-
tion between themselves, as they could if USB were a peer-to-peer topology.
Actually, there is one case where a USB device can initiate signaling without prompting
from the host. After being put into a low-power suspend mode by the host, a device can
signal a remote wakeup. But that’s the only way to “yank the host’s chain.” Everything
else happens because the host makes device requests and the device responds to them.
There’s an excellent reason for this host-centric model. The USB architects were keenly
mindful of cost, and the best way to make low-cost peripherals is to put most of the smarts
A USB device never spontaneously sends data to the host. Nevertheless, in the EZ-USB
chip, there’s nothing to stop the 8051 from loading data for the host into an endpoint
buffer (Section 1.13, "EZ-USB Endpoints") and arming it for transfer. But the data will sit
in the buffer until the host sends an IN token to that particular endpoint. If the host never
sends the IN token, the data sits there indefinitely.
Once you accept that the host is the bus master, it’s easy to remember USB direction: OUT
means from the host to the device, and IN means from the device to the host. EZ-USB
nomenclature uses this naming convention. For example, an endpoint that sends data to
the host is an IN endpoint. This can be confusing at first, because the 8051 sends data by
loading an IN endpoint buffer, but keeping in mind that an 8051 out is IN to the host, it
makes sense.
1.7 Frame
The USB host provides a time base to all USB devices by transmitting a SOF (Start Of
Frame) packet every millisecond. The SOF packet includes an incrementing, 11-bit frame
count. The 8051 can read this frame count from two EZ-USB registers. SOF-time has
significance for isochronous endpoints; it’s the time that the ping-ponging buffers switch
places. The EZ-USB core provides the 8051 with an SOF interrupt request for servicing
isochronous endpoint data.
USB defines four transfer types. These match the requirements of different data types
delivered over the bus. (Section 1.13, "EZ-USB Endpoints" explains how the EZ-USB
family supports the four transfer types.)
D C D C
A E C A E C
A R A O A R A
I D N R Payload D N R Payload
T C C U T C C
N D D C Data D D C Data
A 1 K T A 1 K
R P 5 R P 5
1 6 0 6
Token Packet Data Packet H/S Pkt Token Packet Data Packet H/S Pkt
Bulk data is bursty, traveling in packets of 8, 16, 32, or 64 bytes. Bulk data has guaranteed
accuracy, due to an automatic re-try mechanism for erroneous data. The host schedules
bulk packets when there is available bus time. Bulk transfers are typically used for printer,
scanner, or modem data. Bulk data has built-in flow control provided by handshake pack-
ets.
D C
A E C
A R A
I D N R Payload
T C C
N D D C Data
A 1 K
R P 5
1 6
Token Packet Data Packet H/S Pkt
Interrupt data is like bulk data, but exists only for IN endpoints in the “Universal Serial
Bus Specification Version 1.1.” Interrupt data can have packet sizes of 1-64 bytes. Inter-
rupt endpoints have an associated polling interval that ensures that they will be pinged
(will receive an IN token) by the host on a regular basis.
D C
A E C
A R
I D N R Payload
T C
N D D C Data
A 1
R P 5
0 6
Token Packet Data Packet
Isochronous data is time-critical and used for streaming data like audio and video. 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 (ACK/NAK/STALL), and no retries.
Error detection is limited to a 16-bit CRC. Isochronous transfers do not use the data tog-
gle mechanism; isochronous data uses only the DATA0 PID.
S D C
A E C
E A 8 bytes R A
T
D N R
T Setup C C SETUP
D D C
U
R P 5
A Data 1 K Stage
P 0 6
Token Packet Data Packet H/S Pkt
D C
A E C
I D N R
A
Payload
R A DATA
T C C
N D D C
A
Data
1 K
Stage
R P 5
1 6 (optional)
Token Packet Data Packet H/S Pkt
D C
A E C
O A R A
U
D N R
T C C STATUS
D D C
T
R P 5
A 1 K Stage
1 6
Token Packet Data Pkt H/S Pkt
Control transfers are used to configure and send commands to a device. Being mission
critical, they employ the most extensive error checking USB offers. Control transfers are
delivered on a best effort basis by the host (best effort is defined by a six-step process in
the Universal Serial Bus Specification Version 1.1, “Section 5.5.4”). The host reserves a
part of each USB frame time for Control transfers.
1.9 Enumeration
Your computer is ON. You plug in a USB device, and the Windows cursor switches to
an hourglass, and then back to a cursor. And magically, your device is connected and its
Windows driver is loaded! Anyone who has installed a sound card into a PC and had to
configure countless jumpers, drivers, and IO/Interrupt/DMA settings knows that a USB
connection can be like a miracle. We’ve all heard about Plug and Play, but USB delivers
the real thing.
How does all this happen automatically? Inside every USB device is a table of ‘descrip-
tors’ that are the sum total of the device’s requirements and capabilities. When you plug
into USB, the host goes through a ‘sign-on’ sequence:
2. The device dutifully responds to this request by sending ID data back to the host
telling what it is.
3. The host sends the device a “Set_Address” request, which gives it a unique address
to distinguish it from the other devices connected to the bus.
4. The host sends more “Get_Descriptor” requests, asking more device information.
from this, it learns everything else about the device, like how many endpoints the
device has, its power requirements, what bus bandwidth it requires, and what
driver to load.
D C D C
A E C A E C
O A R A O A R A
D N R Payload D N R Payload
U T C C U T C C
D D C Data D D C Data
T A 1 K T A 1 K
R P 5 R P 5
1 6 0 6
Token Packet Data Packet H/S Pkt Token Packet Data Packet H/S Pkt
Payload
Data
D+ Serial
Interface Payload
Data
D- Engine
(SIE)
A
C
K
USB
Tranceiver
Every USB device has a Serial Interface Engine (SIE). The SIE connects to the USB data
lines D+ and D-, and delivers bytes to and from the USB device. Figure 1-8 illustrates a
USB bulk transfer, with time moving from left to right. The SIE decodes the packet PIDs,
performs error checking on the data using the transmitted CRC bits, and delivers payload
data to the USB device. If the SIE encounters an error in the data, it automatically indi-
cates no response instead of supplying a handshake PID. This instructs the host to re-
transmit the data at a later time.
Bulk transfers such as the one illustrated in Figure 1-8 are asynchronous, meaning that
they include a flow control mechanism using ACK and NAK handshake PIDs. The SIE
indicates busy to the host by sending a NAK handshake packet. When the peripheral
device has successfully transferred the data, it commands the SIE to send an ACK hand-
shake packet, indicating success.
To send data to the host, the SIE accepts bytes and control signals from the USB device,
formats it for USB transfer, and sends it over the two-wire USB. Because the USB uses a
self-clocking data format (NRZI), the SIE also inserts bits at appropriate places in the bit
stream to guarantee a certain number of transitions in the serial data. This is called “bit
stuffing,” and is transparently handled by the SIE.
The EZ-USB family can connect as a USB device and download code into internal RAM,
all while its internal 8051 is held in RESET. This is done by an enhanced SIE, which does
all of the work shown in Figure 1-8, and more. It contains additional logic to perform a
full enumeration, using an internal table of descriptors. It also responds to a vendor spe-
cific “Firmware Download” device request to load its internal RAM. An added bonus is
that the added SIE functionality is also made available to the 8051. This saves 8051 code
and processing time.
Throughout this manual, the SIE and its enhancements are referred to as the “USB Core.”
The EZ-USB microprocessor is an enhanced 8051 core. Use of an 8051 compatible pro-
cessor makes extensive software support tools immediately available to the EZ-USB
designer. This enhanced 8051 core, described in Chapter 2, "EZ-USB CPU" and Appen-
dices A-C, has the following features:
• Two UARTs.
• Three counter-timers.
• 24-MHz clock.
• Standard 8051 instruction set—if you know the 8051, you know EZ-USB
The enhanced 8051 core uses on-chip RAM as program and data memory, giving EZ-USB
its soft feature. Chapter 3, "EZ-USB Memory" describes the various memory options.
The EZ-USB 8051 has two duties. First, it participates in the protocol defined in the Uni-
versal Serial Bus Specification Version 1.1, “Chapter 9, USB Device Framework.”
Thanks to EZ-USB enhancements to the SIE and USB interface, the 8051 firmware asso-
ciated with USB overhead is simplified, leaving code space and bandwidth available for
the 8051’s primary duty, to help implement your device. On the device side, abundant
input/output resources are available, including IO ports, UARTs, and an I2C bus master
controller. These resources are described in Chapter 4, "EZ-USB Input/Output."
1.12 ReNumeration
Because it is soft, the EZ-USB chip can take on the identities of multiple distinct USB
devices. The first device downloads your 8051 firmware and USB descriptor tables over
the USB cable when the peripheral device is plugged in. Once downloaded, another
device comes on as a totally different USB peripheral as defined by the downloaded infor-
mation. This two-step process, called ReNumeration, happens instantly when the
device is plugged in, with no hint that the initial load step has occurred.
The Universal Serial Bus Specification Version 1.1 defines an endpoint as a source or sink
of data. Since USB is a serial bus, a device endpoint is actually a FIFO which sequentially
empties/fills with USB bytes. The host selects a device endpoint by sending a 4-bit
address and one direction bit. Therefore, USB can uniquely address 32 endpoints, IN0
through IN15 and OUT0 through OUT15.
From the EZ-USB point of view, an endpoint is a buffer full of bytes received or to be
transmitted over the bus. The 8051 reads endpoint data from an OUT buffer, and writes
endpoint data for transmission over USB to an IN buffer.
Four USB endpoint types are defined as: Bulk, Control, Interrupt, and Isochronous.
Bulk endpoints are unidirectional—one endpoint address per direction. Therefore end-
point 2-IN is addressed differently than endpoint 2-OUT. Bulk endpoints use maximum
packet sizes (and therefore buffer sizes) of 8, 16, 32, or 64 bytes. EZ-USB provides four-
teen bulk endpoints, divided into seven IN endpoints (endpoint 1-IN through 7-IN), and
seven OUT endpoints (endpoint 1-OUT through 7-OUT). Each of the fourteen endpoints
has a 64-byte buffer.
Bulk data is available to the 8051 in RAM form, or as FIFO data using a special EZ-USB
Autopointer (Chapter 6, "EZ-USB Bulk Transfers").
Control endpoints transfer mission-critical control information to and from the USB
device. The Universal Serial Bus Specification Version 1.1 requires every USB device to
have a default CONTROL endpoint, endpoint zero. Device enumeration, the process that
the host initiates when the device is first plugged in, is conducted over endpoint zero. The
host sends all USB requests over endpoint zero.
• SETUP
• HANDSHAKE
Eight bytes of data in the SETUP portion of the CONTROL transfer have special USB
significance, as defined in the Universal Serial Bus Specification Version 1.1, “Chapter
9.” A USB device must respond properly to the requests described in this chapter to pass
USB compliance testing (usually referred to as the USB “Chapter Nine Test”).
Endpoint zero is the only CONTROL endpoint in the EZ-USB chip. The 8051 responds to
device requests issued by the host over endpoint zero. The EZ-USB core is significantly
enhanced to simplify the 8051 code required to service these requests. Chapter 7, "EZ-
USB Endpoint Zero" provides a detailed roadmap for writing USB Chapter 9 compliant
8051 code.
Interrupt endpoints are almost identical to bulk endpoints. Fourteen EZ-USB endpoints
(EP1-EP7, IN, and OUT) may be used as interrupt endpoints. Interrupt endpoints have
maximum packet sizes up to 64, and contain a “polling interval” byte in their descriptor to
tell the host how often to service them. The 8051 transfers data over interrupt endpoints in
exactly the same way as for bulk endpoints. Interrupt endpoints are described in Chapter
6, "EZ-USB Bulk Transfers."
Isochronous endpoints deliver high bandwidth, time critical data over USB. Isochronous
endpoints are used to stream data to devices such as audio DACs, and from devices such
as cameras and scanners. Time of delivery is the most critical requirement, and isochro-
nous endpoints are tailored to this requirement. Once a device has been granted an isoch-
ronous bandwidth slot by the host, it is guaranteed to be able to send or receive its data
every frame.
The following versions of the EZ-USB have a fast transfer mode: AN2125SC,
AN2126SC, AN2135SC, AN2136SC, and AN2131QC, that is, those versions that have a
data bus (see Table 1-2). The fast transfer mode minimizes the transfer time from EZ-USB
core also supplies external FIFO read and write strobes to synchronize the transfers.
Using the fast transfer mode, the 8051 transfers a byte of data between an internal FIFO
and the external bus using a single 8051 MOVX instruction, which takes two cycles or
333 ns. Both Isochronous and Bulk endpoints can use this fast transfer mode.
The EZ-USB enhanced 8051 adds seven interrupt sources to the standard 8051 interrupt
system. Three of the added interrupts are used internally, and the others are available on
device pins. INT2 is used for all USB interrupts. INT3 is used by the I2C interface. A
third interrupt is used for remote wakeup indication.
The EZ-USB core automatically supplies jump vectors (Autovectors) for its USB inter-
rupts to save the 8051 from having to test bits to determine the source of the interrupt.
Each BULK/CONTROL/INTERRUPT endpoint has its own vector, so when an endpoint
requires service, the proper interrupt service routine is automatically invoked. The 8051
services all isochronous endpoints in response to a SOF (Start Of Frame) interrupt request.
Chapter 9, "EZ-USB Interrupts" describes the EZ-USB interrupt system.
• Power-On-Reset (POR)
• 8051 reset
• USB Disconnect/Re-connect
The functions of the various EZ-USB resets are described in Chapter 10, "EZ-USB
Resets."
A USB peripheral may be put into a low power state when the host signals a suspend oper-
ation. The Universal Serial Bus Specification Version 1.1 states that a bus powered device
cannot draw more than 500 uA of current from the Vcc wire while in suspend. The EZ-
USB chip contains logic to turn off its internal oscillator and enter a sleep state. A special
interrupt, triggered by a wakeup pin or wakeup signaling on the USB bus, starts the oscil-
lator and interrupts the 8051 to resume operation.
The EZ-USB family is available in various pinouts to serve different system requirements
and costs. Table 1-2 shows the feature set for each member of the EZ-USB Series 2100
Family.
This section summarizes the features of the AN2122 and AN2126 packages. These fea-
tures are not available in the other packages of the EZ-USB family.
Bulk Endpoints
The AN2122 and AN2126 have a reduced set of thirteen bulk endpoints (see Section 6.1,
"Introduction").
Interrupts
The AN2122 and AN2126 contain two interrupts not present in the other AN21xx family
members.
• An IBN (In-Bulk NAK) interrupt request activates when an IN packet is NAKd by
the SIE because the 8051 has not loaded the buffer (and byte count register) for an
IN endpoint. This is useful for applications that need to know when the host is
pinging an IN endpoint (see Section 9.13, "In Bulk NAK Interrupt - (AN2122/
AN2126 only)").
• An I2C interrupt source is added to the I2C interrupt (INT3), indicating that trans-
mission of a STOP bit is complete (see Section 9.14, "I2C STOP Complete Inter-
rupt - (AN2122/AN2126 only)").
1.19 Revision ID
The Revision ID for each part is shown in Table 1.2. The revision value is reported in the
internal DID (Device ID), which is the value read by the host during enumeration if no
EEPROM is connected to the I2C bus. This value also appears in the CPUCS register bits.
Figures 1-9 through 1-13 are pin descriptions by package type. Table 1-3 describes the
pins by pin function.
PB5/INT5#
PB7/T2out
PB2/RxD1
PB1/T2EX
PB3/TxD1
PB6/INT6
PB4/INT4
PC7/RD#
PB0/T2
BKPT
GND
GND
GND
VCC
VCC
SDA
D7
D6
D5
D4
D3
D2
D1
D0
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41
SCL 65 40 PC6/WR#
WAKEUP# 66 39 PC5/T1
NC 67 38 PC4/T0
PA0/T0out 68 37 A15
PA1/T1out 69 36 A14
PA2/OE# 70 35 A13
PA3/CS#
GND
71
72
80 PQFP 34
33
A12
PC3/INT1#
PA4/FWR# PC2/INT0#
PA5/FRD#
73
74
14 x 20 mm 32
31 PC1/TxD0
PA6/RXD0out 75 30 PC0/RxD0
PA7/RXD1out 76 29 A11
USBD- 77 28 A10
GND 78 27 A9
USBD+ 79 26 A8
PSEN# 80 25 RESET
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
VCC
AVCC
VCC
CLK24
A0
A1
A2
A3
A4
A5
A6
A7
EA
AGND
XIN
XOUT
GND
GND
GND
GND
GND
GND
GND
DISCON#
WAKEUP#
PA5/FRD#
DISCON#
USBD+
USBD-
GND
GND
VCC
SDA
SCL
44 43 42 41 40 39 38 37 36 35 34
GND 1 33 VCC
CLK24 2 32 BKPT
GND 3 31 PB7/T2OUT
GND 4 30 PB6/INT6
GND 5 29 PB5/INT5#
GND 6
44 PQFP 28 PB4/INT4
AGND 7 10 x 10 mm 27 PB3/TxD2
XIN 8 26 PB2/RxD2
XOUT 9 25 PB1/T2EX
AVCC 10 24 PB0/T2
VCC 11 23 GND
12 13 14 15 16 17 18 19 20 21 22
PC1/TxD0
PC2/INT0#
PC3/INT1#
PC7/RD#
PC6/WR#
PC4/T0
PC5/T1
RESET
GND
VCC
PC0/RxD0
Figure 1-10. 44-pin PQFP Package with Port B (AN2121S, AN2122S, and AN2131S)
WAKEUP#
PA5/FRD#
DISCON#
USBD+
USBD-
GND
GND
VCC
SDA
SCL
44 43 42 41 40 39 38 37 36 35 34
GND 1 33 VCC
CLK24 2 32 BKPT
GND 3 31 D7
GND 4 30 D6
5 29
GND
GND 6
44 PQFP 28
D5
D4
AGND 7 10 x 10 mm 27 D3
XIN 8 26 D2
XOUT 9 25 D1
AVCC 10 24 D0
VCC 11 23 GND
12 13 14 15 16 17 18 19 20 21 22
PC0/RxD0
PC2/INT0#
PC3/INT1#
PC6/WR#
PC1/TxD0
PC7/RD#
RESET
PC4/T0
PC5/T1
GND
VCC
Figure 1-11. 44-pin Package with Data Bus (AN2125S, AN2126S, AN2135S, and AN2136)
PA4/FWR#
WAKEUP#
PA5/FRD#
DISCON#
USBD+
USBD-
GND
VCC
GND
SDA
SCL
48 47 46 45 44 43 42 41 40 39 38 37
GND 1 36 VCC
CLK24 2 35 BKPT
GND 3 34 PA0/T0OUT
GND 4 33 PB7/T2OUT
GND 5 32 PB6/INT6
AGND 7 30 PB4/INT4
PA7/RxD1OUT 8
7 x 7 mm 29 PB3/TxD1
XIN 9 28 PB2/RxD1
XOUT 10 27 PB1/T2EX
AVCC 11 26 PB0/T2
VCC 12 25 GND
13 14 15 16 17 18 19 20 21 22 23 24
PC7/RD#
PC4/T0
PC2/INT0#
PC5/T1
PC6/WR#
PC1/TxD0
PC3/INT1#
RESET
VCC
PC0/RxD0
GND
CPU12MHZ
Digital GND
Digital VCC
PA4/FWR#
WAKEUP#
PA5/FRD#
DISCON#
USBD+
USBD-
GND
VCC
GND
SDA
SCL
48 47 46 45 44 43 42 41 40 39 38 37
GND 1 36 VCC
CLK24 2 35 BKPT
GND 3 34 PA0/T0OUT
GND 4 33 D7
GND 5 32 D6
GND 6 48 TQFP 31 D5
AGND 7 30 D4
PA7/RxD1OUT 8 7 x 7 mm 29 D3
XIN 9 28 D2
XOUT 10 27 D1
AVCC 11 26 D0
VCC 12 25 GND
13 14 15 16 17 18 19 20 21 22 23 24
PC7/RD#
PC4/T0
VCC
PC2/INT0#
PC5/T1
PC6/WR#
PC1/TxD0
PC3/INT1#
PC0/RxD0
RESET
GND
CPU12MHZ
Digital GND
Digital VCC
2.1 Introduction
The EZ-USB built-in microprocessor, an enhanced 8051 core, is fully described in Appen-
dices A-C. This chapter introduces the processor, its interface to the EZ-USB core, and
describes architectural differences from a standard 8051.
The enhanced 8051 core uses the standard 8051 instruction set. Instructions execute faster
than with the standard 8051 due to two features:
• Wasted bus cycles are eliminated. A bus cycle uses four clocks, as compared to 12
clocks with the standard 8051.
In addition to the speed improvement, the enhanced 8051 core also includes architectural
enhancements:
2. A second UART.
7. 3.3V operation.
The EZ-USB chip provides additional enhancements outside the 8051. These include:
• Breakpoint Facility.
The 8051 communicates with the EZ-USB core through a set of memory mapped regis-
ters. These registers are grouped as follows:
• 8051 control
• IO ports
• Fast Transfer
• I2C Controller
• Interrupts
• USB Functions
These registers and their functions are described throughout this manual. A full descrip-
tion of every register and bit appears in Chapter 12, “EZ-USB Registers.”
FF Upper 128
SFR Space
bytes
Direct Addr
80 Indirect Addr
7F Lower 128
bytes
00 Direct Addr
Like the standard 8051, the EZ-USB 8051 core contains 128 bytes of register RAM at 00-
7F, and a partially populated SFR register space at 80-FF. An additional 128 indirectly
addressed registers (sometimes called “IDATA”) are also available at 80-FF.
All internal EZ-USB RAM, which includes program/data memory, bulk endpoint buffer
memory, and the EZ-USB register set, is addressed as add-on 8051 memory. The 8051
reads or writes these bytes as data using the MOVX (move external) instruction. Even
though the MOVX instruction implies external memory, the EZ-USB RAM and register
set is actually inside the EZ-USB chip. External memory attached to the AN2131Q
address and data busses can also be accessed by the MOVX instruction. The EZ-USB
core encodes its memory strobe and select signals (RD#, WR#, CS#, and OE#) to elimi-
nate the need for external logic to separate the internal and external memory spaces.
A standard 8051 communicates with its IO ports 0-3 through four Special Function Regis-
ters (SFRs). Standard 8051 IO pins are quasi-bidirectional with weak pullups that briefly
drive high only when the pin makes a zero-to-one transition.
The EZ-USB core implements IO ports differently than a standard 8051, as described
in Chapter 4, "EZ-USB Input/Output." Instead of using the 8051 IO ports and SFRs, the
EZ-USB core implements a flexible IO system that is controlled via EZ-USB register set.
Each EZ-USB IO pin functions identically, having the following resources:
• A bit that indicates the state of the IO pin, regardless of its configuration (input or
output).
• An alternate function bit that determines whether the pin is general IO or a special
8051 or EZ-USB function.
The SFRs associated with 8051 ports 0-3 are not implemented in EZ-USB. These SFR
addresses include P0 (0x80), P1 (0x90), P2 (0xA0), and P3 (0xB0). Because P2 is not
implemented, the MOVX@R0/R1 instruction takes the upper address byte from an added
Special Function Register (SFR) at location 0x92. This register is called “MPAGE” in the
Appendices.
2.7 Interrupts
All standard 8051 interrupts are supported in the enhanced 8051 core. Table 2-1 shows
the existing and added 8051 interrupts, and indicates how the added ones are used.
The EZ-USB chip uses 8051 INT2 for 21 different USB interrupts: 16 bulk endpoints plus
SOF, Suspend, SETUP Data, SETUP Token, and USB Bus Reset. To help the 8051 deter-
mine which interrupt is active, the EZ-USB core provides a feature called Autovectoring.
The core inserts an address byte into the low byte of the 3-byte jump instruction found at
the 8051 INT2 vector address. This second level of vectoring automatically transfers con-
trol to the appropriate USB ISR. The Autovector mechanism, as well as the EZ-USB
interrupt system is the subject of Chapter 9, "EZ-USB Interrupts."
The EZ-USB core implements a power-down mode that allows it to be used in USB bus
powered devices that must draw no more than 500 µA when suspended. Power control is
accomplished using a combination of 8051 and EZ-USB core resources. The mechanism
by which EZ-USB powers down for suspend, and then re-powers to resume operation, is
described in detail in Chapter 11, “EZ-USB Power Management.”
A suspend operation uses three 8051 resources, the idle mode and two interrupts. Many
enhanced 8051 architectures provide power control similar (or identical) to the EZ-USB
enhanced 8051 core.
A USB suspend operation is indicated by a lack of bus activity for 3 ms. The EZ-USB
core detects this, and asserts an interrupt request via the USB interrupt (8051 INT2). The
ISR (Interrupt Service Routine) turns off external sub-systems that draw power. When
ready to suspend operation, the 8051 sets an SFR bit, PCON.0. This bit causes the 8051 to
suspend, waiting for an interrupt.
When the 8051 sets PCON.0, a control signal from the 8051 to the EZ-USB core causes
the core to shut down the 12-MHz oscillator and internal PLL. This stops all internal
clocks to allow the EZ-USB core and 8051 to enter a very low power mode.
The suspended EZ-USB chip can be awakened two ways: USB bus activity may resume,
or an EZ-USB pin (WAKEUP#) can be asserted to activate a USB Remote Wakeup. Either
event triggers the following chain of events:
• The EZ-USB core re-starts the 12-MHz oscillator and PLL, and waits for the
clocks to stabilize
• The 8051 vectors to the resume ISR, and upon completion resumes executing code
at the instruction following the instruction that set the PCON.0 bit to 1.
The EZ-USB family was designed to keep 8051 coding as standard as possible, to allow
easy integration of existing 8051 software development tools. The added 8051 SFR regis-
ters and bits are summarized in Table 2-2.
Members of the EZ-USB family that provide pins to expand 8051 memory provide sepa-
rate non-multiplexed 16-bit address and 8-bit data busses. This differs from the standard
8051, which multiplexes eight device pins between three sources: IO port 0, the external
data bus, and the low byte of the address bus. A standard 8051 system with external mem-
ory requires a de-multiplexing address latch, strobed by the 8051 ALE (Address Latch
Enable) pin. The external latch is not required by the non-multiplexed EZ-USB chip, and
no ALE signal is needed. In addition to eliminating the customary external latch, the non-
multiplexed bus saves one cycle per memory fetch cycle, further improving 8051 perfor-
mance.
A standard 8051 user must choose between using Port 0 as a memory expansion port or an
IO port. The AN2131Q provides a separate IO system with its own control registers (in
external memory space), and provides the IO port signals on dedicated (not shared) pins.
This allows the external data bus to be used to expand memory without sacrificing IO
pins.
The 8051 is the sole master of the memory expansion bus. It provides read and write sig-
nals to external memory. The address bus is output-only.
A special fast transfer mode gives the EZ-USB family the capability to transfer data to
and from external memory over the expansion bus using a single MOVX instruction,
which takes only two cycles (eight clocks) per byte.
2.11 Reset
The internal 8051 RESET signal is not directly controlled by the EZ-USB RESET pin.
Instead, it is controlled by an EZ-USB register bit accessible to the USB host. When the
EZ-USB chip is powered, the 8051 is held in reset. Using the default USB device (enu-
merated by the USB core), the host downloads code into RAM. Finally, the host clears an
EZ-USB register bit that takes the 8051 out of reset.
The EZ-USB family also operates with external non-volatile memory, in which case the
8051 exits the reset state automatically at power-on. The various EZ-USB resets and their
effects are described in Chapter 10, "EZ-USB Resets."
3.1 Introduction
EZ-USB devices divide RAM into two regions, one for code and data, and the other for
USB buffers and control registers.
7FFF
Registers/Bulk Buffers
7B40
27FF 16 x 64-byte
Data (RD/WR) RAM
If ISODISAB=1 Bulk Endpoint Buffers
2000
(1,024 bytes)
1FFF
Registers/Bulk Buffers 1B40/7B40
1B40
1B3F
Data (RD/WR) RAM
Code(PSEN) RAM if
EA=0
(6,976 bytes)
0000
0FFF
Code(PSEN) and
Data (RD/WR) RAM
(4096 bytes)
0000
Figure 3-1 illustrates the two internal EZ-USB RAM regions. 6,976 bytes of general-pur-
pose RAM occupy addresses 0x0000-0x1B3F. This RAM is loadable by the EZ-USB
core or I2C bus EEPROM, and contains 8051 code and data.
The EZ-USB EA (External Access) pin controls where the bottom segment of code
(PSEN) memory is located—inside (EA=0) or outside (EA=1) the EZ-USB chip. If the
EZ pin is tied low, the EZ-USB core internally ORs the two 8051 read signals PSEN and
RD for this region, so that code and data share the 0x0000-0x1B3F memory space. IF
EA=1, all code (PSEN) memory is external.
1,024 bytes of RAM at 0x7B40-0x7F3F implement the sixteen bulk endpoint buffers. 192
additional bytes at 0x7F40-0x7FFF contain the USB control registers. The 8051 reads and
writes this memory using the MOVX instruction. In the 8-KB RAM EZ-USB version, the
1,024 bulk endpoint buffer bytes at 0x7B40-0x7F3F also appear at 0x1B40-0x1F3F. This
aliasing allows unused bulk endpoint buffer memory to be added contiguously to the data
memory, as illustrated Figure 3-3. The memory space at 0x1F40-0x1FFF should not be
used.
Even though the 8051 can access EZ-USB endpoint buffers at either 0x1B40 or 0x7B40,
the firmware should be written to access this memory only at 0x7B40-0x7FFF to maintain
compatibility with future versions of EZ-USB that contain more than 8 KB of RAM.
Future versions will have the bulk buffer space at 0x7B40-0x7F3F only.
Figure 3-3. Unused Bulk Endpoint Buffers (Shaded) Used as Data Memory
In the example shown in Figure 3-3, only endpoints 0-IN through 3-IN are used for the
USB function, so the data RAM (shaded) can be extended to 0x1D7F.
If an application uses none of the 16 EZ-USB isochronous endpoints, the 8051 can set the
ISODISAB bit in the ISOCTL register to disable all 16 isochronous endpoints, and make
the 2-KB of isochronous FIFO RAM available as 8051 data RAM at 0x2000-0x27FF.
Setting ISODISAB=1 is an all or nothing choice, as all 16 isochronous endpoints are dis-
abled. An application that sets this bit must never attempt to transfer data over an isochro-
nous endpoint.
The memory map figures in the remainder of this chapter assume that ISODISAB=0, the
default (and normal) case.
The 80-pin EZ-USB package provides a 16-bit address bus, an 8-bit bus, and memory
control signals PSEN#, RD#, and WR#. These signals are used to expand EZ-USB
memory.
External
Data
Memory
(RD,WR)
External
Code
Memory
8000
Registers(RD,WR) (Note 1) (PSEN)
7B40
External
Data
Memory
(RD, WR)
2000
1FFF
1F3F Unused Bulk Buffers
(RD,WR) (Note 1)
1B40
Code & Data
(Note 2)
(PSEN,RD,WR)
0000
Note 1: OK to populate data memory here--RD#, WR#, CS# and OE# pins are inactive.
Note 2: OK to populate code memory here--no PSEN# strobe is generated.
Figure 3-4 shows that when EA=0, the code/data memory is internal at 0x0000-0x1B40.
External code memory can be added from 0x0000-0xFFFF, but it appears in the memory
map only at 0x1B40-0xFFFF. Addressing external code memory at 0x0000-0x1B3F
when EA=0 causes the EZ-USB core to inhibit the #PSEN strobe. This allows program
memory to be added from 0x0000-0xFFFF without requiring decoding to disable it
between 0x0000 and 0x1B3F.
The EZ-USB core automatically gates the standard 8051 RD# and WR# signals to exclude
selection of external memory that exists internal to the EZ-USB part. The PSEN# signal is
also available on a pin for connection to external code memory.
Some 8051 systems implement external memory that is used as both data and program
memory. These systems must logically OR the PSEN# and RD# signals to qualify the
chip enable and output enable signals of the external memory. To save this logic, the EZ-
USB core provides two additional control signals, CS# and OE#. The equations for these
signals are as follows:
Because the RD#, WR#, and PSEN# signals are already qualified by the addresses allo-
cated to external memory, these strobes are active only when external memory is accessed.
External
Data
Memory
(RD,WR)
External
8000 Code
Registers(RD,WR) (Note 1) Memory
7B40 (PSEN)
External
Data
Memory
(RD, WR)
2000
1FFF
1F3F Unused Bulk Buffers
(RD,WR) (Note 1)
1B40
Data (RD,WR)
0000
Note 1: OK to populate data memory here--RD#, WR#, CS# and OE# are inactive.
When EA=1 (Figure 3-5), all code (PSEN) memory is external. All internal EZ-USB
RAM is data memory. This gives the user over 6-KB of general-purpose RAM, accessible
by the MOVX instruction.
Note
Figures 3-4 and 3-5 assume that the EZ-USB chip uses isochronous endpoints, and there-
fore that the ISODISAB bit (ISOCTL.0) is LO. If ISODISAB=1, additional data RAM
appears internally at 0x2000-0x27FF, and the RD#, WR#, CS#, and OE# signals are
modified to exclude this memory space from external data memory.
The EZ-USB 8-KB Masked ROM and 32-KB Masked ROM memory maps are shown in
Figures 3-6 and 3-7.
External
Data
Memory
(RD,WR)
External
Code
Memory
(PSEN)
8000
Registers(RD,WR) (Note 1)
7B40
External
Data
Memory
(RD, WR)
2000
Internal Code
0800 (Note 2)
Memory(PSEN)
07FF Data (RD,WR) (Note 1)
0000
Note 1: OK to populate data memory here, but no RD# or WR# strobes are generated.
Note 2: OK to populate code memory here, but no PSEN# strobe is generated.
EZ-USB ROM versions contain program memory starting at 0x0000. In these versions,
the internal RAM is implemented as data-only memory.
Code for this ROM version can be developed and tested using the AN2131Q with an
external code memory (EA=1, Figure 3-5). As long as the 8051 limits internal RAM
access to 0x0000-0x07FF and accesses the EZ-USB registers and bulk data at 0x7B40-
0x7FFF, the code in the external memory will be the identical image of the code that will
ultimately be internal at 0x0000-0x1FFF in the ROM version.
External External
Data Code
Memory Memory
(RD,WR) (PSEN)
8000
7FFF Registers(RD,WR) (Note 1)
7B40
External
Internal Code Data
Memory (Note 2)
Memory(PSEN)
(RD, WR)
1000
0FFF
Data (RD,WR) (Note 1)
0000
Note 1: OK to populate data memory here, but no RD# or WR# strobes are generated.
Note 2: OK to populate code memory here, but no PSEN# strobe is generated.
The EZ-USB 32-KB ROM version contains program memory from 0x0000 through
0x7FFF, and data memory from 0x0000 through 0x0FFF.
Code for this ROM version can be developed and tested using the AN2131Q with an
external code memory (EA=1, Figure 3-5). As long as the 8051 limits internal RAM
access to 0x0000-0x0FFF and accesses the EZ-USB registers and bulk data at 0x7B40-
0x7FFF, the code in the external memory will be the identical image of the code that will
ultimately be internal at 0x0000-0x7FFF in the ROM version.
4.1 Introduction
This chapter begins with a description of the programmable IO pins, and shows how they
are shared by a variety of 8051 and EZ-USB alternate functions such as UART, timer and
interrupt signals.
The I2C controller uses the SCL and SDA pins, and performs two functions:
Note
2.2-KB to 4.7-KB pullups are required on the SDA and SCL lines.
This chapter describes both the programming information for the 8051 I2C interface, and
the operating details of the I2C boot loader. The role of the boot loader is described in
Chapter 5, "EZ-USB Enumeration and ReNumeration."
OE
PINS
The EZ-USB family implements its IO ports using memory-mapped registers. This is in
contrast to a standard, which uses SFR bits for input/output.
Figure 4-1 shows the basic structure of an EZ-USB IO pin. Twenty-four IO pins are
grouped into three 8-bit ports named PORTA, PORTB, and PORTC. The AN2131Q has
all three ports, while the AN2131S has PORTB, PORTC, and two PORTA bits. The 8051
accesses IO pins using the three control bits shown in Figure 4-1: OE, OUT, and PINS.
The OUT bit writes output data to a register, the OE bit turns on the output buffer, and the
PINS bit indicates the state of the pin.
To configure a pin as an input, the 8051 sets OE=0 to turn off the output buffer. To config-
ure a pin as an output, the 8051 sets OE=1 to turn on the output buffer, and writes data to
the OUT register. The PINS bit reflects the actual pin value regardless of the value of OE.
Depending on whether the alternate function is an input or output, the IO logic is slightly
different, as shown in Figure 4-2 (output) and Figure 4-3 (input). The last column of
Table 4-1 indicates which figure applies to each pin.
OE OE
Pin
OUT reg Pin OUT reg
PINS PINS
Referring to Figure 4-2, when PORTCFG=0, the IO port is selected. In this case the alter-
nate function (shaded) is disconnected and the pin functions exactly as shown in
Figure 4-1. When PORTCFG=1, the alternate function is connected to the IO pin and the
output register and buffer are disconnected. Note that the 8051 can still read the state of
the pin, and thus the alternate function value.
OE OE
Pin
OUT reg Pin OUT reg
PINS PINS
Referring to Figure 4-3, when PORTCFG=0, the IO port is selected. This is the general
IO port shown in Figure 4-1 with one important difference—the alternate function is
always listening. Whether the port pin is set for output or input, the pin signal also drives
the alternate function. 8051 firmware should ensure that if the alternate function is not
used (if the pin is GPIO only), the alternate input function is disabled.
For example, suppose the PB4/INT4 pin is configured for PB4. The pin signal is also
routed to INT4. If INT4 is not used by the application, it should not be enabled. Alterna-
tively, enabling INT4 could be useful, allowing IO bit PB4 to trigger an interrupt.
When PORTxCFG=1, the alternate function is selected. The output register and buffer are
disconnected. The PINS bit can still read the pin, and thus the input to the alternate func-
tion.
OUTA D7 D6 D5 D4 D3 D2 D1 D0
PINSA D7 D6 D5 D4 D3 D2 D1 D0
OEA D7 D6 D5 D4 D3 D2 D1 D0
OUTB D7 D6 D5 D4 D3 D2 D1 D0
PINSB D7 D6 D5 D4 D3 D2 D1 D0
OEB D7 D6 D5 D4 D3 D2 D1 D0
OUTC D7 D6 D5 D4 D3 D2 D1 D0
PINSC D7 D6 D5 D4 D3 D2 D1 D0
OEC D7 D6 D5 D4 D3 D2 D1 D0
Figure 4-4 shows the registers associated with the EZ-USB IO ports. The power-on
default for the PORTCFG bits is 0, selecting the IO port function. The power-on default
for the OE bits is 0, selecting the input direction.
The USB core contains an I 2C controller for boot loading and general-purpose I 2C bus
interface. This controller uses the SCL (Serial Clock) and SDA (Serial Data) pins. I2C
Controller describes how the boot load operates at power-on to read the contents of an
external serial EEPROM to determine the initial EZ-USB FX configuration. The boot
loader operates automatically, while the 8051 is held in reset. The last section of this chap-
ter describes the operating details of the boot loader.
After the boot sequence completes and the 8051 is brought out of reset, the general-pur-
pose I 2C controller is available to the 8051 for interface to external I 2C devices, such as
other EEPROMS, I/O chips, audio/video control chips, etc.
start stop
SDA D7 D6 D5 D4 D3 D2 D1 D0 ACK
SCL 1 2 3 4 5 6 7 8 9
Figure 4-5 illustrates the waveforms for an I 2C transfer. SCL and SDA are open-drain EZ-
USB pins, which must be pulled up to Vcc with external resistors. The EZ-USB chip is an
I 2C bus master only, meaning that it synchronizes data transfers by generating clock
pulses on SCL by driving low. Once the master drives SCL low, external slave devices can
also drive SCL low to extend clock cycle times.
To synchronize I 2C data, serial data (SDA) is permitted to change state only while SCL is
low, and must be valid while SCL is high. Two exceptions to this rule are used to generate
START and STOP conditions. A START condition is defined as SDA going low, while
SCL is high, and a STOP condition is defined as SDA going high, while SCL is high. Data
is sent MSB first. During the last bit time (clock #9 in Figure 4-5), the master (EZ-USB)
floats the SDA line to allow the slave to acknowledge the transfer by pulling SDA low.
start
SDA SA3 SA2 SA1 SA0 DA2 DA1 DA0 R/W ACK D7 D6
SCL 1 2 3 4 5 6 7 8 9 10 11
The first byte of an I 2C bus transaction contains the address of the desired peripheral.
Figure 4-7 shows the format for this first byte, which is sometimes called a control byte.
A master sends the bit sequence shown in Figure 4-6 after sending a START condition.
The master uses this 9-bit sequence to select an I 2C peripheral at a particular address, to
establish the transfer direction (using R/W#), and to determine if the peripheral is present
by testing for ACK#.
The four most significant bits SA3-SA0 are the peripheral chip’s slave address. I2C
devices are pre-assigned slave addresses by device type, for example slave address 1010 is
assigned to EEPROMS. The three bits DA2-DA0 usually reflect the states of I2C device
address pins. Devices with three address pins can be strapped to allow eight distinct
addresses for the same device type. The eighth bit (R/W#) sets the direction for the ensu-
ing data transfer, 1 for master read, and 0 for master write. Most address transfers are fol-
lowed by one or more data transfers, with the STOP condition generated after the last data
byte is transferred.
In Figure 4-6, a READ transfer follows the address byte (at clock 8, the master sets the R/
W# bit high, indicating READ). At clock 9, the peripheral device responds to its address
by asserting ACK. At clock 10, the master floats SDA and issues SCL pulses to clock in
SDA data supplied by this slave.
Assuming the 12-MHz crystal used by the EZ-USB family, the SCL frequency is 90.9
KHz, giving an I2C transfer rate of 11 ms per bit.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
D7 D6 D5 D4 D3 D2 D1 D0
The 8051 uses the two registers shown in Figure 4-7 to conduct I2C transfers. The 8051
transfers data to and from the I2C bus by writing and reading the I2DAT register. The
12CS register controls I2C transfers and reports various status conditions. The three con-
trol bits are START, STOP, and LASTRD. The remaining bits are status bits. Writing to a
status bit has no effect.
4.6.1 START
The 8051 sets the START bit to 1 to prepare an I2C bus transfer. If START=1, the next
8051 load to I2DAT will generate the start condition followed by the serialized byte of
data in I2DAT. The 8051 loads data in the format shown in Figure 4-5 after setting the
START bit. The I2C controller clears the START bit during the ACK interval (clock 9 in
Figure 4-5).
4.6.2 STOP
The 8051 sets STOP=1 to terminate an I2C bus transfer. The I2C controller clears the
STOP bit after completing the STOP condition. If the 8051 sets the STOP bit during a
byte transfer, the STOP condition will be generated immediately following the ACK phase
of the byte transfer. If no byte transfer is occurring when the STOP bit is set, the STOP
condition will be carried out immediately on the bus. Data should not be written to I2CS
4.6.3 LASTRD
To read data over the I2C bus, an I2C master floats the SDA line and issues clock pulses on
the SCL line. After every eight bits, the master drives SDA low for one clock to indicate
ACK. To signal the last byte of the read transfer, the master floats SDA at ACK time to
instruct the slave to stop sending. This is controlled by the 8051 by setting LASTRD=1
before reading the last byte of a read transfer. The I2C controller clears the LASTRD bit at
the end of the transfer (at ACK time).
Note
Setting LASTRD does not automatically generate a STOP condition. The 8051 should
also set the STOP bit at the end of a read transfer.
After a byte transfer the EZ-USB controller updates the three status bits BERR, ACK, and
DONE. If no STOP condition was transmitted, they are updated at ACK time. If a STOP
condition was transmitted they are updated after the STOP condition is transmitted.
4.7.1 DONE
The I2C controller sets this bit whenever it completes a byte transfer, right after the ACK
stage. The controller also generates an I2C interrupt request (8051 INT3) when it sets the
DONE bit. The I2C controller clears the DONE bit when the 8051 reads or writes the
I2DAT register, and the I2C interrupt request bit whenever the 8051 reads or writes the
I2CS or I2DAT register.
4.7.2 ACK
Every ninth SCL of a write transfer, the slave indicates reception of the byte by asserting
ACK. The EZ-USB controller floats SDA during this time, samples the SDA line, and
updates the ACK bit with the complement of the detected value. ACK=1 indicates
acknowledge, and ACK=0 indicates not-acknowledge. The EZ-USB core updates the
4.7.3 BERR
This bit indicates an I2C bus error. BERR=1 indicates that there was bus contention,
which results when an outside device drives the bus LO when it shouldn’t, or when
another bus master wins arbitration, taking control of the bus. BERR is cleared when the
8051 reads or writes the I2DAT register.
These bits are set by the boot loader (Section 4.10, "I2C Boot Loader") to indicate whether
an 8-bit address or 16-bit address EEPROM at slave address 000 or 001 was detected at
power-on. They are normally used only for debug purposes. Table 4-3 shows the encod-
ing for these bits.
To send a multiple byte data record over the I2C bus, follow these steps:
6. Repeat steps 4 and 5 for each byte until all bytes have been transferred.
7. Set STOP=1.
* If the I2C interrupt (8051 INT3) is enabled, each “Wait for DONE=1” step can be inter-
rupt driven, and handled by an interrupt service routine. See Section 9.12, "I2C Inter-
rupt” for more details regarding the I2C interrupt.
4. Read I2DAT and discard the data. This initiates the first burst of nine SCL pulses
to clock in the first byte from the slave.
6. Read the data from I2DAT. This initiates another read transfer.
7. Repeat steps 5 and 6 for each byte until ready to read the second-to-last byte.
9. Read the data from I2DAT. With LASTRD=1, this initiates the final byte read on
the I2C bus.
12. Read the last byte from I2DAT immediately (the next instruction) after setting the
STOP bit. This retrieves the last data byte without initiating an extra read transac-
tion (nine more SCL pulses) on the I2C bus.
* If the I2C interrupt (8051 INT3) is enabled, each “Wait for DONE=1” step can be inter-
rupt-driven, and handled by an interrupt service routing. See Section 9.12, "I2C Inter-
rupt” for more details regarding the I2C interrupt.
When the EZ-USB chip comes out of reset, the EZ-USB boot loader checks for the pres-
ence of an EEPROM on its I2C bus. If an EEPROM is detected, the loader reads the first
EEPROM byte to determine how to enumerate (specifically, whether to supply ID infor-
mation from the EZ-USB core or from the EEPROM). The various enumeration modes
are described in Chapter 5, "EZ-USB Enumeration and ReNumeration."
Prior to reading the first EEPROM byte, the boot loader must set an address counter inside
the EEPROM to zero. It does this by sending a control byte (write) to select the
EEPROM, followed by a zero address to set the internal EEPROM address pointer to zero.
Then it issues a control byte (read), and reads the first EEPROM byte.
EEPROMs with densities up to 256 bytes require loading a single address byte. Larger
EEPROMs require loading two address bytes.
The EZ-USB I2C controller needs to determine which EEPROM type is connected—one
or two address bytes—so that it can properly reset the EEPROM address pointer to zero
before reading the EEPROM. For the single-byte address part, it must send a single zero
byte of address, and for the two-byte address part it must send two zero bytes of address.
The I2C controller performs a three-step test at power-on to determine whether a one-byte-
address or a two-byte-address EEPROM is attached. This test proceeds as follows:
1. The I2C controller sends out a “read current address” command to I2C sub-address
000 (10100001). If no ACK is returned, the controller proceeds to step 2. If ACK
is returned, the one-byte-address device is indicated. The controller discards the
data and proceeds to step 3.
2. The I2C controller sends out a “read current address” command to I2C sub-address
001 (10100011). If ACK is returned, the two-byte-address device is indicated.
The controller discards the data and proceeds to step 3. If no ACK is returned, the
controller assumes that a valid EEPROM is not connected, assumes the “No Serial
EEPROM” mode, and terminates the boot load.
3. The I2C controller resets the EEPROM address pointer to zero (using the appropri-
ate number of address bytes), then reads the first EEPROM byte. If it does not
read 0xB0 or 0xB2, the controller assumes the “No Serial EEPROM” mode. If it
reads either 0xB0 or 0xB2, the controller copies the next six bytes into internal
storage, and if it reads 0xB2, it proceeds to load the EEPROM contents into inter-
nal RAM.
Other EEPROM devices (with device address of 1010) can be attached to the I2C bus for
general purpose 8051 use, as long as they are strapped for address other than 000 or 001.
If a 24LC00 EEPROM is used, no other EEPROMS with device address 1010 may be
used, because the 24LC00 responds to all eight sub-addresses.
5.1 Introduction
The EZ-USB chip is soft. 8051 code and data is stored in internal RAM, which is loaded
from the host using the USB interface. Peripheral devices that use the EZ-USB chip can
operate without ROM, EPROM, or FLASH memory, shortening production lead times
and making firmware updates a breeze.
To support the soft feature, the EZ-USB chip automatically enumerates as a USB device
without firmware, so the USB interface itself may be used to download 8051 code and
descriptor tables. The EZ-USB core performs this initial (power-on) enumeration and
code download while the 8051 is held in reset. This initial USB device, which supports
code download, is called the “Default USB Device.”
After the code descriptor tables have been downloaded from the host to EZ-USB RAM,
the 8051 is brought out of reset and begins executing the device code. The EZ-USB
device enumerates again, this time as the loaded device. This second enumeration is
called “ReNumeration,” which the EZ-USB chip accomplishes by electrically simulat-
ing a physical disconnection and re-connection to the USB.
An EZ-USB control bit called “ReNum” (ReNumerated) determines which entity, the core
or the 8051, handles device requests over endpoint zero. At power-on, the RENUM bit
(USBCS.1) is zero, indicating that the EZ-USB core automatically handles device
requests. Once the 8051 is running, it can set ReNum=1 to indicate that user 8051 code
handles subsequent device requests using its downloaded firmware. Chapter 7, "EZ-USB
Endpoint Zero" describes how the 8051 handles device requests while ReNum=1.
It is also possible for the 8051 to run with ReNum=0 and have the EZ-USB core handle
certain endpoint zero requests (see the text box, “Another Use for the Default USB
Device” on page 5-2).
This chapter deals with the various EZ-USB startup modes, and describes the default USB
device that is created at initial enumeration.
The Default USB Device consists of a single USB configuration containing one interface
(interface 0) with three alternate settings 0, 1, and 2. The endpoints reported for this
device are shown in Table 5-1. Note that alternate setting zero uses no interrupt or isoch-
ronous bandwidth, as recommended by the USB Specification.
When the EZ-USB core establishes the Default USB Device, it also sets the proper end-
point configuration bits to match the descriptor data supplied by the EZ-USB core. For
example, bulk endpoints 2, 4, and 6 are implemented in the Default USB Device, so the
EZ-USB core sets the corresponding EPVAL bits. Chapter 6, “EZ-Bulk Transfers” con-
tains a detailed explanation of the EPVAL bits.
Tables 5-9 through 5-13 show the various descriptors returned to the host by the EZ-USB
core when ReNum=0. These tables describe the USB endpoints defined in Table 5-1,
along with other USB details, and should be useful to help understand the structure of
USB descriptors.
Table 5-2 shows how the EZ-USB core responds to endpoint zero requests when
ReNum=0.
Table 5-2. How the EZ-USB Core Handles EP0 Requests When ReNum=0
bRequest Name Action: ReNum=0
0x00 Get Status/Device Returns two zero bytes
0x00 Get Status/Endpoint Supplies EP Stall bit for indicated EP
0x00 Get Status/Interface Returns two zero bytes
0x01 Clear Feature/Device None
0x01 Clear Feature/Endpoint Clears Stall bit for indicated EP
0x02 (reserved) None
0x03 Set Feature/Device None
0x03 Set Feature Endpoint Sets Stall bit for indicated EP
0x04 (reserved) None
0x05 Set Address Updates FNADD register
0x06 Get Descriptor Supplies internal table
0x07 Set Descriptor None
0x08 Get Configuration Returns internal value
0x09 Set Configuration Sets internal value
0x0A Get Interface Returns internal value (0-3)
0x0B Set Interface Sets internal value (0-3)
0x0C Sync Frame None
Vendor Requests
0x0A Firmware Load Upload/Download RAM
0xA1-0xAF Reserved Reserved by Cypress Semiconductor
all other None
• Set_Address
• Get_Descriptor
• Set_Configuration (to 1)
To ensure proper operation of the default Keil Monitor, which uses SIO-1 (RXD1 and
TXD1), never change the following Port Config bits from “1”:
The USB Specification provides for vendor-specific requests to be sent over CONTROL
endpoint zero. The EZ-USB chip uses this feature to transfer data between the host and
EZ-USB RAM. The EZ-USB core responds to two “Firmware Load” requests, as shown
in Tables 5-3 and 5-4.
These requests are always handled by the EZ-USB core (ReNum=0 or 1). This means that
0xA0 is reserved by the EZ-USB chip, and therefore should never be used for a vendor
request. Cypress Semiconductor also reserves bRequest values 0xA1 through 0xAF, so
your system should not use these bRequest values.
A host loader program typically writes 0x01 to the CPUCS register to put the 8051 into
RESET, loads all or part of the EZ-USB RAM with 8051 code, and finally reloads the
CPUCS register with 0 to take the 8051 out of RESET. The CPUCS register is the only
USB register that can be written using the Firmware Download command.
When the EZ-USB chip comes out of reset, the EZ-USB core makes a decision about how
to enumerate based on the contents of an external EEPROM on its I2C bus. Table 5-5
shows the choices. In Table 5-5, PID means Product ID, VID means Version ID, and DID
means Device ID.
If no EEPROM is present, or if one is present but the first byte is neither 0xB0 nor 0xB2,
the EZ-USB core enumerates using internally stored descriptor data, which contains the
Cypress Semiconductor VID, PID, and DID. These ID bytes cause the host operating sys-
tem to load a Cypress Semiconductor device driver. The EZ-USB core also establishes the
Default USB device. This mode is only used for code development and debug.
If a serial EEPROM is attached to the I2C bus and its first byte is 0xB0, the EZ-USB core
enumerates with the same internally stored descriptor data as for the no-EEPROM case,
but with one difference. It supplies the PID/VID/DID data from six bytes in the external
EEPROM rather than from the EZ-USB core. The custom VID/PID/DID in the EEPROM
causes the host operating system to load a device driver that is matched to the EEPROM
VID/PID/DID. This EZ-USB operating mode provides a soft USB device using ReNu-
meration.
If a serial EEPROM is attached to the I2C bus and its first byte is 0xB2, the EZ-USB core
transfers the contents of the EEPROM into internal RAM. The EZ-USB core also sets the
ReNum bit to 1 to indicate that the 8051 (and not the EZ-USB core) responds to device
requests over CONTROL endpoint zero (see the text box, “When ReNum=1 at Power-
On” on page 5-6). Therefore, all descriptor data, including VID/DID/PID values, are sup-
plied by the 8051 firmware. The last byte loaded from the EEPROM (to the CPUCS reg-
ister) releases the 8051 reset signal, allowing the EZ-USB chip to come up as a fully
custom device with firmware in RAM.
The EZ-USB I2C controller serves two purposes. First, as described in this chapter, it
manages the serial EEPROM interface that operates automatically at power-on to deter-
mine the enumeration method. Second, once the 8051 is up and running, the 8051 can
access the I2C controller for general-purpose use. This makes a wide range of standard
I2C peripherals available to an EZ-USB system.
Other I2C devices can be attached to the SCL and SDA lines of the I2C bus as long as
there is no address conflict with the serial EEPROM described in this chapter. Chapter 4,
"EZ-USB Input/Output" describes the general-purpose nature of the I2C interface.
In the simplest case, no serial EEPROM is present on the I2C bus, or an EEPROM is
present but its first byte is not 0xB0 or 0xB2. In this case, descriptor data is supplied by a
table internal to the EZ-USB core. The EZ-USB chip comes on as the USB Default
Device, with the ID bytes shown in Table 5-6.
The USB host queries the device during enumeration, reads the device descriptor, and uses
the Table 5-6 bytes to determine which software driver to load into the operating system.
This is a major USB feature—drivers are dynamically matched with devices and automat-
ically loaded when a device is plugged in.
The no_EEPROM case is the simplest configuration, but also the most limiting. This
mode is used only for code development, utilizing Cypress software tools matched to the
ID values in Table 5-6.
If, at power-on, the EZ-USB core detects an EEPROM connected to its I2C port with the
value 0xB0 at address 0, the EZ-USB core copies the Vendor ID (VID), Product ID (PID),
and Device ID (DID) from the EEPROM (Table 5-7) into internal storage. The EZ-USB
core then supplies these bytes to the host as part of the Get_Descriptor-Device request.
(These six bytes replace only the VID/PID/DID bytes in the default USB device descrip-
tor.) This causes a driver matched to the VID/PID/DID values in the EEPROM, instead of
those in the EZ-USB core, to be loaded into the OS.
After initial enumeration, the driver downloads 8051 code and USB descriptor data into
EZ-USB RAM and starts the 8051. The code then ReNumerates to come on as the fully
custom device.
A recommended EEPROM for this application is the Microchip 24LC00, a small (5-pin
SOT package) inexpensive 16-byte serial EEPROM. A 24LC01 (128 bytes) or 24LC02
(256 bytes) may be substituted for the 24LC00, but as with the 24LC00, only the first
seven bytes are used.
If, at power-on, the EZ-USB core detects an EEPROM connected to its I2C port with the
value 0xB2 at address 0; the EZ-USB core loads the EEPROM data into EZ-USB RAM.
It also sets the ReNum bit to 1, causing device requests to be fielded by the 8051 instead of
the EZ-USB core. The EEPROM data format is shown in Table 5-8.
The first byte tells the EZ-USB core to copy EEPROM data into RAM. The next six bytes
(1-6) are ignored (see the text box, “VID/PID/DID in a “B2” EEPROM” on page 5-11).
Serial EEPROM data can be loaded into two EZ-USB RAM spaces only.
5.9 ReNumeration
Three EZ-USB control bits in the USBCS (USB Control and Status) register control the
ReNumeration process: DISCON, DISCOE, and RENUM.
b7 b6 b5 b4 b3 b2 b1 b0
DISCON DISCON#
pin
DISCOE
The logic for the DISCON and DISCOE bits is shown in Figure 5-2. To simulate a USB
disconnect, the 8051 writes the value 00001010 to USBCS. This floats the DISCON# pin,
and provides an internal DISCON signal to the USB core that causes it to perform discon-
nect housekeeping.
To re-connect to USB, the 8051 writes the value 00000110 to USBCS. This presents a
logic HI to the DISCON# pin, enables the output buffer, and sets the RENUM bit HI to
indicate that the 8051 (and not the USB core) is now in control for USB transfers. This
arrangement allows connecting the 1,500-ohm resistor directly between the DISCON# pin
and the USB D+ line (Figure 5-3).
DISCON#
EZ-USB
1500
To 3.3V regulator
J1
1
VCC 2
D- 3
D-
D+ 4 D+
GND
USB-B
The 8051 can ReNumerate anytime. Once use for this capability might be to fine tune
an isochronous endpoint’s bandwidth requests by trying various descriptor values and
ReNumerating.
Tables 5-9 through 5-19 show the descriptor data built into the EZ-USB core. The tables
are presented in the order that the bytes are stored.
The configuration descriptor includes a total length field (offset 2-3) that encompasses all
interface and endpoint descriptors that follow the configuration descriptor. This configu-
ration describes a single interface (offset 4). The host selects this configuration by issuing
a Set_Configuration requests specifying configuration #1 (offset 5).
Interface 0, alternate setting 0 describes endpoint 0 only. This is a zero bandwidth setting.
The interface has no string index.
Interface 0, alternate setting 1 has thirteen endpoints, whose individual descriptors follow
the interface descriptor. The alternate settings have no string indices.
Table 5-13. USB Default Interface 0, Alternate Setting 1, Interrupt Endpoint Descriptor
Offset Field Description Value
0 bLength Length of this Endpoint Descriptor 07H
1 bDescriptorType Descriptor Type = Endpoint 05H
2 bEndpointAddress Endpoint Direction (1 is in) and Address = IN1 81H
3 bmAttributes XFR Type = INT 03H
4 wMaxPacketSize (L) Maximum Packet Size = 16 Bytes 10H
5 wMaxPacketSize (H) Maximum Packet Size - High 00H
6 bInterval Polling Interval in Milliseconds = 10 ms 0AH
Interface 0, alternate setting 1 has one interrupt endpoint, IN1, which has a maximum
packet size of 16 and a polling interval of 10 ms.
Interface 0, alternate setting 1 has six bulk endpoints with max packet sizes of 64 bytes.
Even numbered endpoints were chosen to allow endpoint pairing. For more on endpoint
pairing, see Chapter 6, "EZ-USB Bulk Transfers."
Interface 0, alternate setting 2 has thirteen endpoints, whose individual descriptors follow
the interface descriptor. Alternate setting 2 differs from alternate setting 1 in the maxi-
mum packet sizes of its interrupt endpoint and two of its isochronous endpoints (EP8IN
and EP8OUT).
Table 5-17. USB Default Interface 0, Alternate Setting 1, Interrupt Endpoint Descriptor
Offset Field Description Value
0 bLength Length of this Endpoint Descriptor 07H
1 bDescriptorType Descriptor Type = Endpoint 05H
2 bEndpointAddress Endpoint Direction (1 is in) and Address = IN1 81H
3 bmAttributes XFR Type = INT 03H
4 wMaxPacketSize (L) Maximum Packet Size = 64 Bytes 40H
5 wMaxPacketSize (H) Maximum Packet Size - High 00H
6 bInterval Polling Interval in Milliseconds = 10 ms 0AH
Alternate setting 2 for the interrupt 1-IN increases the maximum packet size for the inter-
rupt endpoint to 64.
The bulk endpoints for alternate setting 2 are identical to alternate setting 1.
The only differences between alternate settings 1 and 2 are the maximum packet sizes for
EP8IN and EP8OUT. This is a high-bandwidth setting using 256 bytes each.
6.1 Introduction
D C D C
A E C A E C
A R A A R A
I D N R Payload I D N R Payload
T C C T C C
N D D C Data N D D C Data
A 1 K A 1 K
R P 5 R P 5
0 6 1 6
Token Packet Data Packet H/S Pkt Token Packet Data Packet H/S Pkt
EZ-USB provides sixteen endpoints for BULK, CONTROL, and INTERRUPT transfers,
numbered 0-7 as shown in Table 6-1. This chapter describes BULK and INTERRUPT
transfers. INTERRUPT transfers are a special case of BULK transfers. EZ-USB CON-
TROL endpoint zero is described in Chapter 7, "EZ-USB Endpoint Zero."
* The highlighted endpoints do not exist in the AN2122 or AN2126. See also Table 1-2.
The 8051 sets fourteen endpoint valid bits (IN07VAL, OUT07VAL registers) at initializa-
tion time to tell the EZ-USB core which endpoints are active. The default CONTROL
endpoint zero is always valid.
Bulk data appears in RAM. Each bulk endpoint has a reserved 64-byte RAM space, a 7-
bit count register, and a 2-bit control and status (CS) register. The 8051 can read one bit of
the CS register to determine endpoint busy, and write the other to force an endpoint
STALL condition.
The 8051 should never read or write an endpoint buffer or byte count register while the
endpoint’s busy bit is set.
When an endpoint becomes ready for 8051 service, the EZ-USB core sets an interrupt
request bit. The EZ-USB vectored interrupt system separates the interrupt requests by
endpoint to automatically transfer control to the ISR (Interrupt Service Routine) for the
endpoint requiring service. Chapter 9, "EZ-USB Interrupts" fully describes this mecha-
nism.
Figure 6-2 illustrates the registers and bits associated with bulk transfers.
IN07IEN 7 6 5 4 3 2 1 0 IN2BC
Interrupt Enable (1=enabled) Byte Count
IN2CS B S IN07IRQ 7 6 5 4 3 2 1 0
OUT07IEN 7 6 5 4 3 2 1 0 OUT4BC
Interrupt Enable (1=enabled) Byte Count
OUT4CS B S OUT07IRQ 7 6 5 4 3 2 1 0
1 2 3 4 5
H D H H D
D C
A E C
A R A
A E C
N ..
... I D N R
T
Payload
C C
I D N R
A
H D H D H
D C
A E C A E C
A R
... I D
N D
N
D
R
C
N
A ... I D N
N D D
R
C
T
Payload
Data
C
A
C
K A 1 K
R P 5 R P 5
0 6
Token Packet H/S Pkt Token Packet Data Packet H/S Pkt
USB bulk IN data travels from device to host. The host requests an IN transfer by issuing
an IN token to the EZ-USB core, which responds with data when it is ready. The 8051
indicates ready by loading the endpoint’s byte count register. If the EZ-USB core receives
an IN token for an endpoint that is not ready, it responds to the IN token with a NAK hand-
shake.
In the bulk IN transfer illustrated in Figure 6-3, the 8051 has previously loaded an end-
point buffer with a data packet, and then loaded the endpoint’s byte count register with the
number of bytes in the packet to arm the next IN transfer. This sets the endpoint’s BUSY
Bit. The host issues an IN token (1), to which the USB core responds by transmitting the
data in the IN endpoint buffer (2). When the host issues an ACK (3), indicating that the
data has been received error-free, the USB core clears the endpoint’s BUSY Bit and sets
its interrupt request bit. This notifies the 8051 that the endpoint buffer is empty. If this is a
multi-packet transfer, the host then issues another IN token to get the next packet.
If the second IN token (4) arrives before the 8051 has had time to fill the endpoint buffer,
the EZ USB core issues a NAK handshake, indicating busy (5). The host continues to send
The only difference between a bulk endpoint and an interrupt endpoint exists in the end-
point descriptor, where the endpoint is identified as type interrupt, and a polling interval is
specified. The polling interval determines how often the USB host issues IN tokens to the
interrupt endpoint.
Suppose 220 bytes are to be transferred to the host using endpoint 2-IN. Further assume
that MaxPacketSize of 64 bytes for endpoint 2-IN has been reported to the host during
enumeration. Because the total transfer size exceeds the maximum packet size, the 8051
divides the 220-byte transfer into four transfers of 64, 64, 64, and 28 bytes.
After loading the first 64 bytes into IN2BUF (at 0x7C00), the 8051 loads the byte count
register IN6BC with the value 64. Writing the byte count register instructs the EZ-USB
core to respond to the next host IN token by transmitting the 64 bytes in the buffer. Until
the byte count register is loaded to arm the IN transfer, any IN tokens issued by the host
are answered by EZ-USB with NAK (Not-Acknowledge) tokens, telling the USB host that
the endpoint is not yet ready with data. The host continues to issue IN tokens to endpoint
2-IN until data is ready for transfer—whereupon the EZ-USB core replaces NAKs with
valid data.
When the 8051 initiates an IN transfer by loading the endpoint’s byte count register, the
EZ-USB core sets a busy bit to instruct the 8051 to hold off loading IN2BUF until the
USB transfer is finished. When the IN transfer is complete and successfully acknowl-
edged, the EZ-USB core resets the endpoint 2-IN busy bit and generates an endpoint 2-IN
interrupt request. If the endpoint 2-IN interrupt is enabled, program control automatically
vectors to the data transfer routine for further action (Autovectoring is enabled by setting
AVEN=1; refer to Chapter 9, "EZ-USB Interrupts").
Initialization Note
When the EZ-USB chip comes out of RESET, or when the USB host issues a bus reset,
the EZ-USB core unarms IN endpoint 1-7 by setting their busy bits to 0. Any IN trans-
fer requests are NAKd until the 8051 loads the appropriate INxBC register(s). The end-
point valid bits are not affected by an 8051 reset or a USB reset. Chapter 10, "EZ-USB
Resets" describes the various reset conditions in detail.
The EZ-USB core takes care of USB housekeeping chores such as handshake verification.
When an endpoint 2-IN interrupt occurs, the user is assured that the data loaded by the
8051 into the endpoint buffer was received error-free by the host. The EZ-USB core auto-
matically checks the handshake information from the host and re-transmits the data if the
host indicates an error by not ACKing.
USB bulk OUT data travels from host to device. The host requests an OUT transfer by
issuing an OUT token to EZ-USB, followed by a packet of data. The EZ-USB core then
responds with an ACK, if it correctly received the data. If the endpoint buffer is not ready
to accept data, the EZ-USB core discards the host’s OUT data and returns a NAK token,
indicating “not ready.” In response, the host continues to send OUT tokens and data to
the endpoint until the EZ-USB core responds with an ACK.
H H D H H D
D C D C
O
A E
D N
C
R
A
Payload
R A O
A E
D N
C
R
A
Payload
R N ..
... U
T
D D C
T
A
Data
C
1
C
K
U
T
D D C
T
A
Data
C
1
A
K .
(OUTnBC loaded,
EPnOUT Interrupt,
OUTnBSY=1)
OUTnBSY=0
4 5 6 7 8 9
H H D H H D
D C D C
.. O
A E
D N
C
R
A
Payload
R N O
A E
D N
C
R
A
Payload
R A
U T C A U T C C
. T
D D
R P
C
5
A
0
Data
1
6
K T
D D
R P
C
5
A
0
Data
1
6
K
Token Packet Data Packet H/S Pkt Token Packet Data Packet H/S Pkt
Each EZ-USB bulk OUT endpoint has a byte count register, which serves two purposes.
The 8051 reads the byte count register to determine how many bytes were received during
the last OUT transfer from the host. The 8051 writes the byte count register (with any
value) to tell the EZ-USB core that is has finished reading bytes from the buffer, making
the buffer available to accept the next OUT transfer. The OUT endpoints come up (after
reset) armed, so the byte count register writes are required only for OUT transfers after the
first one.
In the bulk OUT transfer illustrated in Figure 6-4, the 8051 has previously loaded the end-
point’s byte count register with any value to arm receipt of the next OUT transfer. Loading
the byte count register causes the EZ-USB core to set the OUT endpoint’s busy bit to 1,
indicating that the 8051 should not use the endpoint’s buffer.
The host issues an OUT token (1), followed by a packet of data (2), which the USB core
acknowledges, clears the endpoint’s busy bit and generates an interrupt request (3). This
notifies the 8051 that the endpoint buffer contains valid USB data. The 8051 reads the
endpoint’s byte count register to find out how many bytes were sent in the packet, and
transfers that many bytes out of the endpoint buffer.
In a multi-packet transfer, the host then issues another OUT token (4) along with the next
data packet (5). If the 8051 has not finished emptying the endpoint buffer, the EZ-USB FX
The host continues to send OUT tokens (4, 5, and 6) that are greeted by NAKs until the
buffer is ready. Eventually, the 8051 empties the endpoint buffer data, and then loads the
endpoint’s byte count register (7) with any value to re-arm the USB core. Once armed and
when the next OUT token arrives (8) the USB core accepts the next data packet (9).
The EZ-USB core takes care of USB housekeeping chores such as CRC checks and data
toggle PIDs. When an endpoint 6-OUT interrupt occurs and the busy bit is cleared, the
user is assured that the data in the endpoint buffer was received error-free from the host.
The EZ-USB core automatically checks for errors and requests the host to re-transmit data
if it detects any errors using the built-in USB error checking mechanisms (CRC checks
and data toggles).
Table 6-2. Endpoint Pairing Bits (in the USB PAIR Register)
Bit 5 4 3 2 1 0
Name PR6OUT PR4OUT PR2OUT PR6IN PR4IN PR2IN
Paired 6 OUT 4 OUT 2 OUT 6 IN 4 IN 2 IN
Endpoints 7 OUT 5 OUT 3 OUT 7 IN 5 IN 3 IN
The 8051 sets endpoint pairing bits to 1 to enable double-buffering of the bulk endpoint
buffers. With double buffering enabled, the 8051 can operate on one data packet while
another is being transferred over USB. The endpoint busy and interrupt request bits func-
tion identically, so the 8051 code requires little code modification to support double-buff-
ering.
When an endpoint is paired, the 8051 uses only the even-numbered endpoint of the pair.
The 8051 should not use the paired odd endpoint. For example, suppose it is desired to
Note
Bits 2 and 5 must be set to “0” in the AN2122 and AN2126 devices.
INnBSY=1 indicates that both endpoint buffers are in use, and the 8051 should not load
new IN data into the endpoint buffer. When INnBSY=0, either one or both of the buffers
is available for loading by the 8051. The 8051 can keep an internal count that increments
on EPnIN interrupts and decrements on byte count loads to determine whether one or two
buffers are free. Or, the 8051 can simply check for INnBSY=0 after loading a buffer (and
loading its byte count register to re-arm the endpoint) to determine if the other buffer is
free.
Important Note
If an IN endpoint is paired and it is desired to clear the busy bit for that endpoint, do the
following: (a) write any value to the even endpoint’s byte count register twice, and (b)
clear the busy bit for both endpoints in the pair. This is the only code difference between
paired and unpaired use of an IN endpoint.
OUTnBSY=1 indicates that both endpoint buffers are empty, and no data is available to
the 8051. When OUTnBSY=0, either one or both of the buffers holds USB OUT data.
The 8051 can keep an internal count that increments on EPnOUT interrupts and decre-
ments on byte count loads to determine whether one or two buffers contain data. Or, the
8051 can simply check for OUTnBSY=0 after unloading a buffer (and loading its byte
count register to re-arm the endpoint) to determine if the other buffer contains data.
Table 6-3 shows the RAM locations for the sixteen 64-byte buffers for endpoints 0-7 IN
and OUT. These buffers are positioned at the bottom of the EZ-USB register space so that
any buffers not used for endpoints can be reclaimed as general purpose data RAM. The
top of memory for the 8-KB EZ-USB part is at 0x1B3F. However, if the endpoints are
allocated in ascending order starting with the lowest numbered endpoints, the higher num-
bered unused endpoints can effectively move the top of memory to utilize the unused end-
point buffer RAM as data memory. For example, an application that uses endpoint 1-IN,
Note
AN2122 endpoint memory starts at 0x1C00 and AN2126 endpoint memory starts at
address 0x7C00.
Note
Uploads or Downloads to unused bulk memory can be done only at the Mirrored (low)
addresses shown in Table 6-3.
The EZ-USB core automatically maintains the data toggle bits during bulk, control and
interrupt transfers. As explained in Chapter 1, "Introducing EZ-USB," the toggle bits are
used to detect certain transmission errors so that erroneous data can be re-sent.
In these cases, the 8051 can directly clear the data toggle for each of the bulk/interrupt/
control endpoints, using the TOGCTL register (Figure 6-5).
b7 b6 b5 b4 b3 b2 b1 b0
Note
At the present writing, there appears to be no reason to set a data toggle to DATA1. The
S bit is provided for generality.
To clear an endpoint’s data toggle, the 8051 performs the following sequence:
• Select the endpoint by writing the value 000D0EEE to the TOGCTL register,
where D is the direction and EEE is the endpoint number.
• Clear the toggle bit by writing the value 001D0EEE to the TOGCTL register.
After step 1, the 8051 may read the state of the data toggle by reading the TOGCTL regis-
ter checking bit 7.
The following code illustrates the EZ-USB registers used for a simple bulk transfer. In
this example, 8051 register R1 keeps track of the number of endpoint 2-IN transfers and
register R2 keeps track of the number of endpoint 2-OUT transfers (mod-256). Every
endpoint 2-IN transfer consists of 64 bytes of a decrementing count, with the first byte
replaced by the number of IN transfers and the second byte replaced by the number of
OUT transfers.
For both IN and OUT endpoints, the busy bit is set when the EZ-USB core is using the
buffers, and cleared by loading the endpoint’s byte count register. The byte count value is
meaningful for IN transfers because it tells the EZ-USB core how many bytes to transfer
in response to the next IN token. The 8051 can load any byte count OUT transfers,
because only the act of loading the register is significant—loading OUTnBC arms the
OUT transfer and sets the endpoint’s busy bit.
When an OUT packet arrives in OUT2BUF, the service routine at lines 22-26 increments
R2, loads the byte count (any value) into OUT2BC to re-arm the endpoint (lines 24-25),
and jumps back to the polling routine. This program does not use OUT2BUF data; it sim-
ply counts the number of endpoint 2-OUT transfers.
When endpoint 2-IN is ready for the 8051 to load another packet into IN2BUF, the polling
loop jumps to the endpoint 2-IN service routine at lines 28-39. First, R1 is incremented
(line 29). The data pointer is set to IN2BUF at line 30, and register R1 is loaded into the
first byte of the buffer (lines 31-32). The data pointer is advanced to the second byte of
IN2BUF at line 33, and register R2 is loaded into the buffer (lines 34-35). Finally, the
byte count 40H (64 decimal bytes) is loaded into the byte count register IN2BC to arm the
next IN transfer at lines 36-38, and the routine returns the polling loop.
The code in this example is complete, and runs on the EZ-USB chip. You may be wonder-
ing about the missing step, which reports the endpoint characteristics to the host during the
enumeration process. The reason this code runs without any enumeration code is that the
EZ-USB chip comes on as a fully-functional USB device with certain endpoints already
configured and reported to the host. Endpoint 2 is included in this default configuration.
The full default configuration is described in Chapter 5, "EZ-USB Enumeration and
ReNumeration"
All USB interrupts activate the 8051 INT 2 interrupt. If enabled, INT2 interrupts cause the
8051 to push the current program counter onto the stack, and then execute a jump to loca-
tion 0x43, where the programmer has inserted a jump instruction to the interrupt service
routine (ISR). If the AVEN (Autovector Enable) bit is set, the EZ-USB core inserts a spe-
cial byte at location 0x45, which directs the jump instruction to a table of jump instruc-
tions which transfer control the endpoint-specific ISR.
The byte inserted by the EZ-USB core at address 0x45 depends on which bulk endpoint
requires service. Table 6-5 shows all INT2 vectors, with the bulk endpoint vectors un-
shaded. The shaded interrupts apply to all the bulk endpoints.
Each bulk endpoint interrupt has an associated interrupt enable bit (in IN07IEN and
OUT07IEN), and an interrupt request bit (in IN07IRQ and OUT07IRQ). The interrupt
service routine. IRQ bits are cleared by writing a “1.” Because all USB registers are
accessed using “movx@dptr” instructions, USB interrupt service routines must save and
restore both data pointers, the DPS register, and the accumulator before clearing interrupt
request bits.
Note
Any USB ISR should clear the 8051 INT2 interrupt request bit before clearing any of the
EZ-USB endpoint IRQ bits, to avoid losing interrupts. Interrupts are discussed in more
detail in Chapter 9, "EZ-USB Interrupts."
Individual interrupt request bits are cleared by writing “1” to them to simplify code. For
example, to clear the endpoint 2-IN IRQ, simply write “0000100” to IN07IRQ. This will
not disturb the other interrupt request bits. Do not read the contents of IN07IRQ, logi-
cal-OR the contents with 01, and write it back. This clears all other pending interrupts
because you are writing “1”s to them.
This simple (but fully-functional) example illustrates the bulk transfer mechanism using
interrupts. In the example program, BULK endpoint 6 is used to loop data back to the
host. Data sent by the host over endpoint 2-OUT is sent back over endpoint 2-IN.
This table contains all of the USB interrupts, even though only the jumps for endpoint 2
are used for the example. It is convenient to include this table in any USB application that
uses interrupts. Be sure to locate this table on a page boundary (xx00).
; -----------------
; Interrupt Vectors
; -----------------
org 43h ; int2 is the USB vector
ljmp USB_Jump_Table ; Autovector will replace byte 45
Put it anywhere in memory and the jump table in step 1 will automatically jump to it.
; -----------------------------
; USB Interrupt Service Routine
; -----------------------------
EP2OUT_ISR push dps ; save both dptrs, dps, and acc
push dpl
push dph
push dpl1
push dph1
push acc
mov dptr,#OUT07IRQ
mov a,#01000000b ; a “1” clears the IRQ bit
movx @dptr,a ; clear OUT2 int request
setb got_EP2_data ; set my flag
In this example, the ISR simply sets the 8051 flag “got_EP2_data” to indicate to the back-
ground program that the endpoint requires service. Note that both data pointers and the
DPS (Data Pointer Select) registers must be saved and restored in addition to the accumu-
lator.
Figure 6-10. Background Program Transfers Endpoint 2-OUT Data to Endpoint 2-IN
The main program loop tests the “got_EP2_data” flag, waiting until it is set by the end-
point 2 OUT interrupt service routine in Figure 6-10. This indicates that a new data
packet has arrived in OUT2BUF. Then the service routine is entered, where the flag is
cleared in line 2. The number of bytes received in OUT2BUF is retrieved from the
OUT2BC register (Endpoint 2 Byte Count) and saved in registers R6 and R7 in lines 7-10.
The dual data pointers are initialized to the source (OUT2BUF) and destination (IN2BUF)
buffers for the data transfer in lines 15-18. These labels represent the start of the 64-byte
buffers for endpoint 2-OUT and endpoint 2-IN, respectively. Each byte is read from the
OUT2BUF buffer and written to the IN2BUF buffer in lines 19-25. The saved value of
When the transfer is complete, the program loads the endpoint 2-IN byte count register
IN2BC with the number of loaded bytes (from R6) to arm the next endpoint 2-IN transfer
in lines 29-31. Finally, the 8051 loads any value into the endpoint 2 OUT byte count reg-
ister OUT2BC to arm the next OUT transfer in lines 35-36. Then the program loops back
to check for more endpoint 2-OUT data.
The initialization routine sets the stack pointer, and enables the EZ-USB Autovector by
setting USBBAV.0 to 1. Then it enables the endpoint 2-OUT interrupt, all USB interrupts
(INT2), and the 8051 global interrupt (EA) and finally clears the flag indicating that end-
point 2-OUT requires service.
Once this structure is put into place, it is quite easy to service any or all of the bulk end-
points. To add service for endpoint 2-IN, for example, simply write an endpoint 2-IN
interrupt service routine with starting address EP2IN_ISR (to match the address in the
jump table in step 1), and add its valid and interrupt enable bits to the “init” routine.
The code in this example is complete, and runs on the EZ-USB chip. You may be wonder-
ing about the missing step, which reports the endpoint characteristics to the host during the
enumeration process. The reason this code runs without any enumeration code is that the
EZ-USB chip comes on as a fully-functional USB device with certain endpoints already
configured and reported to the host. Endpoint 2 is included in this default configuration.
The full default configuration is described in Chapter 5, "EZ-USB Enumeration and
ReNumeration"
Portions of the above code are not necessary for the default configuration (such as setting
the endpoint valid bits) but the code is included to illustrate all of the EZ-USB registers
used for bulk transfers.
Bulk endpoint data is available in 64-byte buffers in EZ-USB RAM. In some cases it is
preferable to access bulk data as a FIFO register rather than as a RAM. The EZ-USB core
provides a special data pointer which automatically increments when data is transferred.
Using this Autopointer, the 8051 can access any contiguous block of internal EZ-USB
RAM as a FIFO.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
A7 A6 A5 A4 A3 A2 A1 A0
R/W R/W R/W R/W R/W R/W R/W R/W
x x x x x x x x
b7 b6 b5 b4 b3 b2 b1 b0
D7 D6 D5 D4 D3 D2 D1 D0
The 8051 first loads AUTOPTRH and AUTOPTRL with a RAM address (for example the
address of a bulk endpoint buffer). Then, as the 8051 reads or writes data to the data reg-
ister AUTODATA, the address is supplied by AUTOPTRH/L, which automatically incre-
ments after every read or write to the AUTODATA register. The AUTOPTRH/L registers
may be written or read at anytime. These registers maintain the current pointer address, so
the 8051 can read them to determine where the next byte will be read or written.
As the comment in the penultimate line indicates, the Autopointer saves an “inc dptr”
instruction that would be necessary if one of the 8051 data pointers were used to access
the OUT4BUF RAM data. This improves the transfer time.
Note
Fastest bulk transfer speed in and out of EZ-USB bulk buffers is achieved when the
Autopointer is used in conjunction with the EZ-USB Fast Transfer mode.
• The 8051 sets FBLK=1 in the FASTXFR register, enabling fast bulk transfers,
The 8051 code example in Figure 6-14 shows a transfer loop for moving 64 bytes of exter-
nal FIFO data into the endpoint 4-IN buffer. The FASTXFR register bits are explained in
Chapter 8, "EZ-USB Isochronous Transfers."
This transfer loop takes 19 cycles per loop times 8 passes, or 22 ms (152 cycles). A USB
bulk transfer of 64 bytes takes more that 42 ms (64*8*83 ns) of bus time to transfer the
data bytes to or from the host. This calculation neglects USB overhead time.
From this simple example, it is clear that by using the Autopointer and the EZ-USB Fast
Transfer mode, the 8051 can transfer data in and out of EZ-USB endpoint buffers signifi-
cantly faster than the USB can transfer it to and from the host. This means that the EZ-
USB chip should never be a speed bottleneck in a USB system. It also gives the 8051
ample time for other processing duties between endpoint buffer loads.
The Autopointer can be used to quickly move data anywhere in RAM, not just the bulk
endpoint buffers. For example, it can be used to good effect in an application that calls for
transferring a block of data into RAM, processing the data, and then transferring the data
to a bulk endpoint buffer.
7.1 Introduction
Endpoint Zero has special significance in a USB system. It is a CONTROL endpoint, and
is required by every USB device. Only CONTROL endpoints accept special SETUP
tokens that the host uses to signal transfers that deal with device control. The USB host
sends a repertoire of standard device requests over endpoint zero. These standard requests
are fully defined in Chapter 9 of the USB Specification. This chapter describes how the
EZ-USB chip handles endpoint zero requests.
Because the EZ-USB chip can enumerate without firmware (see Chapter 5, "EZ-USB
Enumeration and ReNumeration"), the EZ-USB core contains logic to perform enumer-
ation on its own. This hardware assist of endpoint zero operations is make available to the
8051, simplifying the code required to service device requests. This chapter deals with
8051 control of endpoint zero (ReNum=1, Chapter 5), and describes EZ-USB resources
such as the Setup Data Pointer that simplify 8051 code that handles endpoint zero
requests.
Endpoint zero is the only CONTROL endpoint in the EZ-USB chip. Although CON-
TROL endpoints are bi-directional, the EZ-USB chip provides two 64-byte buffers,
IN0BUF and OUT0BUF, which the 8051 handles exactly like bulk endpoint buffers for
the data stages of a CONTROL transfer. A second 8-byte buffer, SETUPDAT, which is
unique to endpoint zero, holds data that arrives in the SETUP stage of a CONTROL trans-
fer. This relieves the 8051 programmer of having to keep track of the three CONTROL
transfer phases—SETUP, DATA, and STATUS. The EZ-USB core also generates separate
interrupt requests for the various transfer phases, further simplifying code.
The IN0BUF and OUT0BUF buffers have two special properties that result from being
used by CONTROL endpoint zero:
• Endpoints 0-IN and 0-OUT are always valid, so the valid bits (LSB of IN07VAL
and OUT07VAL registers) are permanently set to 1. Writing any value to these
two bits has no effect, and reading these bits always returns a 1.
• Endpoint 0 cannot be paired with endpoint 1, so there is no pairing bit in the USB-
PAIR register for endpoint 0 or 1.
SETUP Stage
S D C
A E C
E A 8 bytes R A
D N R
T T Setup C C
D D C
U A Data 1 K
R P 5
P 0 6
Token Packet Data Packet H/S Pkt
STATUS Stage
D C D C
A E C S A E C
O A R N O A R A
U
T
D N
D D
R
C
T
A
C
Y
N
A
K
.... U
T
D N
D D
R
C
T
A
C C
1 1 K
R P 5 C R P 5
1 6 1 6
Token Packet Data Pkt H/S Pkt Token Packet Data Pkt H/S Pkt
Figure 7-1. A USB Control Transfer (This One Has a Data Stage)
Endpoint zero accepts a special SETUP packet, which contains an 8-byte data structure
that provides host information about the CONTROL transaction. CONTROL transfers
include a final STATUS phase, constructed from standard PIDs (IN/OUT, DATA1, and
ACK/NAK).
Some CONTROL transactions include all required data in their 8-byte SETUP Data
packet. Other CONTROL transactions require more OUT data than will fit into the eight
bytes, or require IN data from the device. These transactions use standard bulk-like trans-
fers to move the data. Note in Figure 7-1 that the “DATA Stage” looks exactly like a bulk
transfer. As with BULK endpoints, the endpoint zero byte count registers must be loaded
to ACK the data transfer stage of a CONTROL transfer.
The HSNAK bit is used to hold off completing the CONTROL transfer until the device
has had time to respond to a request. For example, if the host issues a Set_Interface
request, the 8051 performs various housekeeping chores such as adjusting internal modes
and re-initializing endpoints. During this time the host issues handshake (STATUS stage)
packets to which the EZ-USB core responds with NAKs, indicating “busy.” When the
8051 completes the desired operation, it sets HSNAK=1 (by writing a “1” to the bit) to ter-
minate the CONTROL transfer. This handshake prevents the host from attempting to use
a partially configured interface.
To perform an endpoint stall for the DATA or STATUS stage of an endpoint zero transfer
(the SETUP stage can never stall), the 8051 must set both the STALL and HSNAK bits for
endpoint zero.
Some CONTROL transfers do not have a DATA stage. Therefore the 8051 code that pro-
cesses the SETUP data should check the length field in the SETUP data (in the 8-byte
buffer at SETUPDAT) and arm endpoint zero for the DATA phase (by loading IN0BC or
OUT0BC) only if the length is non-zero.
Two 8051 interrupts provide notification that a SETUP packet has arrived, as shown in
Figure 7-2.
SETUP Stage
S D C
E
A E C
A 8 bytes R A SETUPDAT
D N R 8 RAM
T T Setup C C
D D C bytes
U A Data 1 K
R P 5
P 0 6
Token Packet Data Packet H/S Pkt
SUTOK SUDAV
Interrupt Interrupt
Figure 7-2. The Two Interrupts Associated with EP0 CONTROL Transfers
The EZ-USB core sets the SUTOKIR bit (SETUP Token Interrupt Request) when the EZ-
USB core detects the SETUP token at the beginning of a CONTROL transfer. This inter-
rupt is normally used only for debug.
The EZ-USB core sets the SUDAVIR bit (Setup Data Available Interrupt Request) when
the eight bytes of SETUP data have been received error-free and transferred to eight EZ-
An 8051 program responds to the SUDAV interrupt request by either directly inspecting
the eight bytes at SETUPDAT or by transferring them to a local buffer for further process-
ing. Servicing the SETUP data should be a high 8051 priority, since the USB Specifica-
tion stipulates that CONTROL transfers must always be accepted and never NAKd. It is
therefore possible that a CONTROL transfer could arrive while the 8051 is still servicing
a previous one. In this case the previous CONTROL transfer service should be aborted
and the new one serviced. The SUTOK interrupt gives advance warning that a new CON-
TROL transfer is about to over-write the eight SETUPDAT bytes.
If the 8051 stalls endpoint zero (by setting the EP0STALL and HSNAK bits to 1), the EZ-
USB core automatically clears this stall bit when the next SETUP token arrives.
Like all EZ-USB interrupt requests, the SUTOKIR and SUDAVIR bits can be directly
tested and reset by the CPU (they are reset by writing a “1”). Thus, if the corresponding
interrupt enable bits are zero, the interrupt request conditions can still be directly polled.
Figure 7-3 shows the EZ-USB registers that deal with CONTROL transactions over EP0.
Interrupt Control
SUDPTRH 15 14 13 12 11 10 9 8
USBIRQ T D
These registers augment those associated with normal bulk transfers over endpoint zero,
which are described in Chapter 6, "EZ-USB Bulk Transfers."
The EZ-USB core transfers the eight SETUP bytes into eight bytes of RAM at SETUP-
DAT. A 16-bit pointer, SUDPTRH/L gives hardware assistance for handling CONTROL
IN transfers, in particular, the USB Get_Descriptor requests described later in this chapter.
The Universal Serial Bus Specification Version 1.1, Chapter 9, "USB Device Framework"
defines a set of Standard Device Requests. When the 8051 is in control (ReNum=1), the
EZ-USB core handles one of these requests (Set Address) directly, and relies on the 8051
to support the others. The 8051 acts on device requests by decoding the eight bytes con-
tained in the SETUP packet. Table 7-1 shows the meaning of these eight bytes.
The Byte column in the previous table shows the byte offset from SETUPDAT. The Field
column shows the different bytes in the request, where the “bm” prefix means bit-map,
“b” means byte, and “w” means word (16 bits). Table 7-2 shows the different values
defined for bRequest, and how the 8051 responds to each request. The remainder of this
chapter describes each of the Table 7-2 requests in detail.
Note
Table 7-2 applies when ReNum=1, which signifies that the 8051, and not the EZ-USB
core, handles device requests. Table 5-2 shows how the core handles each of these
device requests when ReNum=0, for example when the chip is first powered and the
8051 is not running.
In the ReNumerated condition (ReNum=1), the EZ-USB core passes all USB requests
except Set Address onto the 8051 via the SUDAV interrupt. This, in conjunction with the
USB disconnect/connect feature, allows a completely new and different USB device
(yours) to be characterized by the downloaded firmware.
The EZ-USB core implements one vendor-specific request, namely “Firmware Load,”
0xA0. (The bRequest value of 0xA0 is valid only if byte 0 of the request, bmRequest-
Type, is also “x10xxxxx,” indicating a vendor-specific request.) The load request is valid
at all times, so even after ReNumeration the load feature maybe used. If your application
implements vendor-specific USB requests, and you do not wish to use the Firmware Load
feature, be sure to refrain from using the bRequest value 0xA0 for your custom requests.
The Firmware Load feature is fully described in Chapter 5, "EZ-USB Enumeration and
ReNumeration."
Note
To avoid future incompatibilities, vendor requests A0-AF (hex) are reserved by Cypress
Semiconductor.
The USB Specification version 1.0 defines three USB status requests. A fourth request, to
an interface, is indicated in the spec as “reserved.” The four status requests are:
The EZ-USB core activates the SUDAV interrupt request to tell the 8051 to decode the
SETUP packet and supply the appropriate status information.
SETUP Stage
S D C
A E C
E A 8 bytes R A
T
D N R
T Setup C
SETUPDAT
D D C C 8 RAM
U A Data 1 K bytes
R P 5
P 0 6
Token Packet Data Packet H/S Pkt
SUTOK SUDAV
Interrupt Interrupt
DATA Stage
D C
A E C
A R A
I D N R 2
T C C
N D D C Bytes
A 1 K
R P 5
1 6
Token Packet Data Packet H/S Pkt
IN0BUF
64-byte
Buffer
STATUS Stage
D C
A E C
O A R A
D N R
U
D D C
T C C 2 IN0BC
T A 1 K
R P 5
1 6
Token Packet Data Pkt H/S Pkt
The following tables show the eight SETUP bytes for Get_Status requests.
Get_Status-Device queries the state of two bits, Remote Wakeup and Self-Powered. The
Remote Wakeup bit indicates whether or not the device is currently enabled to request
remote wakeup. Remote wakeup is explained in Chapter 11, "EZ-USB Power Manage-
ment." The Self-Powered bit indicates whether or not the device is self-powered (as
opposed to USB bus-powered).
The 8051 returns these two bits by loading two bytes into IN0BUF, and then loading a
byte count of two into IN0BC.
About STALL
The USB STALL handshake indicates that something unexpected has happened. For
instance, if the host requests an invalid alternate setting or attempts to send data to a non-
existent endpoint, the device responds with a STALL handshake over endpoint zero
instead of ACK or NAK.
Stalls are defined for all endpoint types except ISOCHRONOUS, which do not employ
handshakes. Every EZ-USB bulk endpoint has its own stall bit. The 8051 sets the stall
condition for an endpoint by setting the stall bit in the endpoint’s CS register. The host
tells the 8051 to set or clear the stall condition for an endpoint using the Set_Feature/Stall
and Clear_Feature/Stall requests.
An example of the 8051 setting a stall bit would be in a routine that handles endpoint
zero device requests. If an undefined or non-supported request is decoded, the 8051
should stall EP0. (EP0 has a single stall bit because it is a bi-directional endpoint.)
Once the 8051 stalls an endpoint, it should not remove the stall until the host issues a
Clear_Feature/Stall request. An exception to this rule is endpoint 0, which reports a stall
condition only for the current transaction, and then automatically clears the stall condi-
tion. This prevents endpoint 0, the default CONTROL endpoint, from locking out device
requests.
Get_Status/Interface is easy: the 8051 returns two zero bytes through IN0BUF and clears
the HSNAK bit. The requested bytes are shown as “Reserved (Reset to zero)” in the USB
Specification
Set Feature is used to enable remote wakeup or stall an endpoint. No data stage is
required.
The only Set_Feature/Device request presently defined in the USB specification is to set
the remote wakeup bit. This is the same bit reported back to the host as a result of a Get
Status-Device request (Table 7-3). The host uses this bit to enable or disable remote
wakeup by the device.
Data Toggles
The EZ-USB core automatically maintains the endpoint toggle bits to ensure data integ-
rity for USB transfers. The 8051 should directly manipulate these bits only for a very
limited set of circumstances:
• Set_Feature/Stall
• Set_Configuration
• Set_Interface
If the USB device supports remote wakeup (as reported in its descriptor table when the
device is enumerated), the Clear_Feature/Remote Wakeup request disables the wakeup
capability.
The Clear_Feature/Stall removes the stall condition from an endpoint. The 8051 should
respond by clearing the stall bit in the indicated endpoint’s CS register.
During enumeration, the host queries a USB device to learn its capabilities and require-
ments using Get_Descriptor requests. Using tables of descriptors, the device sends back
The EZ-USB core provides a special Setup Data Pointer to simplify 8051 service for
Get_Descriptor requests. The 8051 loads this 16-bit pointer with the beginning address of
the requested descriptor, clears the HSNAK bit (by writing “1” to it), and the EZ-USB
core does the rest.
SETUP Stage
S D C
A E C
E A 8 bytes R A
D N R SETUPDAT
T T Setup C C 8 RAM
D D C
U A Data 1 K bytes
R P 5
P 0 6
Token Packet Data Packet H/S Pkt
SUDAV Interrupt
DATA Stage
D C D C
A E C A E C
A R A A R A
I D N R Payload I D N R Payload
T C C T C C
N D D C Data N D D C Data
A 1 K A 1 K
R P 5 R P 5
1 6 0 6
Token Packet Data Packet H/S Pkt Token Packet Data Packet H/S Pkt
EP0IN EP0IN
Interrupt Interrupt
STATUS Stage SUDPTRH/L
D C
A E C 64 bytes
O A R A
D N R
U T C C
D D C
T A 1 K
R P 5
1 6 27 bytes
Token Packet Data Pkt H/S Pkt
Figure 7-5. Using the Setup Data Pointer (SUDPTR) for Get_Descriptor Requests
Figure 7-5 illustrates use of the Setup Data Pointer. This pointer is implemented as two
registers, SUDPTRH and SUDPTRL. Most Get_Descriptor requests involve transferring
more data than will fit into one packet. In the Figure 7-5 example, the descriptor data con-
sists of 91 bytes.
The usual endpoint zero interrupts, SUDAV and EP0IN, remain active during this auto-
mated transfer. The 8051 normally disables these interrupts because the transfer requires
no 8051 intervention.
As illustrated in Figure 7-5, the 8051 loads the 2-byte SUDPTR with the starting address
of the Device Descriptor table. When SUDPTRL is loaded, the EZ-USB core performs
the following operations:
1. Reads the requested number of bytes for the transfer from bytes 6 and 7 of the
SETUP packet (LenL and LenH in Table 7-11).
2. Reads the requested string’s descriptor to determine the actual string length.
3. Sends the smaller of (a) the requested number of bytes or (b) the actual number of
bytes in the string, over IN0BUF using the Setup Data Pointer as a data table
The Setup Data Pointer can be used for any Get_Descriptor request; for example,
Get_Descriptor-String. It can also be used for vendor-specific requests (that you define),
as long as bytes 6-7 contain the number of bytes in the transfer (for step 1).
It is possible for the 8051 to do manual CONTROL transfers, directly loading the
IN0BUF buffer with the various packets and keeping track of which SETUP phase is in
effect. This would be a good USB training exercise, but not necessary due to the hardware
support built into the EZ-USB core for CONTROL transfers.
For DATA stage transfers of fewer than 64 bytes, moving the data into the IN0BUF buffer
and then loading the EP0INBC register with the byte count would be equivalent to loading
the Setup Data Pointer. However, this would waste 8051 overhead because the Setup Data
Pointer requires no byte transfers into the IN0BUF buffer.
Configuration and string descriptors are handled similarly to device descriptors. The 8051
firmware reads byte 2 of the SETUP data to determine which configuration or string is
being requested, loads the corresponding table pointer into SUDPTRH-L, and the EZ-
USB core does the rest.
The 8051 handles Set_Descriptor requests by clearing the HSNAK bit (by writing “1” to
it), then reading descriptor data directly from the OUT0BUF buffer. The EZ-USB core
keeps track of the number of byes transferred from the host into OUT0BUF, and compares
this number with the length field in bytes 6 and 7. When the proper number of bytes has
been transferred, the EZ-USB core automatically responds to the status phase, which is the
third and final stage of the CONTROL transfer.
Note
The 8051 controls the flow of data in the Data Stage of a Control Transfer. After the
8051 processes each OUT packet, it loads any value into the OUT endpoint’s byte count
register to re-arm the endpoint.
When the host issues the Set_Configuration request, the 8051 saves the configuration
number (byte 2 in Table Table 7-16), performs any internal operations necessary to sup-
port the configuration, and finally clears the HSNAK bit (by writing “1” to it) to terminate
the Set_Configuration CONTROL transfer.
Note
After setting a configuration, the host issues Set_Interface commands to set up the vari-
ous interfaces contained in the configuration.
The 8051 returns the current configuration number. It loads the configuration number into
EP0IN, loads a byte count of one into EP0INBC, and finally clears the HSHAK bit (by
writing “1” to it) to terminate the Set_Configuration CONTROL transfer.
This confusingly named USB command actually sets and reads back alternate settings for
a specified interface.
USB devices can have multiple concurrent interfaces. For example a device may have an
audio system that supports different sample rates, and a graphic control panel that supports
different languages. Each interface has a collection of endpoints. Except for endpoint 0,
which each interface uses for device control, endpoints may not be shared between inter-
faces.
Interfaces may report alternate settings in their descriptors. For example, the audio inter-
face may have setting 0, 1, and 2 for 8-KHz, 22-KHz, and 44-KHz sample rates, and the
panel interface may have settings 0 and 1 for English and Spanish. The Set/Get_Interface
requests select between the various alternate settings in an interface.
Table 7-18. Set Interface (Actually, Set Alternate Setting AS for Interface IF)
Byte Field Value Meaning 8051 Response
0 bmRequestType 0x00 OUT, Device Read and stash byte 2 (AS) for
1 bRequest 0x0B “Set_Interface” Interface IF, change setting for
2 wValueL AS Alt Setting Number Interface IF in firmware
3 wValueH 0x00
4 wIndexL IF For this interface
5 wIndexH 0x00
6 wLengthL 0x00
7 wLengthH 0x00
The 8051 should respond to a Set_Interface request by performing the following steps:
• For an IN endpoint, clear the busy bit for every endpoint in the interface.
• For an OUT endpoint, load any value into the byte count register for every end-
point in the interface.
• Clear the HSNAK bit (by writing “1” to it) to terminate the Set_Feature/Stall
CONTROL transfer.
Table 7-19. Get Interface (Actually, Get Alternate Setting AS for interface IF)
Byte Field Value Meaning 8051 Response
0 bmRequestType 0x81 IN, Device Send AS for Interface IF over
1 bRequest 0x0A “Get_Interface” OUT0BUF (1 byte)
2 wValueL 0x00
3 wValueH 0x00
4 wIndexL IF For this interface
5 wIndexH 0x00
6 wLengthL 1 LenL
7 wLengthH 0 LenH
The 8051 simply returns the alternate setting for the requested interface IF, and clears the
HSNAK bit by writing “1” to it.
When a USB device is first plugged in, it responds to device address 0 until the host
assigns it a unique address using the Set_Address request. The EZ-USB core copies this
device address into the FNADDR (Function Address) register, and subsequently responds
only to requests to this address. This address is in effect until the USB device is
unplugged, the host issues a USB Reset, or the host powers down.
The FNADDR register can be read, but not written by the 8051. Whenever the EZ-USB
core ReNumerates, it automatically resets the FNADDR to zero allowing the device to
come back as new.
An 8051 program does not need to know the device address, because the EZ-USB core
automatically responds only to the host-assigned FNADDR value. The EZ-USB core
makes it readable by the 8051 for debug/diagnostic purposes.
The Sync_Frame request is used to establish a marker in time so the host and USB device
can synchronize multi-frame transfers over isochronous endpoints.
To get in sync, the host issues the Sync_Frame request with EP=EP-OUT (byte 4). The
8051 firmware responds by loading IN0BUF with a two-byte frame count for some future
time; for example, the current frame plus 20. This marks frame “current+20” as the sync
frame, during which both sides will initialize their sequence counters to 1. The 8051 reads
the current frame count in the USBFRAMEL and USBFRAMEH registers.
Multiple isochronous endpoints can be synchronized in this manner. The 8051 keeps sep-
arate internal sequence counts for each endpoint.
The USB endpoint zero protocol provides a mechanism for mixing vendor-specific
requests with the previously described standard device requests. Bits 6:5 of the bmRe-
quest field are set to 00 for a standard device request, and to 10 for a vendor request.
The EZ-USB core responds to two endpoint zero vendor requests, RAM Download and
RAM Upload. These requests are active in all modes (ReNum=0 or 1).
Because bit 7 of the first byte of the SETUP packet specifies direction, only one bRequest
value (0xA0) is required for the upload and download requests. These RAM load com-
mands are available to any USB device that uses the EZ-USB chip.
A host loader program typically writes 0x01 to the CPUCS register to put the 8051 into
RESET, loads all or part of the EZ-USB internal RAM with 8051 code, and finally reloads
the CPUCS register with 0 to take the 8051 out of RESET. The CPUCS register is the
only USB register that can be written using the Firmware Download command.
8.1 Introduction
The EZ-USB chips that support isochronous transfers implement sixteen isochronous end-
points, IN8-IN15 and OUT8-OUT15. 1,024 bytes of FIFO memory may be distributed
over the 16 endpoint addresses. FIFO sizes for the isochronous endpoints are programma-
ble.
(n=8-15)
SOF
USB
USB FIFO OUT
Data
(n=8-15)
SOF
USB
USB FIFO IN
Data
The 8051 reads or writes isochronous data using sixteen FIFO data registers, one per end-
point. These FIFO registers are shown in Figure 8-1 as INnDATA (Endpoint n IN Data)
and OUTnDATA (Endpoint n OUT Data).
The EZ-USB core provides a total of 2,048 bytes of FIFO memory (1,024 bytes, double-
buffered) for ISO endpoints. This memory is in addition to the 8051 program/data mem-
ory, and normally exists outside of the 8051 memory space. The 1,024 FIFO bytes may be
divided among the sixteen isochronous endpoints. The 8051 writes sixteen EZ-USB reg-
isters to allocate the FIFO buffer space to the isochronous endpoints. The 8051 also sets
endpoint valid bits to enable isochronous endpoints.
IN transfers travel from device to host. Figure 8-2 shows the EZ-USB registers and bits
associated with isochronous IN transfers.
IN8ADDR A9 A8 A7 A6 A5 A4 0 0
USBIRQ 7 6 5 4 3 2 1 0
FIFO Start Address (see text)
SOFIR (1=clear request)
USBPAIR 7 6 5 4 3 2 1 0
USBIEN 7 6 5 4 3 2 1 0
SOFIE (1=enabled)
8.2.1 Initialization
• Sets the endpoint’s FIFO size by loading a starting address (Section 8.4, "Setting
Isochronous FIFO Sizes").
• Sets the ISOSEND0 bit in the USBPAIR register for the desired response.
• Enables the SOF interrupt. All isochronous endpoints are serviced in response to
the SOF interrupt.
• The 8051 does not load any bytes to an INnDATA register during the previous
frame, and
If ISOSEND0=0 (the default value), the EZ-USB core does not respond to the IN token.
If ISOSEND0=1, the EZ-USB core sends a zero-length data packet in response to the IN
token. Which action to take depends on the overall system design. The ISOSEND0 bit
applies to all of the isochronous IN endpoints, EP8IN through EP15IN.
When an SOF interrupt occurs, the 8051 is presented with empty IN FIFOs that it fills
with data to be transferred to the host during the next frame. The 8051 has 1 ms to transfer
data into these FIFOs before the next SOF interrupt arrives.
To respond to the SOF interrupt, the 8051 clears the USB interrupt (8051 INT2), and
clears the SOFIR (Start Of Frame Interrupt Request) bit writing a “1” to it. Then, the 8051
loads data into the appropriate isochronous endpoint. The EZ-USB core keeps track of the
number of bytes the 8051 loads to each INnDATA register, and subsequently transfers the
correct number of bytes in response to the USB IN token during the next frame.
The EZ-USB FIFO swap occurs every SOF, even if during the previous frame the host did
not issue an IN token to read the isochronous FIFO data, or if the host encountered an
error in the data. USB isochronous data has no re-try mechanism like bulk data.
OUT transfers travel from host to device. Figure 8-3 shows the EZ-USB registers and bits
associated with isochronous OUT transfers.
OUT15ADDR A9 A8 A7 A6 A5 A4 0 0
USBIRQ 7 6 5 4 3 2 1 0
FIFO Start Address (see text)
SOFIR (1=clear request)
USBIEN 7 6 5 4 3 2 1 0
ISOERR 15 14 13 12 11 10 9 8
8.3.1 Initialization
• Sets the endpoint’s FIFO size by loading a starting address (Section 8.4, "Setting
Isochronous FIFO Sizes").
• Enables the SOF interrupt. All isochronous endpoints are serviced in response to
the SOF interrupt.
When an SOF interrupt occurs, the 8051 is presented with FIFOs containing OUT data
sent from the host in the previous frame, along with 10-bit byte counts, indicating how
many bytes are in the FIFOs. The 8051 has 1 ms to transfer data out of these FIFOs before
the next SOF interrupt arrives.
Sixteen start address registers set the isochronous FIFO sizes (Table 8-1). The EZ-USB
core constructs the address writing the 1,024 byte range from the register value as shown
in Figure 8-4.
Address
A9 A8 A7 A6 A5 A4 0 0 0 0
Register
An 8051 assembler or C compiler may be used to translate FIFO sizes into starting
addresses. The assembler example in Figure 8-5 shows a block of equates for the 16 iso-
chronous FIFO sizes, followed by assembler equations to compute the corresponding
FIFO relative address values. To initialize all sixteen FIFO sizes, the 8051 merely copies
the table starting at 8OUTAD to the sixteen EZ-USB registers starting at OUT8ADDR.
The assembler computes starting addresses in Figure 8-5 by adding the previous end-
point’s address to the desired size shifted right twice. This aligns A9 with bit 7 as shown
in Table 8-1. The LOW operator takes the low byte of the resulting 16 bit expression
The user of this code must ensure that the sizes given in the first equate block are all mul-
tiples of 16. This is easy to tell by inspection—the least significant digit of the hex values
in the first column should be zero.
The amount of data USB can transfer during a 1-ms frame is slightly more than 1,000
bytes per frame (1,500 bytes theoretical, without accounting for USB overhead and bus
utilization). A device’s actual isochronous transfer bandwidth is usually determined by
how fast the CPU can move data in and out of its isochronous endpoint FIFOs.
The 8051 code example in Figure 8-6 shows a typical transfer loop for moving external
FIFO data into an IN endpoint FIFO. This code assumes that the 8051 is moving data
from an external FIFO attached to the EZ-USB data bus and strobed by the RD signal, into
an internal isochronous IN FIFO.
The numbers in parentheses indicate 8051 cycles. One cycle is four clocks, and the EZ-
USB 8051 is clocked at 24 MHz (42 ns). Thus, an 8051 cycle takes 4*42=168 ns, and the
loop takes 9 cycles or 1.5 µs. This loop can transfer about 660 bytes into an IN FIFO
every millisecond (1 ms/1.5 µs).
If more speed is required, the loop can be unrolled by in-line coding the first four instruc-
tions in the loop. Then, a byte is transferred in 6 cycles (24 clocks) which equates to 1 µs
per byte. Using this method, the 8051 could transfer 1,000 bytes into an IN FIFO every
millisecond. In practice, a better solution is to in-line code only a portion of the loop code,
which decreases full in-line performance only slightly and uses far fewer bytes of program
code.
EZ-USB has a special fast transfer mode for applications that use external FIFOs con-
nected to the EZ-USB data bus. These applications typically require very high transfer
speeds in and out of EZ-USB endpoint buffers.
EZ-USB
Registers
(Addressed
DPTR as external
RAM)
Accumulator
The 8051 transfers data to and from EZ-USB registers and RAM using the MOVX (move
external) instruction (Figure 8-7). The 8051 loads one of its two 16-bit data pointers
(DPTR) with an address in RAM, and then executes a MOVX instruction to transfer data
between the accumulator and the byte addressed by DPTR. The “@” symbol indicates
that the address is supplied indirectly, by the DPTR.
The EZ-USB core monitors MOVX transfers between the accumulator and any of the six-
teen isochronous FIFO registers. If an enable bit is set (FISO=1 in the FASTXFR regis-
ter), any read or write to an isochronous FIFO register causes the EZ-USB core to connect
the data to the EZ-USB data bus D[7..0], and generate external read/write strobes. One
MOVX instruction thus transfers a byte of data in or out of an endpoint FIFO and gener-
ates timing strobes for an outside FIFO or memory. The 2-cycle MOVX instruction takes
2 cycles or 333 ns. Figures 8-8 and 8-9 show the data flow for fast writes and reads over
the EZ-USB data bus.
FWR#
External FIFO
or ASIC
D[7..0]
Accumulator
Fast writes are illustrated in Figure 8-8. When the fast mode is enabled, the DPTR points
to an isochronous OUT FIFO register, and the 8051 executes the “movx a,@dptr” instruc-
tion, the EZ-USB core broadcasts the data from the isochronous FIFO to the outside world
via the data bus D[7..0], and generates a Write Strobe FWR# (Fast Write). A choice of
eight waveforms is available for the write strobe, as shown in the next section.
movx @dptr,a
FRD#
External FIFO
or ASIC
D[7..0]
Accumulator
Fast reads are illustrated in Figure 8-9. When the fast mode is enabled, the DPTR points
to an isochronous OUT FIFO register, and the 8051 executes the “movx @dptr,a” instruc-
tion, the EZ-USB core breaks the data path from the accumulator to the IN FIFO register,
and instead writes the IN FIFO using outside data from D[7..0]. The EZ-USB core syn-
chronizes this transfer by generating a FIFO Read Strobe FRD# (Fast Read). A choice of
eight waveform is available for the read strobe, as shown in the next section.
The 8051 sets bits in the FASTXFR register to select the fast ISO and/or fast BULK mode
and to adjust the timing and polarity of the read and write strobes FRD# and FWR#.
b7 b6 b5 b4 b3 b2 b1 b0
Figure 8-10. The FASTXFR Register Controls FRD# and FWR# Strobes
The 8051 sets FISO=1 to select the fast ISO mode and FBLK=1 to select the fast Bulk
mode. The 8051 selects read and write strobe pulse polarities with the RPOL and WPOL
bits, where 0=active low, and 1=active high. Read and write strobe timings are set by
Note
When using the fast transfer feature, be sure to enable the FRD# and FWR# strobe sig-
nals in the PORTACFG register.
tC L
4 1 .6 6 n s
C LK 24
s tre tc h = 0 0 0
D [7 ..0 ] O utput
s tre tc h = 0 0 0
F W R # [0 0 ]
s tre tc h = 0 0 0
F W R # [0 1 ]
s tre tc h = 0 0 0
F W R # [1 0 ]
s tre tc h = 0 0 0
F W R # [1 1 ]
D [7 ..0 ] O u tp ut s tre tc h = 0 0 1
F W R # [0 0 ] s tre tc h = 0 0 1
F W R # [0 1 ] s tre tc h = 0 0 1
F W R # [1 0 ] s tre tc h = 0 0 1
F W R # [1 1 ] s tre tc h = 0 0 1
[n n ] = W M 1 :W M 0 , W P O L = 0
N o te : If W P O L = 1 th e w a v e fo rm s a re in v e rte d
tCL
41.66 ns
OSC24
D[7..0] In
D[7..0] In
D[7..0] In
FRD#[10] stretch=000
FRD#[10] stretch=001
D[7..0] In
FRD#[11] stretch=000
FRD#[11] stretch=001
The timing choices for fast read pulses (FRD#) are shown in Figure 8-12. Read Strobe
waveforms for stretch values of 000 and 001 are indicated. Although two of the read
strobe widths can be extended using stretch values greater than 000, the times that the
input data is sampled by the EZ-USB core remains the same as shown.
FRD# strobes [10] and [11] are typically connected to an external asynchronous FIFO,
where no clock is required. Strobe [10] samples the data at the same time as strobe [11],
but provides a wider pulse width (for stretch=000), which is required by some audio
CODECS. Timing values for these strobe signals are given in Chapter 13, “EZ-USB AC/
DC Parameters.”
The 8051 code example in Figure 8-13 shows a transfer loop for moving external FIFO
data into the endpoint 8-IN FIFO. This code moves data from an external FIFO attached
to the EZ-USB data bus and strobed by the FRD# signal, into the FIFO register IN8DATA
Figure 8-13. 8051 Code to Transfer 640 Bytes of External Data to an Isochronous IN FIFO
This routine uses a combination of in-line and looped code to transfer 640 bytes into the
EP8IN FIFO from an external FIFO. The loop transfers eight bytes in 19 cycles, and it
takes 80 times through the loop to transfer 640 bytes. Therefore, the total transfer time is
80 times 19 cycles, or 1,520 cycles. The 640 byte transfer thus takes 1,520*166 ns or 252
µs, or approximately one-fourth of the 1-ms USB frame time.
Using this routine, the time to completely fill one isochronous FIFO with 1,024 bytes
(assuming all 1,024 isochronous FIFO bytes are assigned to one endpoint) would be 128
If still faster time is required, the routine can be modified to put more of the MOVX
instructions in-line. For example, with 16 in-line MOVX instructions, the transfer time
for 1,024 bytes would be 35 cycles times 64 loops or 2,240 cycles, or 371 µs, an 8% speed
improvement over the eight instruction loop.
Two additional registers, ISOCTL and ZBCOUT, provide additional isochronous endpoint
features.
b7 b6 b5 b4 b3 b2 b1 b0
Bit zero of the ISOCTL register is called ISODISAB. When the 8051 sets ISODISAB=1,
all sixteen of EZ-USB endpoints are disabled. If ISODISAB=1, EP8IN=EP15IN and
EP8OUT-EP15OUT should not be used. ISODISAB is cleared at power-on.
When ISODISAB=1, the 2,048 bytes of RAM normally used for isochronous buffers is
available to the 8051 as XDATA RAM (not program memory), from 0x2000 to 0x27FF in
internal memory. When ISODISAB=1, the behavior of the RD# and WR# strobe signals
changes to reflect the additional 2 KB of memory inside the EZ-USB chip. This is shown
in Table 8-2.
Table 8-2. Addresses for RD# and WR# vs. ISODISAB bit
ISODISAB RD#, WR#
0 2000-7B40,
(default) 8000-FFFF
1 2800-7B40,
8000-FFFF
Caution!
If you use this option, be absolutely certain that the host never sends isochronous data to
your device. Isochronous data directed to a disabled isochronous endpoint system will
cause unpredictable operation.
Note
The Autopointer is not usable from 0x2000-0x27FF (the reclaimed ISO buffer RAM)
when ISODISAB=1.
When the SOF interrupt is asserted, the 8051 normally checks the isochronous OUT end-
point FIFOs for data. Before reading the byte count registers and unloading an isochro-
nous FIFO, the firmware may wish to check for a zero byte count. In this case, the 8051
can check bits in the ZBCOUT register. Any endpoint bit set to “1” indicates that no OUT
bytes were received for that endpoint during the previous frame. Figure 8-15 shows this
register.
b7 b6 b5 b4 b3 b2 b1 b0
The ISOSEND0 bit (bit 7 in the USBPAIR register) is used when the EZ-USB chip
receives an isochronous IN token while the IN FIFO is empty. If ISOSEND0=0 (the
default value) the EZ-USB core does not respond to the IN token. If ISOSEND0=1, the
EZ-USB core sends a zero-length data packet in response to the IN token. Which action to
take depends on the overall system design. The ISOSEND0 bit applies to all of the isoch-
ronous IN endpoints, IN-8 through IN-15.
There is a window of time before and after each SOF (Start of Frame) when accessing the
Isochronous FIFOs will cause data corruption or loss of data.
This is because each isochronous endpoint is actually a pair of FIFOs, and the FIFOs are
swapped at SOF time. The swap occurs about 10 µs before the SOF interrupt signals the
8051 code. (Between SOFs, one FIFO of the pair is accessible to the 8051, while the other
FIFO of the pair transfers data to or from the USB.)
Workaround#1: If you can pre-assemble the data into a buffer, blast the data (in a tight
loop) into the new FIFO just after the SOF interrupt, typically inside the SOF ISR (Inter-
rupt Service Routine).
Workaround#2: If you can’t pre-assemble the data into a buffer, prevent access during
SOFs by setting a time (in the SOF ISR) to time out and halt access just before the next
SOF. Set the timer for about 950 µs (ms minus 50 µs).
Be careful of interrupt latency delaying the timeout ISR. That is, the timeout ISR may be
prevented from halting access by getting preempted by a higher priority interrupt(s), made
worse by the necessary practice of disabling interrupts to manage shared resources,
resources that are shared between the ISRs and background process.
To prevent drift of the timer relative to SOFs, restart the timer after each SOF (typically in
the SOF ISR).
9.1 Introduction
The EZ-USB enhanced 8051 responds to the interrupts shown in Table 9-1. Interrupt
sources that are not present in the standard 8051 are shown as checked in the “New” col-
umn. The three interrupts used by the EZ-USB core are shown in bold type.
The Natural Priority column in Table 9-1 shows the 8051 interrupt priorities. As
explained in Appendix C, the 8051 can assign each interrupt to a high or low priority
group. The 8051 resolves priorities within the groups using the natural priorities.
The EZ-USB core provides three interrupt request types, which are described in the fol-
lowing sections:
Wakeup - After the EZ-USB chip detects USB suspend and the 8051 has entered
its idle state, the EZ-USB core responds to an external signal on its
WAKEUP# pin or resumption of USB bus activity by re-starting the EZ-
USB oscillator and resuming 8051 operation.
Chapter 10, "EZ-USB Resets" describes suspend-resume signaling in detail, along with a
code example that uses the Wakeup interrupt.
Briefly, the USB host puts a device into SUSPEND by stopping bus activity to the device.
When the EZ-USB core detects 3 ms of no bus activity, it activates the USB suspend inter-
rupt request. If enabled, the 8051 takes the suspend interrupt, does power management
housekeeping (shutting down power to external logic), and finishes by setting SFR bit
PCON.0. This signals the EZ-USB core to enter a very low power mode by turning off the
12-MHz oscillator.
When the 8051 sets PCON.0, it enters an idle state. 8051 execution is resumed by activa-
tion of any enabled interrupt. The EZ-USB chip uses a dedicated interrupt for USB
Resume. When external logic pulls WAKEUP# low (for example, when a keyboard key is
pressed or a modem receives a ring signal) or USB bus activity resumes, the EZ-USB core
re-starts the 12-MHz oscillator, allowing the 8051 to recognize the interrupt and continue
executing instructions.
EICON.5
8051
Resume signal "RESUME"
from EZ-USB core S Interrupt
R EICON.4(rd)
EICON.4(0)
Figure 9-1 shows the 8051 SFR bits associated with the RESUME interrupt. The EZ-USB
core asserts the resume signal when the EZ-USB core senses a USB Global Resume, or
when the EZ-USB WAKEUP# pin is pulled low. The 8051 enables the RESUME inter-
rupt by setting EICON.5.
The 8051 reads the RESUME interrupt request bit in EICON.4, and clears the interrupt
request by writing a zero to EICON.4.
Figure 9-2 shows the 21 USB requests that share the 8051 USB (INT2) interrupt. The bot-
tom IRQ, EP7-OUT, is expanded in the diagram to show the logic associated with each
USB interrupt request. Vector 05, not shown in the diagram, exists only in the AN2122/
AN2126, and is described later in this chapter.
EZ-USB 8051
00 SUDAV
01 SOF
02 SUTOK
03 SUSP
04 URES
05 IBN Int
06 EP0-IN
07 EP0-OUT
EIE.0
08 EP1-IN
8051 "USB"
09 EP1-OUT
S Interrupt
0A EP2-IN
0B EP2-OUT R EXIF.4(rd)
0C EP3-IN
EXIF.4(0)
0D EP3-OUT
0E EP4-IN
0F EP4-OUT
10 EP5-IN
11 EP5-OUT
12 EP6-IN
13 EP6-OUT
14 EP7-IN
OUT07IEN.7
15 EP7-OUT S
The EZ-USB core prioritizes the USB interrupts, and constructs an Autovector, which
appears in the AVEC register. The interrupt vector values IV[4..0] are shown to the left of
the interrupt sources (shaded boxes). 00 is the highest priority, 15 is the lowest. If two
USB interrupts occur simultaneously, the prioritization affects which one is first indicated
in the AVEC register. If the 8051 has enabled Autovectoring, the AVEC byte replaces
byte 0x45 in 8051 program memory. This causes the USB interrupt automatically to vec-
tor to different addresses for each USB interrupt source. This mechanism is explained in
detail in Section 9.10, "USB Autovectors."
Due to the OR gate in Figure 9-2, any of the USB interrupt sources sets the 8051 USB
interrupt request latch, whose state appears as an interrupt request in the 8051 SFR bit
EXIF.4. The 8051 enables the USB interrupt by setting SFR bit EIE.0. To clear the USB
interrupt request the 8051 writes a zero to the EXIF.4 bit. Note that this is the opposite of
clearing any of the individual USB interrupt sources, which the 8051 does by writing a “1”
to the IRQ bit.
When a USB resource requires service (for example, a SOF token arrives or an OUT token
arrives on a BULK endpoint), two things happen. First, the corresponding Interrupt
Request Latch is set. Second, a pulse is generated, ORd with the other USB interrupt
logic, and routed to the 8051 INT2 input. The pulse is required because INT2 is edge trig-
gered.
When the 8051 finishes servicing a USB interrupt, it clears the particular IRQ bit by writ-
ing a “1” to it. If any other USB interrupts are pending, the act of clearing the IRQ causes
the EZ-USB core logic to generate another pulse for the highest-priority pending interrupt.
If more that one is pending, they are serviced in the priority order shown in Figure 9-2,
starting with SUDAV (priority 00) as the highest priority, and ending with EP7-OUT (pri-
ority 15) as the lowest.
Important
It is important in any USB Interrupt Service Routine (ISR) to clear the 8051 INT2 inter-
rupt before clearing the particular USB interrupt request latch. This is because as soon
as the USB interrupt is cleared, any pending USB interrupt will pulse the 8051 INT2
input, and if the INT2 interrupt request latch has not been previously cleared the pending
interrupt will be lost.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
Figure 9-4 shows the registers associated with the USB interrupts. Each interrupt source
has an enable (IEN) and a request (IRQ) bit. The 8051 sets the IEN bit to enable the inter-
rupt. The USB core sets an IRQ bit high to request an interrupt, and the 8051 clears an
IRQ bit by writing a “1” to it.
SETUP Stage
S D C
A E C
E A 8 bytes R A
D N R
T T Setup C C
D D C
U A Data 1 K
R P 5
P 0 6
Token Packet Data Packet H/S Pkt
SUTOK SUDAV
Interrupt Interrupt
SUTOK and SUDAV are supplied to the 8051 by EZ-USB CONTROL endpoint zero.
The first portion of a USB CONTROL transfer is the SETUP stage shown in Figure 9-5.
(A full CONTROL transfer is the SETUP stage shown in Figure 7-1.) When the EZ-USB
core decodes a SETUP packet, it asserts the SUTOK (SETUP Token) interrupt request.
After the EZ-USB core has received the eight bytes error-free and copied them into eight
internal registers at SETUPDAT, it asserts the SUDAV interrupt request.
The 8051 program responds to the SUDAV interrupt by reading the eight SETUP data
bytes in order to decode the USB request (Chapter 7, "EZ-USB Endpoint Zero").
The SUTOK interrupt is provided to give advance warning that the eight register bytes at
SETUPDAT are about to be over-written. It is useful for debug and diagnostic purposes.
F C
S
R R
O
N C
F
O 5
Token Pkt
USB Start of Frame interrupt requests occur every millisecond. When the EZ-USB core
receives an SOF packet, it copies the eleven-bit frame number (FRNO in Figure 9-6) into
the USBFRAMEH and USBFRAMEL registers, and activates the SOF interrupt request.
The 8051 services all isochronous endpoint data as a result of the SOF interrupt.
If the EZ-USB detects 3 ms of no bus activity, it activates the SUSP (Suspend) interrupt
request. A full description of Suspend-Resume signaling appears in Chapter 11, "EZ-USB
Power Management."
The USB signals a bus reset by driving both D+ and D- low for at least 10 ms. When the
EZ-USB core detects the onset of USB bus reset, it activates the URES interrupt request.
The remaining 16 USB interrupt requests are indexed to the 16 EZ-USB bulk endpoints.
The EZ-USB core activates a bulk interrupt request when the endpoint buffer requires ser-
vice. For an OUT endpoint, the interrupt request signifies that OUT data has been sent
from the host, validated by the EZ-USB core, and is sitting in the endpoint buffer memory.
For an IN endpoint, the interrupt request signifies that the data previously loaded by the
8051 into the IN endpoint buffer has been read and validated by the host, making the IN
endpoint buffer ready to accept new data.
The USB interrupt is shared by 21 interrupt sources. To save the code and processing time
required to sort out which USB interrupt occurred, the EZ-USB core provides a second
level of interrupt vectoring, called “Autovectoring.” When the 8051 takes a USB inter-
rupt, it pushes the program counter onto its stack, and then executes a jump to address 43,
where it expects to find a jump instruction to an interrupt service routine. The 8051 jump
instruction is encoded as follows:
If Autovectoring is enabled (AVEN=1 in the USBBAV register), the EZ-USB core substi-
tutes its AVEC byte for the byte at address 0x0045. Therefore, if the programmer pre-
loads the high byte (“page”) of a jump table address at location 0x0044, the core-inserted
byte at 0x45 will automatically direct the JUMP to one of 21 addresses within the page. In
the jump table, the programmer then puts a series of jump instructions to each particular
ISR.
1. Insert a jump instruction at 0x43 to a table of jump instructions to the various USB
interrupt service routines.
8051 USB
Interrupt
Vector USB_Jmp_Table:
0043 LJMP 0400
0044 04
0045 (00)2C
USB core
042C LJMP EP2OUT_ISR
AVEC 2C 042D 01
042E 19 EP2OUT_ISR:
0119
Figure 9-7 illustrates an ISR that services endpoint 2-OUT. When endpoint 2-OUT
requires service, the EZ-USB core activates the USB interrupt request, vectoring the 8051
to location 0x43. The jump instruction at this location, which was originally coded as
“LJMP 04-00” becomes “LJMP 04-2C” due to the EZ-USB core substituting 2C as the
Autovector byte for Endpoint 2-OUT (Table 9-3). The 8051 jumps to 042C, where it exe-
cutes the jump instruction to the endpoint 2-OUT ISR shown in this example at address
0119. Once the 8051 takes the vector at 0043, initiation of the endpoint-specific ISR takes
only eight 8051 cycles.
EZ-USB 8051
EIE.1
8051 I2C
DONE Interrupt
S S (INT3)
RD or WR
I2DAT register R R EXIF.5(rd)
I2C Interrupt
Request EXIF.5(0)
I2DAT D7 D6 D5 D4 D3 D2 D1 D0
Chapter 4, "EZ-USB Input/Output" describes the 8051 interface to the EZ-USB I2C con-
troller. The 8051 uses two registers, I2CS (I2C Control and Status) and I2DAT (I2C Data)
to transfer data over the I2C bus. The EZ-USB core signals completion of a byte transfer
by setting the DONE bit (I2CS.0) high, which also sets an I2C interrupt request latch
(Figure 9-8). This interrupt request is routed to the 8051 INT3 interrupt.
The 8051 enables the I2C interrupt by setting EIE.1=1. The 8051 determines the state of
the interrupt request flag by reading EXIF.5, and resets the INT3 interrupt request by writ-
ing a zero to EXIF.5. Any 8051 read or write to the I2DAT or I2CS register automatically
clears the I2C interrupt request.
The EZ-USB family responds to an IN token from the host by loading an IN endpoint
buffer and then arming the endpoint by loading a byte count for the endpoint. After the
host successfully receives the IN data, the 8051 receives an EP-IN interrupt, signifying
that the IN endpoint buffer is once again ready to accept data.
The new interrupt is called “IBN,” for IN Bulk NAK. Its INT2 Autovector is 05, which
was previously reserved in the EZ-USB family.
The IBN interrupt requests and enables are controlled by two new registers. Note that
because the IBN interrupt exists only in the AN2122/AN2126, which has 6 bulk IN end-
points, there are IRQ and IEN bits endpoints IN0 through IN6.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
Each of the individual IN endpoints may be enabled for an IBN interrupt using the IBNEN
register. The 8051 sets an interrupt enable bit to “1” to enable the corresponding interrupt.
The ISR tests the IBNIRQ bits to determine which endpoint or endpoints generated the
interrupt request. As with all other EZ-USB interrupt requests, the 8051 clears an
IBNIRQ bit by writing a “1” to it.
b7 b6 b5 b4 b3 b2 b1 b0
0 0 0 0 0 0 STOPIE 0
R R R R R R R/W R
0 0 0 0 0 0 0 0
The I2C interrupt includes one additional interrupt source in the AN2122/AN2126, a 1-0
transition of the STOP bit. To enable this interrupt, set the STOPIE bit in the I2CMODE
register. The 8051 determines the interrupt source by checking the DONE and STOP bits
in the I2CS register.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
D7 D6 D5 D4 D3 D2 D1 D0
The 8051 concludes I2C transfers by setting the STOP bit (I2CS.6). When the STOP con-
dition has been sent over the I2C bus, the I2C controller resets I2CS.6 to zero. During the
time the I2C controller is generating the stop condition, it ignores accesses to the I2CS and
I2DAT registers. The 8051 code should therefore check the STOP bit for zero before writ-
ing new data to I2CS or I2DAT. In the EZ-USB family, it does this by polling the I2CS.6
bit.
10.1 Introduction
• A Power-On Reset (POR), which turns on the EZ-USB chip in a known state.
RES
8051
Vcc
CPUCS.0
(1 at PWR ON)
RESET RES
EZ-USB Core 24 MHz
USB Bus
Reset
XIN 48 MHz
12
Oscillator PLL ÷2
MHz
XOUT CLK24
When power is first applied to the EZ-USB chip, the external R-C circuit holds the EZ-
USB core in reset until the on-chip PLL stabilizes. The CLK24 pin is active as soon as
power is applied. The 8051 may clear an EZ-USB control bit, CLK24OE, to inhibit the
CLK24 output pin for EMI-sensitive applications that do not need this signal. External
logic can force a chip reset by pulling the RESET pin HI. The RESET pin is normally
The CLK24 signal is active while RESET = HI. When RESET returns LO, the activity on
the CLK24 pin depends on whether or not the EZ-USB chip is in suspend state. If in sus-
pend, CLK24 stops. Resumption of USB bus activity or asserting the WAKEUP# pin LO
re-starts the CLK24 signal.
Power-on default values for all EZ-USB register bits are shown in Chapter 12, "EZ-USB
Registers." Table 10-1 summarizes reset states that affect USB device operation. Note
that the term “Power-On Reset” refers to a reset initiated by application of power, or by
assertion of the RESET pin.
* When the 8051 is released from reset, the EZ-USB automatically arms the Bulk OUT
endpoints by setting their CS registers to 000000010b.
• The 8051 is held in reset, and the CLK24 pin is enabled (3).
• USB interrupts are disabled, and USB interrupt requests are cleared (7-8).
• Bulk IN and OUT endpoints are unarmed, and their stall bits are cleared (9). The
EZ-USB core will NAK IN or OUT tokens while the 8051 is reset. OUT end-
points are enabled when the 8051 is released from reset.
• The ReNum bit is cleared. This means that the EZ-USB core, and not the 8051,
initially responds to USB device requests (12).
• The endpoint valid bits are set to match the endpoints used by the default USB
device (14-17).
The EZ-USB register bit CPUCS.0 resets the 8051. This bit is HI at power-on, initially
holding the 8051 in reset. There are three ways to release the 8051 from reset:
Once enumerated, the host can download code into the EZ-USB RAM using the “Firm-
ware Load” vendor request (Chapter 7, "EZ-USB Endpoint Zero"). The last packet loaded
writes 0 to the CPUCS register, which clears the 8051 RESET bit.
Note
The other bit in the CPUCS register, CLK24OE, is writable only by the 8051, so the host
writing a zero byte to this register does not turn off the CLK24 signal.
Chapter 5 describes the EEPROM boot loads in detail. Briefly, at power-on, the EZ-USB
core checks for the presence of an EEPROM on its I2C bus. If found, it reads the first
EEPROM byte. If it reads 0xB2 as the first byte, the EZ-USB core downloads 8051 code
from the EEPROM into internal RAM. The last byte of a “B2” load writes 0x00 to the
CPUCS register (at 0x7F92), which releases the 8051 from reset.
EZ-USB systems can use external program memory containing 8051 code and USB
device descriptors, which include the VID/DID/PID bytes. Because these systems do no
require and I2C EEPROM to supply the VID/DID/PID, the EZ-USB core automatically
releases 8051 reset when:
The EZ-USB core also sets the ReNum bit to “1,” giving USB control to the 8051.
Once the 8051 is running, the USB host may reset the 8051 by downloading the value
0x01 to the CPUCS register. The host might do this in preparation for loading code over-
lays, effectively magnifying the size of the internal EZ-USB RAM. For such applications
it is important to know the state of the EZ-USB chip during and after an 8051 reset. In this
The basic USB device configuration remains intact through an 8051 reset. Valid end-
points remain valid, the USB function address remains the same, and the IO ports retain
their configurations and values. Stalled endpoints remain stalled, and data toggles don’t
change. The only effects of an 8051 reset are as follows:
• USB interrupts are disabled, but pending interrupt requests remain pending.
• During the 8051 Reset, all bulk endpoints are unarmed, causing the EZ-USB core
to NAK and IN or OUT tokens.
• After the 8051 Reset is removed, the OUT bulk endpoints are automatically
armed. OUT endpoints are thus ready to accept one OUT packet before 8051
intervention is required.
When the 8051 comes out of reset, the pending interrupts are kept pending, but disabled
(1). This gives the firmware writer the choice of acting on pre-8051-reset USB events, or
ignoring them by clearing the pending interrupt(s).
During the 8051 reset time, the EZ-USB core holds off any USB traffic by NAKing IN
and OUT tokens (2). The EZ-USB core automatically arms the OUT endpoints when the
8051 exits the reset state (3).
USBBAV.3, the breakpoint BREAK bit, is cleared (4). The other bits in the USBBAV reg-
ister are unaffected.
The host signals a USB Bus Reset by driving an SE0 state (both D+ and D- data lines low)
for a minimum of 10 ms. The EZ-USB core senses this condition, requests the 8051 USB
Interrupt (INT2), and supplies the interrupt vector for a USB Reset. A USB reset affects
the EZ-USB resources as shown in Table 10-2.
A USB bus reset leaves most EZ-USB resources unchanged. From Table 10-2, after USB
bus reset:
• The EZ-USB core unarms all Bulk IN endpoints (9). Data loaded by the 8051 into
an IN endpoint buffer remains there, and the 8051 firmware can either re-send it by
loading the endpoint byte count register to re-arm the transfer, or send new data by
re-loading the IN buffer before re-arming the endpoint.
• Bulk OUT endpoints retain their busy states (10). Data sent by the host to an OUT
endpoint buffer remains in the buffer, and the 8051 firmware can either read the
data or reject it as stale simply by not reading it. In either case, the 8051 loads a
dummy value to the endpoint byte count register to re-arm OUT transfers.
• Bulk IN endpoints are unarmed, and bulk OUT endpoints are armed (9-10).
Note
The I2C controller is not reset for any of the conditions laid out in Table 10-4. Only the
EZ-USB RESET pin resets it.
11.1 Introduction
The USB host can suspend a device to put it into a power-down mode. When the USB
signals a SUSPEND operation, the EZ-USB chip goes through a sequence of steps to
allow the 8051 to first turn off external power-consuming subsystems, and then enter an
ultra-low-power mode by turning off its oscillator. Once suspended, the EZ-USB chip is
awakened either by resumption of USB bus activity, or by assertion of its WAKEUP# pin.
This chapter describes the suspend-resume mechanism.
12 MHz
WAKEUP pin
START
USB Resume Oscillator
STOP
PLL
48 MHz
Restart
Delay
div by
2
CLK24
PCON.0
Signal
Resume INT 8051 Resume
(USBCS.0)
USB
No USB activity
"SUSPEND"
for 3 msec.
Interrupt
Figure 11-1 illustrates the EZ-USB logic that implements USB suspend and resume.
These operations are explained in the next sections.
EZ-USB TRM v1.9 Chapter 11. EZ-USB Power Management Page 11-1
11.2 Suspend
12 MHz
STOP Oscillator
PLL
48 MHz
div by
2
CLK24
PCON.0
8051
INT2
USB
No USB activity
"SUSPEND"
for 3 msec.
Interrupt
A USB device recognizes SUSPEND as 3 ms of a bus idle (“J”) state. The EZ-USB core
alerts the 8051 by asserting the USB (INT2) interrupt and the SUSPEND interrupt vector.
This gives the 8051 code a chance to perform power SUSPEND interrupt vector. This
gives the 8051 code a chance to perform power conservation housekeeping before shut-
ting down the oscillator.
Page 11-2 Chapter 11. EZ-USB Power Management EZ-USB TRM v1.9
The 8051 code responds to the SUSPEND interrupt by taking the following steps:
2. Sets bit 0 of the PCON SFR (Special Function Register). This has two effects:
• The 8051 enters its idle mode, which is exited by any interrupt.
• The 8051 sends an internal signal to the EZ-USB core which causes it to turn
off the oscillator and PLL.
These actions put the EZ-USB chip into a low-power mode, as required by the USB Spec-
ification.
11.3 Resume
12 MHz
WAKEUP# pin
START
USB Resume Oscillator
PLL
48 MHz
Restart
Delay
div by
2
CLK24
Signal
Resume INT 8051 Resume
(USBCS.0)
EZ-USB TRM v1.9 Chapter 11. EZ-USB Power Management Page 11-3
The EZ-USB oscillator re-starts when:
After an oscillator stabilization time, the EZ-USB core asserts the 8051 Resume interrupt
(Figure 9-1). This causes the 8051 to exit its idle mode. The Resume interrupt is the high-
est priority 8051 interrupt. It is always enabled, unaffected by the EA bit.
The resume ISR clears the interrupt request flag, and executes an “reti” (return from inter-
rupt) instruction. This causes the 8051 to continue program execution at the instruction
following the one that set PCON.0 to initiate the suspend operation.
b7 b6 b5 b4 b3 b2 b1 b0
Two bits in the USBCS register are used for remote wakeup, WAKESRC and SIGR-
SUME.
After exiting the idle state, the 8051 reads the WAKESRC bit in the USBCS register to
discover how the wakeup was initiated. WAKESRC=1 indicates assertion of the
WAKEUP# pin, and WAKESRC=0 indicates a resumption of USB bus activity. The 8051
clears the WAKESRC bit by writing a “1” to it.
Page 11-4 Chapter 11. EZ-USB Power Management EZ-USB TRM v1.9
Note
If your design does not use remote wakeup, tie the WAKEUP# pin high. Holding the
WAKEUP# pin low inhibits the EZ-USB chip from suspending.
When a USB device is suspended, the hub driver is tri-stated, and the bus pullup and pull-
down resistors cause the bus to assume the “J,” or idle state. A suspended device signals a
remote wakeup by asserting the “K” state for 10-15 ms. The 8051 controls this using the
SIGRSUME bit in the USBCS register.
If the 8051 finds WAKESRC=1 after exiting the idle mode, it drives the “K” state for 10-
15 ms to signal the USB remote wakeup. It does this by setting SIGRSUME=1, waiting
10-15 ms, and then setting SIGRSUME=0. When SIGRSUME=0, the EZ-USB bus buffer
reverts to normal operation. The resume routine should also write a “1” to the WAKESRC
bit to clear it.
J and K States
The USB Specification uses differential data signals D+ and D-. Instead of defining a
logical “1” and “0,” it defines the “J” and “K” states. For a high speed device, the “J”
state means (D+ > D-).
The USB Default device does not support remote wakeup. This fact is reported at enu-
meration time in byte 7 of the built-in Configuration Descriptor (Table 5-10).
EZ-USB TRM v1.9 Chapter 11. EZ-USB Power Management Page 11-5
Page 11-6 Chapter 11. EZ-USB Power Management EZ-USB TRM v1.9
12 EZ-USB Registers
12.1 Introduction
This section describes the EZ-USB registers in the order they appear in the EZ-USB mem-
ory map. The registers are named according to the following conventions.
Most registers deal with endpoints. The general register format is DDDnFFF, where:
• BC, BCL, and BCH are byte count registers. BC is used for single byte counts,
and BCL/H are used as the low and high bytes of 16-bit byte counts.
Examples:
• OUT07IRQ is the register containing interrupt request bits for OUT endpoints 0-7.
b7 b6 b5 b4 b3 b2 b1 b0
Figure 12-1 illustrates the register description format used in this chapter.
• The top line shows the register name, functional description, and address in the
EZ-USB memory.
• The third line shows the name of each bit in the register.
• The fifth line shows the default value. These values apply after a Power-On-Reset
(POR).
b7 b6 b5 b4 b3 b2 b1 b0
D7 D6 D5 D4 D3 D2 D1 D0
R/W R/W R/W R/W R/W R/W R/W R/W
x x x x x x x x
Sixteen 64-byte bulk data buffers appear at 0x1B40 and 0x7B40 in the 8K version of EZ-
USB, and only at 0x7B40 in the 32K version of EZ-USB. The endpoints are ordered to
permit the reuse of the buffer space as contiguous RAM when the higher numbered end-
points are not used. These registers default to unknown states.
b7 b6 b5 b4 b3 b2 b1 b0
D7 D6 D5 D4 D3 D2 D1 D0
R R R R R R R R
x x x x x x x x
b7 b6 b5 b4 b3 b2 b1 b0
D7 D6 D5 D4 D3 D2 D1 D0
W W W W W W W W
x x x x x x x x
b7 b6 b5 b4 b3 b2 b1 b0
0 0 0 0 0 0 BC9 BC8
R R R R R R R R
x x x x x x x x
b7 b6 b5 b4 b3 b2 b1 b0
Byte counts are valid only for OUT endpoints. The byte counts indicate the number of
bytes remaining in the endpoint’s Receive FIFO. Every time the 8051 reads a byte from
the ISODATA register, the byte count decrements by one.
To read USB OUT data, the 8051 first reads byte count registers OUTnBCL and OUTn-
BCH to determine how many bytes to transfer out of the OUT FIFO. (The 8051 can also
quickly test ISO output endpoints for zero byte counts using the ZBCOUT register.)
Then, the CPU reads that number of bytes from the ISODATA register. Separate byte
counts are maintained for each endpoint, so the CPU can read the FIFOs in a discontinu-
ous manner. For example, if EP8 indicates a byte count of 100, and EP9 indicates a byte
count of 50, the CPU could read 50 bytes from EP8, then read 10 bytes from EP9, and
resume reading EP8. At this moment the byte count for EP8 would read 50.
There are no byte count registers for the IN endpoints. The USB core automatically tracks
the number of bytes loaded by the 8051.
If the 8051 does not load an IN isochronous endpoint FIFO during a 1-ms frame, and the
host requests data from that endpoint during the next frame (IN token), the USB Core
responds according to the setting of the ISOSEND0 bit (USBPAIR.7). If ISOSEND0=1,
the core returns a zero-length data packet in response to the host IN token. If ISOS-
END=0, the core does not respond to the IN token.
It is the responsibility of the 8051 programmer to ensure that the number of bytes written
to the IN FIFO does not exceed the maximum packet size as reported during enumeration.
b7 b6 b5 b4 b3 b2 b1 b0
This register enables the CLK24 output and permits the host to reset the 8051 using a
Firmware Download.
These register bits define the silicon revision. Consult individual Cypress Semiconductor
data sheets for values.
When this bit is set to 1, the internal 24-MHz clock is connected to the EZ-USB CLK24
pin. When this bit is 0, the CLK24 pin drives HI. This bit can be written by the 8051 only.
The USB host writes “1” to this bit to reset the 8051, and “0” to run the 8051. Only the
USB host can write this bit.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
These three registers control the three IO ports on the EZ-USB chip. They select between
IO ports and various alternate functions. They are read/write by the 8051.
When PORTnCFG=0, the port pin functions as IO, using the OUT, PINS, and OE control
bits. Data written to an OUTn registers appears on an IO Port pin if the corresponding
output enable bit (OEn) is HI.
When PORTnCFG=1, the pin assumes the alternate function shown in Table 12-4 on the
following page.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
The OUTn registers provide the data that drives the port pin when OE=1 and the PORT-
nCFG pin is 0. If the port pin is selected a an input (OE=0), the value stored in the corre-
sponding OUTn bit is stored in an output latch but not used.
b7 b6 b5 b4 b3 b2 b1 b0
R R R R R R R R
x x x x x x x x
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
The PINSn registers contain the current value of the port pins, whether they are selected as
IO ports or alternate functions.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
The OE registers control the output enables on the tri-state drivers connected to the port
pins. When these bits are “1,” the port is an output, unless the corresponding PORTnCFG
bit is set to a “1.”
b7 b6 b5 b4 b3 b2 b1 b0
- - - - - - UART1 UART0
R R R R R R R/W R/W
0 0 0 0 0 0 0 0
These bits, when set to “1,” connect an internal 3.69-MHz clock to UART0 and/or
UART1. The UARTs divide this frequency by 16, giving a 230-KHz baud clock if the cor-
responding SMOD bit is set, or 115 baud clock if the corresponding SMOD bit is clear.
(NOTE: SMOD0 is bit 7 or SFR 0x87, SMOD1 is bit 7 or SFR 0xD8). When the UART0
or UART1 bit is clear, the normal UART clock sources are used.
b7 b6 b5 b4 b3 b2 b1 b0
R R R R R R R R
x x x x x x x x
The ISOERR bits are updated at every SOF. They indicate that a CRC error was received
on a data packet for the current frame. The ISOERR bit status refers to the USB data
received in the previous frame, and which is currently in the endpoint’s OUT FIFO. If the
ISOERR bit = 1, indicating a bad CRC check, the data is still available in the OUTnDATA
register.
b7 b6 b5 b4 b3 b2 b1 b0
This bit indicates the isochronous buffer currently in use by the EZ-USB core. It is used
only for diagnostic purposes.
ISODISAB=1 disables all 16 isochronous endpoints, making the 2,048 bytes of isochro-
nous FIFO memory available as 8051 data memory at 0x2000-0x27FF.
b7 b6 b5 b4 b3 b2 b1 b0
R R R R R R R R
x x x x x x x x
Bits 0-7: EP(n) Zero Byte Count for ISO OUT Endpoints
The 8051 can check these bits as a fast way to check all of the OUT isochronous endpoints
at once for no data received during the previous frame. A “1” in any bit position means
that a zero byte Isochronous OUT packet was received for the indicated endpoint.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
D7 D6 D5 D4 D3 D2 D1 D0
The 8051 uses these registers to transfer data over the EZ-USB I2C bus.
The 8051 sets the START bit to “1” to prepare an I2C bus transfer. If START=1, the next
8051 load to I2DAT will generate the start condition followed by the serialized byte of
data in I2DAT. The 8051 loads byte data into I2DAT after setting the START bit. The I2C
controller clears the START bit during the ACK interval.
The 8051 sets STOP=1 to terminate an I2C bus transfer. The I2C controller clears the
STOP bit after completing the STOP condition. If the 8051 sets the STOP bit during a
byte transfer, the STOP condition will be generated immediately following the ACK phase
of the byte transfer. If no byte transfer is occurring when the STOP bit is set, the STOP
condition will be carried out immediately on the bus. Data should not be written to I2CS
or I2DAT until the STOP bit returns low.
To read data over the I2C bus, an I2C master floats the SDA line and issues clock pulses on
the SCL line. After every eight bits, the master drives SDA low for one clock to indicate
ACK. To signal the last byte of the read transfer, the master floats SDA at ACK time to
instruct the slave to stop sending. This is controlled by the 8051 by setting LastRD=1
before reading the last byte of a read transfer. The I2C controller clears the LastRD bit at
the end of the transfer (at ACK time).
Note
Setting LastRD does not automatically generate a STOP condition. The 8051 should
also set the STOP bit at the end of a read transfer.
These bits are set by the boot loader to indicate whether an 8-bit address or 16-bit address
EEPROM at slave address 000 or 001 was detected at power-on. Normally, they are used
for debug purposes only.
This bit indicates an I2C bus error. BERR=1 indicates that there was bus contention,
which results when an outside device drives the bus LO when it shouldn’t, or when
another bus master wins arbitration, taking control of the bus. BERR is cleared when
8051 reads or writes the IDATA register.
Every ninth SCL or a write transfer the slave indicates reception of the byte by asserting
ACK. The EZ-USB controller floats SDA during this time, samples the SDA line, and
updates the ACK bit with the complement of the detected value. ACK=1 indicates
acknowledge, and ACK=0 indicates not-acknowledge. The EZ-USB core updates the
ACK bit at the same time it sets DONE=1. The ACK bit should be ignored for read trans-
fers on the bus.
The I2C controller sets this bit whenever it completes a byte transfer, right after the ACK
stage. The controller also generates an I2C interrupt request (8051 INT3) when it sets the
DONE bit. The I2C controller automatically clears the DONE bit and the I2C interrupt
request bit whenever the 8051 reads or writes the I2DAT register.
b7 b6 b5 b4 b3 b2 b1 b0
0 0 0 0 0 0 STOPIE 0
R R R R R R R/W R
0 0 0 0 0 0 0 0
The I2C interrupt includes one additional interrupt source in the AN2122/AN2126, a 1-0
transition of the STOP bit. To enable this interrupt, set the STOPIE bit in the I2CMODE
register. The 8051 determines the interrupt source by checking the DONE and STOP bits
in the I2CS register.
b7 b6 b5 b4 b3 b2 b1 b0
IVEC indicates the source of an interrupt from the USB Core. When the USB core gener-
ates an INT2 (USB) interrupt request, it updates IVEC to indicate the source of the inter-
rupt. The interrupt sources are encoded on IV[4..0] as shown in Figure 9-2.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
These interrupt request (IRQ) registers indicate the pending interrupts for each bulk end-
point. An interrupt request (IR) bit becomes active when the BSY bit for an endpoint
makes a transition from one to zero (the endpoint becomes un-busy, giving access to the
8051). The IR bits function independently of the Interrupt Enable (IE) bits, so interrupt
requests are held whether or not the interrupts are enabled.
The 8051 clears an interrupt request bit by writing a “1” to it (see the following Note).
Note
Do not clear an IRQ bit by reading an IRQ register, ORing its contents with a bit mask,
and writing back the IRQ register. This will clear ALL pending interrupts. Instead, sim-
ply write the bit mask value (with the IRQ you want to clear) directly to the IRQ register.
b7 b6 b5 b4 b3 b2 b1 b0
* AN2122/AN2126 only.
USBIRQ indicates the interrupt request status of the USB reset, suspend, setup token, start
of frame, and setup data available interrupts.
This bit is in the AN2122 and AN2126 versions only. The EZ-USB core sets this bit when
any of the IN bulk endpoints responds to an IN token with a NAK. This interrupt occurs
when the host sends an IN token to a bulk IN endpoint which has not been armed by the
8051 writing its byte count register. Individual enables and requests (per endpoint) are
controlled by the IBNIRQ and IBNIEN registers (7FB0, 7FB1).
The EZ-USB core sets this bit to “1” when it detects a USB bus reset.
Because this bit can change state while the 8051 is in reset, it may be active when the 8051
comes out of reset, although it is reset to “0” by a power-on reset. Write a “1” to this bit to
clear the interrupt request. See Chapter 10, "EZ-USB Resets" for more information about
this bit.
The EZ-USB core sets this bit to “1” when it detects USB SUSPEND signaling (no bus
activity for 3 ms). Write a “1” to this bit to clear the interrupt request.
Because this bit can change state while the 8051 is in reset, it may be active when the 8051
comes out of reset, although it is reset to “0” by a power-on reset. See Chapter 11, "EZ-
USB Power Management" for more information about this bit.
The EZ-USB core sets this bit to “1” when it receives a SETUP token. Write a “1” to this
bit to clear the interrupt request. See Chapter 7, "EZ-USB Endpoint Zero" for more infor-
mation on the handling of SETUP tokens.
Because this bit can change state while the 8051 is in reset, it may be active when the 8051
comes out of reset, although it is reset to “0” by a power-on reset.
The EZ-USB core sets this bit to “1” when it receives a SOF packet. Write a “1” to this bit
to clear the interrupt condition.
Because this bit can change state while the 8051 is in reset, it may be active when the 8051
comes out of reset, although it is reset to “0” by a power-on reset.
The EZ-USB core sets this bit to “1” when it has transferred the eight data bytes from an
endpoint zero SETUP packet into internal registers (at SETUPDAT). Write a “1” to this
bit to clear the interrupt condition.
Because this bit can change state while the 8051 is in reset, it may be active when the 8051
comes out of reset, although it is reset to “0” by a power-on reset.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
The Endpoint Interrupt Enable registers define which endpoints have active interrupts.
They do not affect the endpoint action, only the generation of an interrupt in response to
endpoint events.
When the IEN bit for an endpoint is “0,” the interrupt request bit for that endpoint is
ignored, but saved. When the IEN bit for an endpoint is “1,” any IRQ bit equal to “1” gen-
erates an 8051 INT2 request.
Note
The INT2 interrupt (EIE.0) and the 8051 global interrupt enable (EA) must be enabled
for the endpoint interrupts to propagate to the 8051. Once the INT2 interrupt is active, it
must be cleared by software.
b7 b6 b5 b4 b3 b2 b1 b0
* AN2122/AN2126 only.
USBIEN bits gate the interrupt request to the 8051 for USB reset, suspend, SETUP token,
start of frame, and SETUP data available.
This bit is in the AN2122 and AN2126 versions only. The 8051 sets this bit to enable the
IN-bulk-NAK interrupt. This interrupt occurs when the host sends an IN token to a bulk
IN endpoint which has not been armed by the 8051 writing its byte count register. Indi-
vidual enables and requests (per endpoint) are controlled by the IBNIRQ and IBNIEN reg-
isters (7FB0, 7FB1).
This bit is the interrupt mask for the URESIR bit. When this bit is “1,” the interrupt is
enabled, when it is “0,” the interrupt is disabled.
This bit is the interrupt mask for the SUSPIR bit. When this bit is “1,” the interrupt is
enabled, when it is “0,” the interrupt is disabled.
This bit is the interrupt mask for the SUTOKIR bit. When this bit is “1,” the interrupt is
enabled, when it is “0,” the interrupt is disabled.
This bit is the interrupt mask for the SOFIE bit. When this bit is “1,” the interrupt is
enabled, when it is “0,” the interrupt is disabled.
This bit is the interrupt mask for the SUDAVIE bit. When this bit is “1,” the interrupt is
enabled, when it is “0,” the interrupt is disabled.
b7 b6 b5 b4 b3 b2 b1 b0
The BREAK bit is set when the 8051 address bus matches the address held in the bit
breakpoint address registers (next page). The BKPT pin reflects the state of this bit. The
8051 writes a “1” to the BREAK bit to clear it. It is not necessary to clear the BREAK bit
if the pulse mode bit (BPPULSE) is set.
The 8051 sets this bit to “1” to pulse the BREAK bit (and BKPT pin) high for 8 CLK24
cycles when the 8051 address bus matches the address held in the breakpoint address reg-
isters. when this bit is set to “0,” the BREAK bit (and BKPT pin) remains high until it is
cleared by the 8051.
If this bit is “1,” a BREAK signal is generated whenever the 16-bit address lines match the
value in the Breakpoint Address Registers (BPADDRH/L). The behavior of the BREAK
bit and associated BKPT pin signal is either latched or pulsed, depending on the state of
the BPPULSE bit.
If this bit is “1,” the EZ-USB Auto-vector feature is enabled. If it is 0, the auto-vector fea-
ture is disabled. See Chapter 9, "EZ-USB Interrupts" for more information on the auto-
vector feature.
b7 b6 b5 b4 b3 b2 b1 b0
* AN2122/AN2126 only.
These bits are set when a bulk IN endpoint (0-6) received an IN token while the endpoint
was not armed for data transfer. In this case the SIE automatically sends a NAK response,
and sets the corresponding IBNIRQ bit. If the IBN interrupt is enabled (USBIEN.5=1),
and the endpoint interrupt is enabled in the IBNIEN register, an interrupt is request gener-
ated. The 8051 can test the IBNIRQ register to determine which of the endpoints caused
the interrupt. The 8051 clears an IBNIRQ bit by writing a “1” to it.
b7 b6 b5 b4 b3 b2 b1 b0
Each of the individual IN endpoints may be enabled for an IBN interrupt using the IBNEN
register. The 8051 sets an interrupt enable bit to 1 to enable the corresponding interrupt.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
A7 A6 A5 A4 A3 A2 A1 A0
R/W R/W R/W R/W R/W R/W R/W R/W
x x x x x x x x
When the current 16-bit address (code or xdata) matches the BPADDRH/BPADDRL
address, a breakpoint event occurs. The BPPULSE and BPEN bits in the USBBAV regis-
ter control the action taken on a breakpoint event.
If the BPEN bit is “0,” address breakpoints are ignored. If BPEN is “1” and BPPULSE is
“1,” an 8 CLK24 wide pulse appears on the BKPT pin. If BPEN is “1” and BPPULSE is
“0,” the BKPT pin remains active until the 8051 clears the BREAK bit by writing “1” to it.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
These registers control EZ-USB CONTROL endpoint zero. Because endpoint zero is a bi-
directional endpoint, the IN and OUT functionality is controlled by a single control and
status (CS) register, unlike endpoints 1-7, which have separate INCS and OUTCS regis-
ters.
OUTBSY is a read-only bit that is automatically cleared when a SETUP token arrives.
The 8051 sets the OUTBSY bit by writing a byte count to EPOUTBC.
INBSY is a read-only bit that is automatically cleared when a SETUP token arrives. The
8051 sets the INBSY bit by writing a byte count to IN0BC.
If the CONTROL transfer uses an IN data phase, the 8051 loads the requested data into the
IN0BUF buffer, and then loads the byte count into IN0BC to arm the data phase of the
CONTROL transfer. Alternatively, the 8051 can arm the data transfer by loading an
address into the Setup Data Pointer registers SUDPTRH/L. Until armed, the EZ-USB
core will NAK the IN tokens.
HSNAK (Handshake NAK) is a read/write bit that is automatically set when a SETUP
token arrives. The 8051 clears HSNAK by writing a “1” to the register bit.
While HSNAK=1, the EZ-USB core NAKs the handshake (status) phase of the CON-
TROL transfer. When HSNAK=0, it ACKs the handshake phase. The 8051 can clear
HSNAK at any time during a CONTROL transfer.
EP0STALL is a read/write bit that is automatically cleared when a SETUP token arrives.
The 8051 sets EP0STALL by writing a “1” to the register bit.
While EP0STALL=1, the EZ-USB core sends the STALL PID for any IN or OUT token.
This can occur in either the data or handshake phase of the CONTROL transfer.
Note
To indicate an endpoint stall on endpoint zero, set both EP0STALL and HSNAK bits.
Setting the EP0STALL bit alone causes endpoint zero to NAK forever because the host
keeps the control transfer pending.
Endpoints 1-7 IN and OUT are used for bulk or interrupt data. Table 12-5 shows the
addresses for the control/status and byte count registers associated with these endpoints.
The bi-directional CONTROL endpoint zero registers are described in Section 12.12,
"Endpoint 0 Control and Status Registers."
Table 12-5. Control and Status Register Addresses for Endpoints 0-7
Address Function Name
7FB4 Control and Status - Endpoint IN0 EP0CS
7FB5 Byte Count - Endpoint IN0 IN0BC
7FB6 Control and Status - Endpoint IN1 IN1CS
7FB7 Byte Count - Endpoint IN1 IN1BC
7FB8 Control and Status - Endpoint IN2 IN2CS
7FB9 Byte Count - Endpoint IN2 IN2BC
7FBA Control and Status - Endpoint IN3 IN3CS
7FBB Byte Count - Endpoint IN3 IN3BC
7FBC Control and Status - Endpoint IN4 IN4CS
7FBD Byte Count - Endpoint IN4 IN4BC
7FBE Control and Status - Endpoint IN5 IN5CS
7FBF Byte Count - Endpoint IN5 IN5BC
7FC0 Control and Status - Endpoint IN6 IN6CS
7FC1 Byte Count - Endpoint IN6 IN6BC
7FC2 Control and Status - Endpoint IN7 IN7CS
7FC3 Byte Count - Endpoint IN7 IN7BC
7FC4 Reserved
7FC5 Byte Count - Endpoint OUT0 OUT0BC
7FC6 Control and Status - Endpoint OUT1 OUT1CS
7FC7 Byte Count - Endpoint OUT1 OUT1BC
7FC8 Control and Status - Endpoint OUT2 OUT2CS
7FC9 Byte Count - Endpoint OUT2 OUT2BC
7FCA Control and Status - Endpoint OUT3 OU37CS
7FCB Byte Count - Endpoint OUT3 OUT3BC
7FCC Control and Status - Endpoint OUT4 OUT4CS
7FCD Byte Count - Endpoint OUT4 OUT4BC
7FCE Control and Status - Endpoint OUT5 OUT5CS
7FCF Byte Count - Endpoint OUT5 OUT5BC
7FD0 Control and Status - Endpoint OUT6 OUT6CS
7FD1 Byte Count - Endpoint OUT6 OUT6BC
7FD2 Control and Status - Endpoint OUT7 OUT7CS
7FD3 Byte Count - Endpoint OUT7 OUT7BC
b7 b6 b5 b4 b3 b2 b1 b0
- - - - - - INnBSY INnSTL
R R R R R R R/W R/W
0 0 0 0 0 0 0 0
The BSY bit indicates the status of the endpoint’s IN Buffer INnBUF. The EZ-USB core
sets BSY=0 when the endpoint’s IN buffer is empty and ready for loading by the 8051.
The 8051 sets BSY=1 by loading the endpoint’s byte count register.
When BSY=1, the 8051 should not write data to an IN endpoint buffer, because the end-
point FIFO could be in the act of transferring data to the host over the USB. BSY=0 when
the USB IN transfer is complete and endpoint RAM data is available for 8051 access.
USB IN tokens for the endpoint are NAKd while BSY=0 (the 8051 is still loading data
into the endpoint buffer).
A 1-to-0 transition of BSY (indicating that the 8051 can access the buffer) generates an
interrupt request for the IN endpoint. After the 8051 writes the data to be transferred to
the IN endpoint buffer, it loads the endpoint’s byte count register with the number of bytes
to transfer, which automatically sets BSY=1. This enables the IN transfer of data to the
host in response to the next IN token. Again, the CPU should never load endpoint data
while BSY=1.
The 8051 writes a “1” to an IN endpoint busy bit to disarm a previously armed endpoint.
(This sets BSY=0.) The 8051 program should do this only after a USB bus reset, or when
the host selects a new interface or alternate setting that uses the endpoint. This prevents
stale data from a previous setting from being accepted by the host’s first IN transfer that
uses the new setting.
Note:
Even though the register description shows bit 1 as “R/W,” the 8051 can only clear this
bit by writing a “1” to it. The 8051 can not directly set this bit.
To disarm a paired IN endpoint, write a “1” to the busy bit for both endpoints in the pair.
The 8051 sets this bit to “1” to stall an endpoint, and to “0” to clear a stall.
When the stall bit is “1,” the EZ-USB core returns a STALL Handshake for all requests to
the endpoint. This notifies the host that something unexpected has happened.
2. The 8051 encounters any show stopper error on the endpoint, and sets the stall bit
to tell the host to halt traffic to the endpoint.
2. The 8051 receives some other indication from the host that the stall should be
cleared (this is referred to as “host intervention” in the USB Specification). This
indication could be a USB bus reset.
All stall bits are automatically cleared when the EZ-USB chip ReNumerates by pulsing
the DISCON bit HI.
b7 b6 b5 b4 b3 b2 b1 b0
- D6 D5 D4 D3 D2 D1 D0
The 8051 writes this register with the number of bytes it loaded into the IN endpoint
buffer INnBUF. Writing this register also arms the endpoint by setting the endpoint BSY
bit to 1.
Legal values for these registers are 0-64. A zero transfer size is used to terminate a trans-
fer that is an integral multiple of MaxPacketSize. For example, a 256-byte transfer with
maxPacketSize = 64, would require four packets of 64 bytes each plus one packet of 0
bytes.
The IN byte count should never be written while the endpoint’s BUSY bit is set.
When the register pairing feature is used (Section 6, "EZ-USB Bulk Transfers") IN2BC is
used for the EP2/EP3 pair, IN4BC is used for the EP4/EP5 pair, and IN6BC is used for the
EP6/EP7 pair. In the paired (double-buffered) mode, after the first write to the even-num-
bered byte count register, the endpoint BSY bit remains at 0, indicating that only one of
the buffers is full, and the other is still empty. The odd numbered byte count register is not
used when endpoints are paired.
b7 b6 b5 b4 b3 b2 b1 b0
- - - - - - OUTnBSY OUTnSTL
R R R R R R R R/W
0 0 0 0 0 0 0 0
The BSY bit indicates the status of the endpoint’s OUT Buffer OUTnBUF. The EZ-USB
core sets BSY=0 when the host data is available in the OUT buffer. The 8051 sets BSY=1
by loading the endpoint’s byte count register.
When BSY=1, endpoint RAM data is invalid--the endpoint buffer has been emptied by the
8051 and is waiting for new OUT data from the host, or it is the process of being loaded
over the USB. BSY=0 when the USB OUT transfer is complete and endpoint RAM data
in OUTnBUF is available for the 8051 to read. USB OUT tokens for the endpoint are
NAKd while BSY=1 (the 8051 is still reading data from the OUT endpoint).
A 1-to-0 transition of BSY (indicating that the 8051 can access the buffer) generates an
interrupt request for the OUT endpoint. After the 8051 reads the data from the OUT end-
point buffer, it loads the endpoint’s byte count register with any value to re-arm the end-
point, which automatically sets BSY=1. This enables the OUT transfer of data from the
host in response to the next OUT token. The CPU should never read endpoint data while
BSY=1.
The 8051 sets this bit to “1” to stall an endpoint, and to “0” to clear a stall.
When the stall bit is “1,” the EZ-USB core returns a STALL Handshake for all requests to
the endpoint. This notifies the host that something unexpected has happened.
2. The 8051 receives some other indication from the host that the stall should be
cleared (this is referred to as “host intervention” in the USB Specification).
All stall bits are automatically cleared when the EZ-USB chip ReNumerates.
b7 b6 b5 b4 b3 b2 b1 b0
- D6 D5 D4 D3 D2 D1 D0
R R R R R R R R/W
0 0 0 0 0 0 0 0
The 8051 reads this register to determine the number of bytes sent to an OUT endpoint.
Legal sizes are 0 - 64 bytes.
Each EZ-USB bulk OUT endpoint has a byte count register, which serves two purposes.
The 8051 reads the byte count register to determine how many bytes were received during
the last OUT transfer from the host. The 8051 writes the byte count register (with any
value) to tell the EZ-USB core that it has finished reading bytes from the buffer, making
the buffer available to accept the next OUT transfer. Writing the byte count register sets
the endpoint’s BSY bit to “1.”
When the register-pairing feature is used, OUT2BC is used for the EP2/EP3 pair,
OUT4BC is used for the EP4/EP5 pair, and OUT6BC is used for the EP6/EP7 pair. The
odd-numbered byte count registers should not be used. When the 8051 writes a byte to the
even numbered byte count register, the EZ-USB core switches buffers. If the other buffer
already contains data to be read by the 8051, the OUTnBSY bit remains at “0.”
All OUT tokens are NAKd until the 8051 is released from RESET, whereupon the ACK/
NAK behavior is based on pairing.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
A7 A6 A5 A4 A3 A2 A1 A0
R/W R/W R/W R/W R/W R/W R/W R/W
x x x x x x x x
When the EZ-USB chip receives a “Get_Descriptor” request on endpoint zero, it can
instruct the EZ-USB core to handle the multi-packet IN transfer by loading these registers
with the address of an internal table containing the descriptor data. The descriptor data
tables may be placed in internal program/data RAM or in unused Endpoint 0-7 RAM. The
SUDPTR does not operate with external memory. The SUDPTR registers should be
loaded in HIGH/LOW order.
In addition to loading SUDPTRL, the 8051 must also clear the HSNAK bit in the EP0CS
register (by writing a “1” to it) to complete the CONTROL transfer.
Note
Any host request that uses the EZ-USB Setup Data Pointer to transfer IN data must indi-
cate the number of bytes to transfer in bytes 6 (wLenghthL) and 7 (wLengthH) of the
SETUP packet. These bytes are pre-assigned in the USB Specification to be length bytes
in all standard device requests such as “Get_Descriptor.” If vendor-specific requests are
used to transfer large blocks of data using the Setup Data Pointer, they must include this
pre-defined length field in bytes 6-7 to tell the EZ-USB core how many bytes to transfer
using the Setup Data Pointer.
b7 b6 b5 b4 b3 b2 b1 b0
This bit indicates that a high to low transaction was detected on the WAKEUP# pin. Writ-
ing a “1” to this bit resets it to “0.”
The EZ-USB DISCON# pin reflects the complement of this bit. This bit is normally set to
0 so that the action of the DISCOE bit (below) either floats the DISCON# pin or drives it
HI.
DISCOE controls the output buffer on the DISCON# pin. When DISCOE=0, the pin
floats, and when DISCOE=1, it drives to the complement of the DISCON bit (above).
DISCOE is used in conjunction with the RENUM bit to perform ReNumeration (Chap-
ter 5, "EZ-USB Enumeration and ReNumeration").
This bit controls which entity, the USB core or the 8051, handles USB device requests.
When RENUM=0, the EZ-USB core handles all device requests. When RENUM=1, the
8051 handles all device requests except Set_Address.
The 8051 sets RENUM=1 during a bus disconnect to transfer USB control to the 8051.
The EZ-USB core automatically sets RENUM=1 under two conditions:
2. When external memory is used (EA=1) and no boot I2C EEPROM is used (see
Section 10.3.3, "External ROM").
The 8051 sets SIGRSUME=1 to drive the “K” state onto the USB bus. This should be
done only by a device that is capable of remote wakeup, and then only during the SUS-
PEND state. To signal RESUME, the 8051 sets SIGRSUME=1, waits 10-15 ms, then sets
SIGRSUME=0.
b7 b6 b5 b4 b3 b2 b1 b0
Q=0 indicates DATA0 and Q=1 indicates DATA1, for the endpoint selected by the IO and
EP[2..0] bits. The 8051 writes the endpoint select bits (IO and EP[2..0]), before reading
this value.
After selecting the desired endpoint by writing the endpoint select bits (IO and EP[2..0])
the 8051 sets S=1 to set the data toggle to DATA1. The endpoint selection bits should not
be changed while this bit is written.
Note
At this writing there is no known reason to set an endpoint data toggle to 1. This bit is
provided for generality and testing only.
After selecting the desired endpoint by writing the endpoint select bits (IO and EP[2..0])
the 8051 sets R=1 to set the data toggle to DATA0. The endpoint selection bits should not
be changed while this bit is written. For advice on when to reset the data toggle, see Chap-
ter 7, "EZ-USB Endpoint Zero."
The 8051 sets this bit to select an endpoint direction prior to setting its R or S bit. IO=0
selects an OUT endpoint, IO=1 selects an IN endpoint.
The 8051 sets these bits to select an endpoint prior to setting its R or S bit. Valid values
are 0-7 to correspond to bulk endpoints IN0-IN7 and OUT0-OUT7.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
Every millisecond the host sends a SOF token indicating “Start Of Frame,” along with an
11-bit incrementing frame count. The EZ-USB copies the frame count into these registers
at every SOF. One use of the frame count is to respond to the USB SYNC_FRAME
request (Chapter 7, "EZ-USB Endpoint Zero").
If the USB core detects a missing or garbled SOF, it generates an internal SOF and incre-
ments USBFRAMEL-USBRAMEH.
b7 b6 b5 b4 b3 b2 b1 b0
R R R R R R R R
x x x x x x x x
During the USB enumeration process, the host sends a device a unique 7-bit address,
which the EZ-USB core copies into this register. There is normally no reason for the CPU
to know its USB device address because the USB Core automatically responds only to its
assigned address.
Note
During ReNumeration the USB Core sets register to 0 to allow the EZ-USB chip to
respond to the default address 0.
b7 b6 b5 b4 b3 b2 b1 b0
The ISOSEND0 bit is used when the EZ-USB chip receives an isochronous IN token
while the IN FIFO is empty. If ISOSEND0=0 (the default value), the EZ-USB core does
not respond to the IN token. If ISOSEND0=1, the EZ-USB core sends a zero-length data
packet in response to the IN token. Which action to take depends on the overall system
design. The ISOSEND0 bit applies to all of the isochronous IN endpoints, IN8BUF
through IN15BUF.
Set the endpoint pairing bits (PRxOUT) to “1” to enable double-buffering of the bulk
OUT endpoint buffers. With double buffering enabled, the 8051 can operate on one buffer
while another is being transferred over USB. The endpoint busy and interrupt request bits
function identically, so the 8051 code requires no code modification to support double
buffering.
When an endpoint is paired, the 8051 uses only the even-numbered endpoint of the pair.
The 8051 should not use the paired odd endpoint’s IRQ, IEN, VALID bits or the buffer
associated with the odd numbered endpoint.
Set the endpoint pairing bits (PRxIN) to “1” to enable double-buffering of the bulk IN
endpoint buffers. With double buffering enabled, the 8051 can operate on one buffer
while another is being transferred over USB.
When an endpoint is paired, the 8051 should access only the even-numbered endpoint of
the pair. The 8051 should not use the IRQ, IEN, VALID bits or the buffer associated with
the odd numbered endpoint.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
The 8051 sets VAL=1 for any active endpoints, and VAL=0 for inactive endpoints. These
bits instruct the EZ-USB core to return a “no response” if an invalid endpoint is addressed,
instead of a NAK.
The default values of these registers are set to support all endpoints that exist in the default
USB device (see Table 5-1).
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
The 8051 sets VAL=1 for active endpoints, and VAL=0 for inactive endpoints. These bits
instruct the EZ-USB core to return a “no response” if an invalid endpoint is addressed.
The default values of these registers are set to support all endpoints that exist in the default
USB device (see Table 5-1).
b7 b6 b5 b4 b3 b2 b1 b0
The EZ-USB core provides a fast transfer mode that improves the8051 transfer speed
between external logic and the isochronous and bulk endpoint buffers. The FASTXFR
register enables the modes for bulk and/or isochronous transfers, and selects the timing
waveforms for the FRD# and FWR# signals.
The 8051 sets FISO=1 to enable fast isochronous transfers for all16 isochronous endpoint
FIFOs. When FISO=0, fast transfers are disabled for all 16 isochronous endpoints.
The 8051 sets FBLK=1 to enable fast bulk transfers using the Autopointer (see Section
12.16, "SETUP Data") with BULK endpoints. When FBLK=0 fast transfers are disabled
for BULK endpoints.
The 8051 sets RPOL=0 for active-low FRD# pulses, and RPOL=1 for active high FRD#
pulses.
These bits select the phasing and width of the FRD# pulse. See Figure 8-12.
The 8051 sets WPOL=0 for active-low FWR# pulses, and WPOL=1 for active high
FWR# pulses.
These bits select the phasing and width of the FWR# pulse. See Figure 8-11.
b7 b6 b5 b4 b3 b2 b1 b0
b7 b6 b5 b4 b3 b2 b1 b0
A7 A6 A5 A4 A3 A2 A1 A0
R/W R/W R/W R/W R/W R/W R/W R/W
x x x x x x x x
b7 b6 b5 b4 b3 b2 b1 b0
D7 D6 D5 D4 D3 D2 D1 D0
AUTOPTRH/L
The 8051 loads a 16-bit address into the AUTOPTRH/L registers. Subsequent reads or
writes to the AUTODATA register increment the 16-bit value in these registers. The
loaded address must be in internal EZ-USB RAM. The 8051 can read these registers to
determine the address must be in internal EZ-USB RAM. The 8051 can read these regis-
ters to determine the address of the next byte to be accessed via the AUTODATA register.
AUTODATA
8051 data read or written to the AUTODATA register accesses the memory addressed by
the AUTOPTRH/L registers, and increments the address after the read or write.
These registers allow FIFO access to the bulk endpoint buffers, as well as being useful for
internal data movement. Chapter 6, "EZ-USB Bulk Transfers" and Chapter 8, "EZ-USB
Isochronous Transfers" explain how to use the Autopointer for fast transfers to and from
the EZ-USB endpoint buffers.
b7 b6 b5 b4 b3 b2 b1 b0
D7 D6 D5 D4 D3 D2 D1 D0
R R R R R R R R
x x x x x x x x
This buffer contains the 8 bytes of SETUP packet data from the most recently received
CONTROL transfer.
The data in SETUPBUF is valid when the SUDAVIR (Setup Data Available Interrupt
Request) bit is set. The 8051 responds to the SUDAV interrupt by reading the SETUP
bytes from this buffer.
b7 b6 b5 b4 b3 b2 b1 b0
A9 A8 A7 A6 A5 A4 0 0
R/W R/W R/W R/W R/W R/W R/W R/W
x x x x x x x x
b7 b6 b5 b4 b3 b2 b1 b0
A9 A8 A7 A6 A5 A4 0 0
R/W R/W R/W R/W R/W R/W R/W R/W
x x x x x x x x
EZ-USB Isochronous endpoints use a pool of 1,024 double-buffered FIFO bytes. The
1,024 FIFO bytes can be divided between any or all of the isochronous endpoints. The
8051 sets isochronous endpoint FIFO sizes by writing starting addresses to these registers,
starting with address 0. Address bits A3-A0 are internally set to zero, so the minimum
FIFO size is 16 bytes.
See Section 8.8, "Fast Transfer Speed" for details about how to set these registers.
13.1.3 DC Characteristics
EZ-USB TRM v1.9 Chapter 13. EZ-USB AC/DC Parameters Page 13-1
13.1.4 AC Electrical Characteristics
Page 13-2 Chapter 13. EZ-USB AC/DC Parameters EZ-USB TRM v1.9
13.1.8 Data Memory Write
EZ-USB TRM v1.9 Chapter 13. EZ-USB AC/DC Parameters Page 13-3
tCL
CLK24
tAV
A [15.0]
tCD tCD
CS#
tOED tOED
OE#
tWD tWD
WR#
tRD tRD
RD#
tPD tPD
PSEN#
tCL
CLK24
OE#
tAA1 tAH1
tDSU1 tDH1
Page 13-4 Chapter 13. EZ-USB AC/DC Parameters EZ-USB TRM v1.9
tCL
CLK24
RD#
CS#
OE#
tDSU2 tDH2
D [7.0]
tCL
CLK24
CS#
WR#
tAH3
A [15.0]
tDV tDVZ
D [7.0]
EZ-USB TRM v1.9 Chapter 13. EZ-USB AC/DC Parameters Page 13-5
EZ-USB
Fast Transfer Block Diagram
EZ-USB
ASIC
AN2131Q
80 D [7:0] D [7:0]
PQFP
Page 13-6 Chapter 13. EZ-USB AC/DC Parameters EZ-USB TRM v1.9
tCL
CLK24
tDSU4 tDH4
Input
D[7..0]
tCRO
FRD#[00]
tCL
CLK24
tCDO tCDO
D[7..0] Output
tCWO tCWO
FWR#[00]
EZ-USB TRM v1.9 Chapter 13. EZ-USB AC/DC Parameters Page 13-7
tCL
CLK24
tDSU4 tDH4
Input
D[7..0]
tCRO
FRD#[01]
tCL
CLK24
tCDO tCDO
D[7..0] Output
tCWO tCWO
FWR#[01]
tPFWD
Page 13-8 Chapter 13. EZ-USB AC/DC Parameters EZ-USB TRM v1.9
tCL
CLK24
tDSU4 tDH4
Input
D[7..0]
tCRO
FRD#[10]
tCL
CLK24
tCDO tCDO
D[7..0] Output
tCWO tCWO
FWR#[10]
EZ-USB TRM v1.9 Chapter 13. EZ-USB AC/DC Parameters Page 13-9
tCL
CLK24
tDSU4 tDH4
Input
D[7..0]
tCRO
FRD#[11]
tCL
CLK24
tCDO tCDO
D[7..0] Output
tCWO tCWO
FWR#[11]
tPFWD
Page 13-10 Chapter 13. EZ-USB AC/DC Parameters EZ-USB TRM v1.9
14 EZ-USB Packaging
13.45
12.95
10.10
9.90
8.00 REF
44 34
1 33
0.80 BSC.
11 23
12 22
2.35 MAX
0.45
0.30
0o~7o 0.23
0.13
0.25
0.10 0.95
0.65
1.60 TYP
24.10
23.70
20.05
19.95
0.80
64 41
65
3.0
40
0.80 BSC.
18.10 14.05 3.0
80 25
1 24
1.00 Ref
See Lead
Detail
3.04 MAX
0.42
0.32
0o~10o
0o~7o
Base Plane
Seating Plane
0.28
0.18 1.00
0.80
1.95 + 0.15
Detail "A"
S ee L ea d
D e ta il
1 .60 M A X
0 .2 7
AL L D IM EN S IO N S IN M IL L IM ET ER S .
0 .1 7
9 .0 0 B S C .
7 .0 0
BSC.
48 37
1 36
0 .5 0 B S C .
48 T Q F P
12 25
13 24
AL L D IM EN S IO N S IN M IL L IM ET ER S .
Base Plane
Seating Plane
0.05 0.08 R .
0.15 M IN .
0 - 7o
0.20 M IN .
0.45
0.75
AL L D IM E N S IO N S IN M ILLIM E T ER S. 1.00 REF.
Table of Contents
Table A-1. Feature Summary of 8051 Core and Common 803x/805x Configurations A-4
Table B-1. Legend for Instruction Set Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-4
Table B-2. 8051 Instruction Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-5
Table B-3. Data Memory Stretch Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-11
Table B-4. Special Function Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-13
Table B-5. Special Function Register Reset Values . . . . . . . . . . . . . . . . . . . . . . . . . B-14
Table B-6. PSW Register - SFR D0h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16
Table C-1. Timer/Counter Implementation Comparison . . . . . . . . . . . . . . . . . . . . . . C-2
Table C-2. TMOD Register - SFR 89h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-4
Table C-3. TCON Register - SRF 88h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-5
Table C-4. CKCON Register - SRF 8Eh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-8
Table C-5. Timer 2 Mode Control Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-9
Table C-6. T2CON Register - SFR C8h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-10
Table C-7. Serial Port Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-14
Table C-8. SCON0 Register - SFR 98h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-15
Table C-9. SCON1 Register - SFR C0h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-16
Table C-10. Timer 1 Reload Values for Common Serial Port Mode 1 Baud Rates . C-20
Table C-11. Timer 2 Reload Values for Common Serial port Mode 1 Baud Rates . . C-21
Table C-12. IE Register - SFR A8h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-28
Table C-13. IP Register - SFR B8h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-29
Table C-14. EXIF Register - SFR 91h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-30
Table C-15. EICON Register - SFR D8h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-31
Table C-16. EIE Register - SFR E8h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-32
Table C-17. EIP Register - SFR F8h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-33
Table C-18. Interrupt Natural Vectors and Priorities . . . . . . . . . . . . . . . . . . . . . . . . . C-34
Table C-19. Interrupt Flags, Enables, and Priority Control . . . . . . . . . . . . . . . . . . . . C-35
Table C-20. PCON Register - SFR 87h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-37
A.1 Introduction
The EZ-USB contains an 8051 core that is binary compatible with the industry standard 8051
instruction set. This appendix provides an overview of the 8051 core features. the topics are:
• New 8051 Features
• Performance Overview
• Software Compatibility
• 803x/805x Feature Comparison
• 8051/DS80C320 Differences
The 8051 core provides the following design features and enhancements to the standard 8051
micro-controller:
• Compatible with industry standard 803x/805x:
- Standard 8051 instruction set
- Two full-duplex serial ports
- Three timers
• High speed architecture:
- 4 clocks/instruction cycle
- 2.5X average improvement in instruction execution time over the standard 8051
- Runs DC to 25-MHz clock
- Wasted bus cycles eliminated
- Dual data pointers
• 256 Bytes internal data RAM
• High-speed external memory interface with 16-bit address bus
• Variable length MOVX to access fast/slow RAM peripherals
• Fully static synchronous design
• Supports industry standard compilers, assemblers, emulators, and ROM monitors
The 8051 core has been designed to offer increased performance by executing instructions in a
4-clock bus cycle, as opposed to the 12-clock bus cycle in the standard 8051 (see Figure A-1.).
The shortened bus timing improves the instruction execution rate for most instructions by a
factor of three over the standard 8051 architectures.
Some instructions require a different number of instruction cycles on the 8051 core than they
do on the standard 8051. In the standard 8051, all instructions except for MUL and DIV take
one or two instruction cycles to complete. In the 8051 core, instructions can take between one
and five instruction cycles to complete. The average speed improvement for the entire
instruction set is approximately 2.5X, calculated as follows:
150 3.0X
51 1.5X
43 2.0X
2 2.4X
ALE
PSEN#
AD0-AD7
PORT2
4
XTAL1
12
ALE
PSEN#
AD0-AD7
PORT2
The 8051 core is object code compatible with the industry standard 8051 micro-controller.
That is, object code compiled with an industry standard 8051 compiler or assembler will
execute on the 8051 core and will be functionally equivalent. However, because the 8051 core
uses a different instruction timing than the standard 8051, existing code with timing loops
may require modification.
The “Instruction Set” in Table B-2 on page B-5 lists the number of instruction cycles required
to perform each instruction on the 8051 core. The 8051 instruction cycle timing and number
of instruction cycles required for each instruction are compatible with the Dallas
Semiconductor DS80C320.
Table A-1. provides a feature-by-feature comparison of the 8051 core and several common
803x/805x configurations.
Table A-1. Feature Summary of 8051 Core and Common 803x/805x Configurations
Intel
Dallas Anchor
Feature
DS80C320 8051
8031 8051 80C32 80C52
Internal RAM 128 bytes 128 bytes 256 bytes 256 bytes 256 bytes 256 bytes
Data Pointers 1 1 1 1 2 2
Serial Ports 1 1 1 1 2 2
16-bit Timers 2 2 3 3 3 3
The 8051 core is similar to the DS80C320 in terms of hardware features and instruction cycle
timing. However, there are some important differences between the 8051 core and the
DS80C320.
The 8051 core does not implement serial port framing error detection and does not implement
slave address comparison for multiprocessor communications. Therefore, the 8051 core also
does not implement the following SFRs: SADDR0, SADDR1, SADEN0, and SADEN1.
A.6.2 Timer 2
The 8051 core does not implement Timer 2 downcounting mode or the downcount enable bit
(TMOD2, bit 0). Also, the 8051 core does not implement Timer 2 output enable (T2OE) bit
(TMOD2, bit 1). Therefore, the TMOD2 SFR is also not implemented in the 8051 core.
Also, the 8051 core Timer 2 overflow output is active for one clock cycle. In the DS80C320,
the Timer 2 overflow output is a square wave with a 50% duty cycle.
The 8051 core does not implement timed access protection and therefore, does not implement
the TA SFR.
B.1 Introduction
This appendix provides a technical overview and description of the 8051 core architecture.
PC4/TO, PC5/T1
8051
PA0/t0_out,
PA1/t0_out
8051_cpu PB0/T2
8051_ram_128 8051_timer 8051_timer2
Timer 2 PB1/t2ex
Timers 0 and 1
PB7/t2out
(80..FFh indirect)
8051_ram_128
(lower 128 Byte RAM)
(0..7Fh direct/indirect)
8051_serial PC1/TxD0
8051_intr_0 PC0/rxd0in
or Serial Port 0 PA6/rxd0out
8051_alu 8051_intr_1
Interrupt Unit
8051_serial PB3/txd1
8051_ PB2/rxd1in
8051_control main_regs Serial Port 1 PA7/rxd1out
interrupts
8051_biu
port_control
A15-A0
D7 - D0
8051_op_decoder CLK24
RESET#
Memory organization in the 8051 core is similar to that of the industry standard 8051. There
are three distinct memory areas: program memory (ROM), data memory (external RAM), and
registers (internal RAM).
The EZ-USB provides 8K of data that is mapped as both program and data memory at
addresses 0x0000-0x1B3F. In addition, the bulk endpoint buffers may be used as external data
memory if they are not used as endpoint buffers. See Chapter 3, "EZ-USB Memory" for more
details.
The EZ-USB chip has dedicated address and data pins, so port 2 and port 0 are not used to
access the memory bus. As shown in Chapter 3, "EZ-USB Memory", the EZ-USB is
expandable to over 100K of external program and data memory.
All 8051 instructions are binary code compatible and perform the same functions as they do
with the industry standard 8051. The effects of these instructions on bits, flags, and other
status functions is identical to the industry standard 8051. However, the timing of the
instructions is different, both in terms of number of clock cycles per instruction cycle and
timing within the instruction cycle.
Figure B-2 lists the 8051 instruction set and the number of instruction cycles required to
complete each instruction. Table B-1. defines the symbols and mnemonics used in Table B-2.
FFh FFh
Direct RAM
Upper 128
bytes SFR space
30h (optional)
Bank 2Fh 7F ... 78
Select . 80h 80h
Bit-Addressable
. 7Fh
(PSW bits
Registers
.
4,3)
Lower 128 Direct addressing only
... 00
20h 07 bytes
1Fh Bank 3
11 18h
17h 00h
10 Bank 2
10h
0Fh Direct or indirect addressing
01 Bank 1
08h
07h
00 Bank 0
00h
Symbol Function
A Accumulator
Rn Register R7–R0
Instr. Hex
Mnemonic Description Byte
Cycles Code
Arithmetic
INC A increment A 1 1 04
DEC A Decrement A 1 1 14
MUL AB Multiply A by B 1 5 A4
DIV AB Divide A by B 1 5 84
DA A Decimal adjust A 1 1 D4
Instr. Hex
Mnemonic Description Byte
Cycles Code
Logical
CLR A Clear A 1 1 E4
CPL A Complement A 1 1 F4
RL A Rotate A left 1 1 23
Instr. Hex
Mnemonic Description Byte
Cycles Code
Data Transfer
Instr. Hex
Mnemonic Description Byte
Cycles Code
* Number of cycles is user-selectable. See “Stretch Memory Cycles (Wait States)” on page B-10.
Boolean
Branching
Instr. Hex
Mnemonic Description Byte
Cycles Code
CJNE Rn, #d, rel Compare reg, immediate JNE relative 3 4 B8-BF
CJNE @ Ri, #d, rel Compare Ind, immediate JNE relative 3 4 B6-B7
Miscellaneous
NOP No operation 1 1 00
There is an additional reserved opcode (A5) that performs the same function as NOP. All mnemonics
are copyrighted. Intel Corporation 1980.
Instruction cycles in the 8051 core are 4 clock cycles in length, as opposed to the 12 clock
cycles per instruction cycle in the standard 8051. This translates to a 3X improvement in
execution time for most instructions.
Some instructions require a different number of instruction cycles on the 8051 core than they
do on the standard 8051. In the standard 8051, all instructions except for MUL and DIV take
one or two instruction cycles to complete. In the 8051 core, instructions can take between one
and five instruction cycles to complete.
For example, in the standard 8051, the instructions MOVX A, @DPTR and MOV direct,
direct each take 2 instruction cycles (24 clock cycles) to execute. In the 8051 core, MOVX
A, @DPTR takes two instruction cycles (8 clock cycles) and MOV direct, direct takes
three instruction cycles (12 clock cycles). Both instructions execute faster on the 8051 core
than they do on the standard 8051, but require different numbers of clock cycles.
For timing of real-time events, use the numbers of instruction cycles from Table B-1. to
calculate the timing of software loops. The bytes column indicates the number of memory
As previously stated, an 8051 core instruction cycle consists of 4 CLK24 cycles. Each CLK24
cycle forms a CPU cycle. Therefore, an instruction cycle consists of 4 CPU cycles: C1, C2, C3,
and C4, as illustrated in Figure B-3. Various events occur in each CPU cycle, depending on the
type of instruction being executed. The labels C1, C2, C3, and C4 in timing descriptions refer to
the 4 CPU cycles within a particular instruction cycle.
The execution for instruction n is performed during the fetch of instruction n+1. Data writes
occur during fetch of instruction n+2. The level sensitive interrupts are sampled with the rising
edge of CLK24 at the end of C3.
CLK24
Instruction cycle n+1 n+2
CPU cycle C1 C2 C3 C4 C1 C2 C3 C4 C1
The stretch memory cycle feature enables application software to adjust the speed of data
memory access. The 8051 core can execute the MOVX instruction in as few as 2 instruction
cycles. However, it is sometimes desirable to stretch this value; for example to access slow
memory or slow memory-mapped peripherals such as UARTs or LCDs.
The three LSBs of the Clock Control Register (at SFR location 8Eh) control the stretch value.
You can use stretch values between zero and seven. A stretch value of zero adds zero instruction
cycles, resulting in MOVX instructions executing in two instruction cycles. A stretch value of
seven adds seven instruction cycles, resulting in MOVX instructions executing in nine instruction
cycles. The stretch value can be changed dynamically under program control.
Read/Write
Memory Strobe Width
MD2 MD1 MD0 Strobe Width
Cycles @ 24MHz
(Clocks)
0 0 0 2 2 83.3 ns
0 0 1 3 (default) 4 166.7 ns
0 1 0 4 8 333.3 ns
0 1 1 5 12 500 ns
1 0 0 6 16 666.7 ns
1 0 1 7 20 833.3 ns
1 1 0 8 24 1000 ns
1 1 1 9 28 1166.7 ns
The 8051core employs dual data pointers to accelerate data memory block moves. The
standard 8051 data pointer (DPTR) is a 16-bit value used to address external data RAM or
peripherals. The 8051 maintains the standard data pointer as DPTR0 at SFR locations 82h
(DPL0) and 83h (DPH0). It is not necessary to modify existing code to use DPTR0.
The 8051 core adds a second data pointer (DPTR1) at SFR locations 84h (DPL1) and 85h
(DPH1). The SEL bit in the DPTR Select register, DPS (SFR 86h), selects the active pointer.
When SEL = 0, instructions that use the DPTR will use DPL0 and DPH0. When SEL = 1,
instructions that use the DPTR will use DPL1 and DPH1. SEL is the bit 0 of SFR location
86h. No other bits of SFR location 86h are used.
The Special Function Registers (SFRs) control several of the features of the 8051. Most of the
8051 core SFRs are identical to the standard 8051 SFRs. However, there are additional SFRs
that control features that are not available in the standard 8051.
Table B-4. lists the 8051 core SFRs and indicates which SFRs are not included in the standard
8051 SFR space.
In Table B-5., SFR bit positions that contain a 0 or a 1 cannot be written to and, when read,
always return the value shown (0 or 1). SFR bit positions that contain “-” are available but not
used. Table B-5. lists the reset values for the SFRs.
The following SFRs are related to CPU operation and program execution:
81h SP Stack Pointer
D0h PSW Program Status Word ()
E0h ACC Accumulator Register
F0h B B Register
Table B-6. lists the functions of the bits in the PSW SFR. Detailed descriptions of the
remaining SFRs appear with the associated hardware descriptions in Appendix C of this
databook.
Register Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Addr
SP 81h
DPL0 82h
DPH0 83h
DPL1(1) 84h
DPH1(1) 85h
TCON TF1 TR1 TF0 TR0 IE1 IT1 IE0 IT0 88h
TL0 8Ah
TL1 8Bh
TH0 8Ch
TH1 8Dh
MPAGE(1) 92h
SCON0 SM0_0 SM1_0 SM2_0 REN_0 TB8_0 RB8_0 TI_0 RI_0 98h
SBUF0 99h
SCON1(1) SM0_1 SM1_1 SM2_1 REN_1 TB8_1 RB8_1 TI_1 RI_1 C0h
SBUF1(1) C1h
T2CON TF2 EXF2 RCLK TCLK EXEN2 TR2 C/T2 CP/RL2 C8h
RCAP2L CAh
RCAP2H CBh
TL2 CCh
Register Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Addr
TH2 CDh
ACC E0H
B F0h
Register Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Addr
SP 0 0 0 0 0 1 1 1 81h
DPL0 0 0 0 0 0 0 0 0 82h
DPH0 0 0 0 0 0 0 0 0 83h
DPL1(1) 0 0 0 0 0 0 0 0 84h
DPH1(1) 0 0 0 0 0 0 0 0 85h
DPS(1) 0 0 0 0 0 0 0 0 86h
PCON 0 0 1 1 0 0 0 0 87h
TCON 0 0 0 0 0 0 0 0 88h
TMOD 0 0 0 0 0 0 0 0 89h
TL0 0 0 0 0 0 0 0 0 8Ah
TL1 0 0 0 0 0 0 0 0 8Bh
TH0 0 0 0 0 0 0 0 0 8Ch
TH1 0 0 0 0 0 0 0 0 8Dh
CKCON(1) 0 0 0 0 0 0 0 1 8Eh
SPC_FNC(1) 0 0 0 0 0 0 0 0 8Fh
EXIF(1) 0 0 0 0 1 0 0 0 91h
Register Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Addr
MPAGE(1) 0 0 0 0 0 0 0 0 92h
SCON0 0 0 0 0 0 0 0 0 98h
SBUF0 0 0 0 0 0 0 0 0 99h
IE 0 0 0 0 0 0 0 0 A8h
IP 1 0 0 0 0 0 0 0 B8h
SCON1(1) 0 0 0 0 0 0 0 0 C0h
SBUF1(1) 0 0 0 0 0 0 0 0 C1h
T2CON 0 0 0 0 0 0 0 0 C8h
RCAP2L 0 0 0 0 0 0 0 0 CAh
RCAP2H 0 0 0 0 0 0 0 0 CBh
TL2 0 0 0 0 0 0 0 0 CCh
TH2 0 0 0 0 0 0 0 0 CDh
PSW 0 0 0 0 0 0 0 0 D0h
EICON(1) 0 1 0 0 0 0 0 0 D8h
ACC 0 0 0 0 0 0 0 0 E0H
EIE(1) 1 1 1 0 0 0 0 0 E8h
B 0 0 0 0 0 0 0 0 F0h
EIP(1) 1 1 1 0 0 0 0 0 F8h
(1)
Not part of standard 8051 architecture.
Bit Function
PSW.7 CY - Carry flag. This is the unsigned carry bit. The CY flag is
set when an arithmetic operation results in a carry from bit 7 to
bit 8, and cleared otherwise. In other words, it acts as a virtual
bit 8. The CY flag is cleared on multiplication and division.
PSW.4 RS1 - Register bank select bit 1. used with RS0 to select a
register bank in internal RAM.
PSW.2 OV - Overflow flag. This is the signed carry bit. The OV flag
is set when a positive sum exceeds 7fh, or a negative sum (in
two’s compliment notation) exceeds 80h. On a multiply, if OV
= 1, the result of the multiply is greater than FFh. On a divide,
OV = 1 on a divide by 0.
PSW.0 P - Parity flag. Set to 1 when the modulo-2 sum of the 8 bits in
the accumulator is 1 (odd parity), cleared to 0 on even parity.
C.1 Introduction
This chapter provides technical data about the 8051 core hardware operation and timing. The
topics are:
• Timers/Counters
• Serial Interface
• Interrupts
• Reset
• Power Saving Modes
C.2 Timers/Counters
The 8051 core includes three timer/counters (Timer 0, Timer 1, and Timer 2). Each timer/
counter can operate as either a timer with a clock rate based on the CLK24 pin, or as an event
counter clocked by the T0 pin (Timer 0), T1 pin (Timer 1), or the T2 pin (Timer 2).
Each timer/counter consists of a 16-bit register that is accessible to software as two SFRs:
• Timer 0 - TL0 and TH0
• Timer 1 - TL1 and TH1
• Timer 2 - TL2 and TH2
Dallas
Feature Intel 8051 8051
DS80C320
Number of timers 2 3 3
Timers 0 and 1 each operate in four modes, as controlled through the TMOD SFR (Table C-2.)
and the TCON SFR (Table C-3.). The four modes are:
• 13-bit timer/counter (mode 0)
• 16-bit timer/counter (mode 1)
• 8-bit counter with auto-reload (mode 2)
• Two 8-bit counters (mode 3, Timer 0 only)
C.2.3 Mode 0
Mode 0 operation, illustrated in Figure C-1., is the same for Timer 0 and Timer 1. In mode 0,
the timer is configured as a 13-bit counter that uses bits 0-4 of TL0 (or TL1) and all 8 bits of
TH0 (or TH1). The timer enable bit (TR0/TR1) in the TCON SFR starts the timer. The C/T bit
selects the timer/counter clock source, CLK24 or the T0/T1 pins.
The timer counts transitions from the selected source as long as the GATE bit is 0, or the
GATE bit is 1 and the corresponding interrupt pin (INT0# or INT1#) is 1.
When the 13-bit count increments from 1FFFh (all ones), the counter rolls over to all zeros,
the TF0 (or TF1) bit is set in the TCON SFR, and the T0OUT (or T1OUT) pin goes high for
one clock cycle.
Mode 0
T0 (or T1) pin
Mode 1
TR0 (or TR1)
GATE
INT0# pin
(or INT1#) TF0 (or TF1) INT
To Serial Port
(Timer 1 only)
C.2.4 Mode 1
Mode 1 operation is the same for Timer 0 and Timer 1. In mode 1, the timer is configured as a
16-bit counter. As illustrated in Figure C-1., all 8 bits of the LSB register (TL0 or TL1) are
used. The counter rolls over to all zeros when the count increments from FFFFh. Otherwise,
mode 1 operation is the same as mode 0.
Bit Function
Bit Function
TCON.7 TF1 - Timer 1 overflow flag. Set to 1 when the Timer 1 count
overflows and cleared when the processor vectors to the
interrupt service routine.
TCON.5 TF0 - Timer 0 overflow flag. Set to 1 when the Timer 0 count
overflows and cleared when the processor vectors to the
interrupt service routine.
GATE
C.2.5 Mode 2
Mode 2 operation is the same for Timer 0 and Timer 1. In mode 2, the timer is configured as
an 8-bit counter, with automatic reload of the start value. The LSB register (TL0 or TL1) is the
counter and the MSB register (TH0 or TH1) stores the reload value.
As illustrated in Figure C-2., mode 2 counter control is the same as for mode 0 and mode 1.
However, in mode 2, when TLn increments from FFh, the value stored in THn is reloaded into
TLn.
CLK24 1 0 CLK
C/ T 0 TL0 7
Divide by 4 1
T0 pin
TF0 INT
TR0
TF1 INT
GATE
C.2.6 Mode 3
In mode 3, Timer 0 operates as two 8-bit counters and Timer 1 stops counting and holds its
value.
As shown in Figure C-3., TL0 is configured as an 8-bit counter controlled by the normal
Timer 0 control bits. TL0 can either count CLK24 cycles (divided by 4 or by 12) or high-to-
low transitions on T0, as determined by the C/T bit. The GATE function can be used to give
counter enable control to the INT0# pin.
TH0 functions as an independent 8-bit counter. However, TH0 can only count CLK24 cycles
(divided by 4 or by 12). The Timer 1 control and flag bits (TR1 and TF1) are used as the
control and flag bits for TH0.
When Timer 0 is in mode 3, Timer 1 has limited usage because Timer 0 uses the Timer 1
control bit (TR1) and interrupt flag (TF1). Timer 1 can still be used for baud rate generation
and the Timer 1 count values are still available in the TL1 and TH1 registers.
Control of Timer 1 when Timer 0 is in mode 3 is through the Timer 1 mode bits. To turn Timer
1 on, set Timer 1 to mode 0, 1, or 2. To turn Timer 1 off, set it to mode 3. The Timer 1 C/T bit
and T1M bit are still available to Timer 1. Therefore, Timer 1 can count CLK24/4,
CLK24/12, or high-to-low transitions on the T1 pin. The Timer 1 GATE function is also
available when Timer 0 is in mode 3.
The default timer clock scheme for the 8051 timers is 12 CLK24 cycles per increment, the
same as in the standard 8051. However, in the 8051, the instruction cycle is 4 CLK24 cycles.
Using the default rate (12 clocks per timer increment) allows existing application code with
real-time dependencies, such as baud rate, to operate properly. However, applications that
require fast timing can set the timers to increment every 4 CLK24 cycles by setting bits in the
Clock Control register (CKCON) at SFR location 8Eh (see Table C-4.).
The CKCON bits that control the timer clock rates are:
CKCON BitCounter/Timer
5 Timer 2
4 Timer 1
3 Timer 0
When a CKCON register bit is set to 1, the associated counter increments at 4-CLK24
intervals. When a CKCON bit is cleared, the associated counter increments at 12-CLK24
intervals. The timer controls are independent of each other. The default setting for all three
timers is 0 (12-CLK24 intervals). These bits have no effect in counter mode.
Bit Function
CKCON.7,6 Reserved
Timer 2 runs only in 16-bit mode and offers several capabilities not available with Timers 0
and 1. The modes available with Timer 2 are:
• 16-bit timer/counter
• 16-bit timer with capture
• 16-bit auto-reload timer/counter
• Baud rate generator
X X X 0 Off
X = Don’t care.
Bit Function
T2CON.7 TF2 - Timer 2 overflow flag. Hardware will set TF2 when
the Timer 2 overflows from FFFFh. TF2 must be cleared to 0
by the software. TF2 will only be set to a 1 if RCLK and
TCLK are both cleared to 0. Writing a 1 to TF2 forces a
Timer 2 interrupt if enabled.
T2CON.6 EXF2 - Timer 2 external flag. Hardware will set EXF2 when
a reload or capture is caused by a high-to-low transition on
the T2EX pin, and EXEN2 is set. EXF2 must be cleared to 0
by the software. Writing a 1 to EXF2 forces a Timer 2
interrupt if enabled.
T2CON.2 TR2 - Timer 2 run control flag. TR2 = 1 starts Timer 2. TR2
= 0 stops Timer 2.
Bit Function
T2M
Divide by 12
0
CLK24 C/ T2
1 0
CLK 0 7 8 15
Divide by 4 1 TL2 TH2
T2 pin
TF2
EXEN2
CAPTURE
EXF2 INT
T2EX pin
T2M
Divide by 12
0
CLK24 1 0 CLK
C/ T2 0 7 8 15
Divide by 4 1 TL2 TH2
T2 pin
TF2
EXEN2
EXF2 INT
T2EX pin
TIMER 1 OVERFLOW
CLK24 Divide
by 2 0 C/ T2 Divide
CLK by 2
1
SMOD1
0 1
T2 pin RX
0 7 8 15 RCLK CLOCK
TR2
TL2 TH2
1 0 Divide
by 16
TCLK
RCAP2L RCAP2H
1 0
0 7 8 15 Divide
EXEN2
by 16
The 8051 core provides two serial ports. Serial Port 0 is identical in operation to the standard
8051 serial port. Serial Port 1 is identical to Serial Port 0, except that Timer 2 cannot be used
as the baud rate generator for Serial Port 1.
Each serial port can operate in synchronous or asynchronous mode. In synchronous mode,
8051 generates the serial clock and the serial port operates in half-duplex mode. In
asynchronous mode, the serial port operates in full-duplex mode. In all modes, 8051 buffers
received data in a holding register, enabling the UART to receive an incoming byte before the
software has read the previous value.
Each serial port can operate in one of four modes, as outlined in Table C-7..
(1)
Timer 2 available for Serial Port 0 only.
The implementation of the serial interface is similar to that of the Intel 8052.
C.3.2 Mode 0
Serial mode 0 provides synchronous, half-duplex serial communication. For Serial Port 0,
serial data output occurs on the RXD0OUT pin, serial data is received on the RXD0 pin, and
the TXD0 pin provides the shift clock for both transmit and receive. For Serial Port 1, the
corresponding pins are RXD1OUT, RXD1, and TXD1.
The serial mode 0 baud rate is either CLK24/12 or CLK24/4, depending on the state of the
SM2_0 bit (or SM2_1 for Serial Port 1). When SM2_0 = 0, the baud rate is CLK24/12, when
SM2_0 = 1, the baud rate is CLK24/4.
Mode 0 operation is identical to the standard 8051. Data transmission begins when an
instruction writes to the SBUF0 (or SBUF1) SFR. The UART shifts the data, LSB first, at the
selected baud rate, until the 8-bit value has been shifted out.
Mode 0 data reception begins when the REN_0 (or REN_1) bit is set and the RI_0 (or RI_1)
bit is cleared in the corresponding SCON SFR. The shift clock is activated and the UART
shifts data in on each rising edge of the shift clock until 8 bits have been received. One
Bit Function
SCON0.3 TB8_0 - Defines the state of the 9th data bit transmitted in
modes 2 and 3.
SCON0.1 TI_0 - Transmit interrupt flag. indicates that the transmit data
word has been shifted out. In mode 0, TI_0 is set at the end
of the 8th data bit. In all other modes, TI_0 is set when the
stop bit is placed on the TXD0 pin. TI_0 must be cleared by
firmware.
SCON0.0 RI_0 - Receive interrupt flag. Indicates that serial data word
has been received. In mode 0, RI_0 is set at the end of the 8th
data bit. In mode 1, RI_0 is set after the last sample of the
incoming stop bit, subject to the state of SM2_0. In modes 2
and 3, RI_0 is set at the end of the last sample of RB8_0.
RI_0 must be cleared by firmware.
Bit Function
SCON1.3 TB8_1 - Defines the state of the 9th data bit transmitted in
modes 2 and 3.
SCON1.1 TI_1 - Transmit interrupt flag. indicates that the transmit data
word has been shifted out. In mode 0, TI_1 is set at the end
of the 8th data bit. In all other modes, TI_1 is set when the
stop bit is placed on the TXD0 pin. TI_1 must be cleared by
the software.
SCON1.0 RI_1 - Receive interrupt flag. Indicates that serial data word
has been received. In mode 0, RI_1 is set at the end of the 8th
data bit. In mode 1, RI_1 is set after the last sample of the
incoming stop bit, subject to the state of SM2_1. In modes 2
and 3, RI_1 is set at the end of the last sample of RB8_1.
RI_1 must be cleared by the software.
PSEN
RXD0 D0 D1 D2 D3 D4 D5 D6 D7
RXD0OUT
TXD0
TI
RI
Figure C-7. Serial Port Mode 0 Receive Timing - Low Speed Operation
CLK24
PSEN
RXD0 D0 D1 D2 D3 D4 D5 D6 D7
RXD0OUT
TXD0
TI
RI
Figure C-8. Serial Port Mode 0 Receive Timing - High Speed Operation
PSEN
RXD0
RXD0OUT D0 D1 D2 D3 D4 D5 D6 D7
TXD0
TI
RI
Figure C-9. Serial Port Mode 0 Transmit Timing - Low Speed Operation
CLK24
PSEN
RXD0
RXD0OUT D0 D1 D2 D3 D4 D5 D6 D7
TXD0
TI
RI
Figure C-10. Serial Port Mode 0 Transmit Timing - High Speed Operation
SMODx
2
Baud Rate = x Timer 1 Overflow
32
Timer 2 Overflow
Baud Rate =
16
To use Timer 1 as the baud rate generator, it is best to use Timer 1 mode 2 (8-bit counter with
auto-reload), although any counter mode can be used. The Timer 1 reload is stored in the TH1
register, which makes the complete formula for Timer 1:
SMODx
2 CLK24
Baud Rate = x
32 12 x (256 - TH1)
SMODx
2 x CLK24
TH1 = 256 -
384 x Baud Rate
You can also achieve very low serial port baud rates from Timer 1 by enabling the Timer 1
interrupt, configuring Timer 1 to mode 1, and using the Timer 1 interrupt to initiate a 16-bit
software reload. Table C-10. lists sample reload values for a variety of common serial port
baud rates.
Note that more accurate baud rates are achieved by using Timer 2 as the baud rate generator
(next section).
Table C-10. Timer 1 Reload Values for Common Serial Port Mode 1 Baud Rates
To use Timer 2 as the baud rate generator, configure Timer 2 in auto-reload mode and set the
TCLK and/or RCLK bits in the T2CON SFR. TCLK selects Timer 2 as the baud rate
generator for the transmitter; RCLK selects Timer 2 as the baud rate generator for the receiver.
The 16-bit reload value for Timer 2 is stored in the RCAP2L and RCA2H SFRs, which makes
the equation for the Timer 2 baud rate:
where RCAP2H,RCAP2L is the content of RCAP2H and RCAP2L taken as a 16-bit unsigned
number.
The 32 in the denominator is the result of CLK24 being divided by 2 and the Timer 2 overflow
being divided by 16. Setting TCLK or RCLK to 1 automatically causes CLK24 to be divided
by 2, as shown in Figure C-6., instead of the 4 or 12 determined by the T2M bit in the
CKCON SFR.
To derive the required RCAP2H and RCAP2L values from a known baud rate, use the
equation:
RCAP2H,RCAP2L = CLK24
65536 -
32 x Baud Rate
When either RCLK or TCLK is set, the TF2 flag will not be set on a Timer 2 roll over, and the
T2EX reload trigger is disabled.
Table C-11. Timer 2 Reload Values for Common Serial port Mode 1 Baud Rates
Note: using rates that are off by 2.3% or more will not work in all systems.
If the above conditions are met, the serial port then writes the received byte to the SBUF0 (or
SBUF1) register, loads the stop bit into RB8_0 (or RB8_1), and sets the RI_0 (or RI_1) bit. If
the above conditions are not met, the received data is lost, the SBUF register and RB8 bit are
not loaded, and the RI bit is not set.
After the middle of the stop bit time, the serial port waits for another high-to-low transition on
the (RXD0 or RXD1) pin.
Mode 1 operation is identical to that of the standard 8051 when Timers 1 and 2 use CLK24/12
(the default).
TX CLK
SHIFT
RXD0
RXD0OUT
TI_0
RI_0
RX CLK
TI_0
RI_0
SMODx
2 x CLK24
Baud Rate =
64
Write to
SBUF0
TX CLK
SHIFT
START D0 D1 D2 D3 D4 D5 D6 D7 TB8 STOP
TXD0
RXD0
RXD0OUT
TI_0
RI_0
RX CLK
RXD0 START D0 D1 D2 D3 D4 D5 D6 D7 RB8 STOP
Bit detector
sampling
SHIFT
RXD0OUT
TXD0
TI_0
RI_0
Write to
SBUF0
TX CLK
SHIFT
START D0 D1 D2 D3 D4 D5 D6 D7 TB8 STOP
TXD0
RXD0
RXD0OUT
TI_0
RI_0
RX CLK
RXD0 START D0 D1 D2 D3 D4 D5 D6 D7 RB8 STOP
Bit detector
sampling
SHIFT
RXD0OUT
TXD0
TI_0
RI_0
The multiprocessor communication feature is enabled in modes 2 and 3 when the SM2 bit is
set in the SCON SFR for a serial port (SM2_0 for Serial Port 0, SM2_1 for Serial Port 1). In
multiprocessor communication mode, the 9th bit received is stored in RB8_0 (or RB8_1) and,
after the stop bit is received, the serial port interrupt is activated only if RB8_0 (or RB8_1) =
1.
A typical use for the multiprocessor communication feature is when a master wants to send a
block of data to one of several slaves. The master first transmits an address byte that identifies
the target slave. When transmitting an address byte, the master sets the 9th bit to 1; for data
bytes, the 9th bit is 0.
With SM2_0 (or SM2_1) = 1, no slave will be interrupted by a data byte. However, an address
byte interrupts all slaves so that each slave can examine the received address byte to
determine whether that slave is being addressed. Address decoding must be done by software
during the interrupt service routine. The addressed slave clears its SM2_0 (or SM2_1) bit and
prepares to receive the data bytes. The slaves that are not being addressed leave the SM2_0 (or
SM2_1) bit set and ignore the incoming data bytes.
Bit Function
Bit Function
Bit Function
Bit Function
Bit Function
Bit Function
When an enabled interrupt occurs, the 8051 core vectors to the address of the interrupt service
routine (ISR) associated with that interrupt, as listed in Table C-18.. The 8051 core executes
the ISR to completion unless another interrupt of higher priority occurs. Each ISR ends with a
RETI (return from interrupt) instruction. After executing the RETI, the CPU returns to the
next instruction that would have been executed if the interrupt had not occurred.
An ISR can only be interrupted by a higher priority interrupt. That is, an ISR for a low-level
interrupt can only be interrupted by high-level interrupt. An ISR for a high-level interrupt can
only be interrupted by the resume interrupt.
The 8051 core always completes the instruction in progress before servicing an interrupt. If
the instruction in progress is RETI, or a write access to any of the IP, IE, EIP, or EIE SFRs,
the 8051 core completes one additional instruction before servicing the interrupt.
The EA bit in the IE SFR (IE.7) is a global enable for all interrupts except the USB wakeup
(resume) interrupt. When EA = 1, each interrupt is enabled or masked by its individual enable
bit. When EA = 0, all interrupts are masked, except the USB wakeup interrupt.
Natural Interrupt
Interrupt Description
Priority Vector
There are two stages of interrupt priority assignment, interrupt level and natural priority. The
interrupt level (highest, high, or low) takes precedence over natural priority. The USB wakeup
interrupt, if enabled, always has highest priority and is the only interrupt that can have highest
priority. All other interrupts can be assigned either high or low priority.
In addition to an assigned priority level (high or low), each interrupt also has a natural priority,
as listed in Table C-18.. Simultaneous interrupts with the same priority level (for example,
both high) are resolved according to their natural priority. For example, if INT0 and INT2 are
both programmed as high priority, INT0 takes precedence due to its higher natural priority.
Once an interrupt is being serviced, only an interrupt of higher priority level can interrupt the
service routine of the interrupt currently being serviced.
Priority
Interrupt Description Flag Enable
Control
The internal timers and serial ports generate interrupts by setting their respective SFR
interrupt flag bits. External interrupts are sampled once per instruction cycle.
INT0 and INT1 are both active low and can be programmed to be either edge-sensitive or
level-sensitive, through the IT0 and IT1 bits in the TCON SFR. For example, when IT0 = 0,
INT0 is level-sensitive and the 8051 core sets the IE0 flag when the INT0# pin is sampled
low. When IT0 = 1, INT0 is edge-sensitive and the 8051 sets the IE0 flag when the INT0#
pin is sampled high then low on consecutive samples.
The remaining five interrupts (INT 4-6, USB & I2C Interrupts) are edge-sensitive only. INT6
and INT4 are active high and INT5 is active low.
To ensure that edge-sensitive interrupts are detected, the corresponding ports should be held
high for 4 CLK24 cycles and then low for 4 CLK24 cycles. Level-sensitive interrupts are not
Interrupt response time depends on the current state of the 8051. The fastest response time is 5
instruction cycles: 1 to detect the interrupt, and 4 to perform the LCALL to the ISR.
The maximum latency (13 instruction cycles) occurs when the 8051 is currently executing a
RETI instruction followed by a MUL or DIV instruction. The 13 instruction cycles in this case
are: 1 to detect the interrupt, 3 to complete the RETI, 5 to execute the DIV or MUL, and 4 to
execute the LCALL to the ISR. For the maximum latency case, the response time is 13 x 4 =
52 CLK24 cycles.
The 8051 interrupt structure provides a way to perform single-step program execution. When
exiting an ISR with an RETI instruction, the 8051 will always execute at least one instruction
of the task program. Therefore, once an ISR is entered, it cannot be re-entered until at least
one program instruction is executed.
To perform single-step execution, program one of the external interrupts (for example,INT0)
to be level-sensitive and write an ISR for that interrupt the terminates as follows:
JNB TCON.1,$ ; wait for high on INT0# pin
JB TCON.1,$ ; wait for low on INT0# pin
RETI ; return for ISR
The CPU enters the ISR when the INT0# pin goes low, then waits for a pulse on INT0#. Each
time INT0# is pulsed, the CPU exits the ISR, executes one program instruction, then re-enters
the ISR.
C.5 Reset
The 8051 RESET pin is internally connected to an EZ-USB register bit that is controllable
through the USB host. See Chapter 10, "EZ-USB Resets" for details.
An instruction that sets the IDLE bit (PCON.0) causes the 8051 to enter idle mode when that
instruction completes. In idle mode, CPU processing is suspended, and internal registers
maintain their current data. When the 8051 core is in idle, the EZ-USB core enters suspend
Bit Function
PCON.6-4 Reserved.
PCON.0 IDLE - Idle mode select. Setting the IDLE bit places the
8051 in idle mode.