Implementation of USB Protocol Interface on

Microcontroller
by
V Rama Vara Prasad
1005-10-74!07
M"-"#"-SSP$P%P&'
(ara(r(47)*+mail,com
Pro-ect &.ide
/ Rama 0ris1na
2ssitant Professor
3smania Uni(ersity
2BS%R2#%
The Universal serial bus(USB) had largely replaced the standard serial port to connect
devices to a PC because it is simpler, more foolproof, ans faster. But hile USB ma!es connection
easier for the user, it adds more design challenges, "any designers continue to use the
U#$T(Universal #synchronous $eceiver Transmitter) ith the standard serial port, aiting for
products that ma!e USB easier to implement.
The main ob%ective is to develop the USB using "C&'P(# hich inturn able to
communicate ith PC. The development ill be in such a ay that it ill have the USB ).*
specified things.
The re+uired things to implement is to have an interface of "C&'P(# ith a USB
transceiver(inbuilt or e,ternal). The -nput section of transceiver ill be interfaced ith
"C&'P(#(internally or e,ternally) and output section ill be serial data(./ and .0) of re+uired
voltage levels that support USB).* physical layer.
-n this or!, 1numeration level ill be -mplemented in micro Controller&'P(# so as to
recogni2e the USB device as a mass storage device by PC.
Pro-ect S.mmary
The Protocol 1ngine is a USB).* Communication Core, used for development and production of
USB Classic and 3endor Specific .evices by processing USB).* pac!et0level 4in!04ayer Protocol
tas!s in hardare, thus offloading communication tas!s from the "ain 5Controller. The protocol
engine performs, C$C chec! and generation, pac!et identifier decoding and verification, address
recognition and handsha!e evaluation and response.
#cting on a received to!en and analy2ing the to!en6s P-., address and endpoint number fields, the
protocol engine can handle USB pac!ets and transactions based on data se+uencing and state
machine logic.
USB ).* is an industry0ide, host oriented protocol, utili2ing physical serial bus.Protocol 1ngine
performs transaction to&from host. Protocol 1ngine supports four types of transactions7
#ontrol - used by the USB System Softare to configure devices.
B.l4 5 a reliable transfer that includes the handsha!e phase.
Isoc1rono.s 5 real0time, saves overhead by e,cluding handsha!e phase.
Interr.pt 5 a limited0latency transfer to or from a device.
The Protocol 1ngine pro%ect as donloaded into 8S*9 development board for simulation and
verification.
62R/72R" /"S#RIP%I38
The USB -nterface "odule !it Primarly consists of a microcontroller, :T#( connector, 4ed
-ndications and associated hardare and sofare.The microcontroller is the "C8S*9:";< motorola
family controller having a )=< bytes of USB $#". The bloc! diagram vie is given in figure >.;.
The description if each of these is given in this chapter.

"-C$?C?@T$?441$
The "C8S*9:";< as chosen as controller. The features hich ma!es this controller more
preferableto this pro%ect and it is having ;<!b flash to store code and ;!b $#" and )=< bytes of USB
$#".
"C8S*9:";< series "CUs are members of the lo0cost, high0performance ACS*9 family of 90bit
microcontroller units ("CUs). #ll "CUs in the family use the enhanced ACS*9 core and are
available ith a variety of modules, memory si2es, memory types, and pac!age types.
?n0chip memory in the "C8S*9:";< series of "CUs consists of $#", flash program memory for
nonvolatile data storage, plus -&? and control&status registers. The registers are divided into three
groups7
B .irect0page registers (*,**** through *,**#')
B Aigh0page registers (*,;9** through *,;9=')
B @onvolatile registers (*,''B* through *,''B')
Bloc! .iagram of "C8S*9:";< 7
The 90bit "C8S*9:";< device further e,tends 'reescale6s entry0level 90bit embedded USB
controller family ith up to ;< CB of flash memory, a full0speed USB ).* device controller and an
eight0channel, ;)0bit analog0to0digital converter. The S*9 :" family also has several system
protection features, such as lo voltage detection and a computer operating properly (C?P) module.
The "C8S*9:";< device is ell suited for a variety of industrial control and consumer
applications. Such applications include PC peripherals, industrial printers and touch panels.
The "C8S*9:";< devices, li!e the other USB microcontrollers in the Controller Continuum, are
supported by the 'reescale USB04-T1 Stac! by C"D. This complimentary USB stac! provides
support for certain A-. and C.C classes. Source code for the complimentary stac! is available.
The "C8S*9:";< is softare compatible ith other devices in the Controller Continuum, providing
a direct migration path to higher performing USB microcontrollers.
'eatures Benefits
9-bit 6#S09 #entral Processin+ Unit $#PU'
B Up to )E "A2 internal bus (E9 "A2 ACS*9
core) fre+uency offering ).F to =.=3 across
temperature range of 0E*GC to /9=GC
B ?ffers strong performance throughout the
entire
voltage range
B Support for up to >) peripheral interrupt&
re+uest resources
B #llos for e,ceptional softare fle,ibility and
optimi2ation for real0time applications
3n-#1ip Memory
B Up to ;<C flash read&program&erase over full
operating voltage and temperature
B #llos user to ta!e full advantage of in0
application,
re0programmability benefits
B Up to ;C $#" B Security circuitry to help prevent unauthori2ed
access to $#"
B 'lash contents help to reduce system poer
consumption
B )=< Byte USB $#" B -mprove data transfer speed by providing
data buffering
Po:er-Sa(in+ Modes
B Hait plus to stop modes B #llos continuation of sampling application
in a reduced
poer state hich reduces system poer
consumption
B "ulti0purpose cloc! generator ("C() B 're+uency0loc!ed loop ('44)7 -nternal or
e,ternal
reference can be used to control the '44
B Phase0loc!ed loop (P44)7 3oltage controlled
oscillator (3C?). "odulo 3C? fre+uency
divider.
4oc! detector ith interrupt capability
B -nternal reference cloc!7 Can be selected as
the
cloc! source for the "CU
B 1,ternal reference cloc!7 Provides control for
a separate crystal oscillator. Cloc! monitor ith
reset capability. Can be selected as the cloc!
source for the "CU.
B $eference divider provided
B Cloc! source can be divided by ;, ), E or 9
Peripherals
B USB device module B 'ull0speed USB ).* (;) "bps) module ith
dedicated on0chip >.>3 regulator
B Supports control, interrupt, isochronous and
bul! transfers
B #nalog comparators (#C"P)I#nalog
comparator ith option to compare to
internal reference
B $e+uires only single pin for input signal,
freeing up
other pin for other use
B #llos other system components to see
comparator result ith minimal delay
B Can be used for single slope #.C and $C
time
constant measurements
B #nalog0to0digital converter (#.C)I1ight0
channel, ;)0bit resolution
B ?utput formatted in ;)0, ;*0 or 90bit
right0%ustified format
B Single or continuous conversion
B ?peration in lo0poer modes for loer
noise operation
B #synchronous cloc! source for loer
noise operation
B To serial communications interface
(SC-) modules offering asynchronous
communications
B Provides standard U#$T communications
peripheral
B #llos full0duple,, asynchronous, @$J serial
communication beteen "CU and remote
devices
B - ) C ith up to ;** !bps ith ma,imum bus
loadingK multi0master operationK programmable
slave addressK interrupt driven byte0by0byte
data transferK supports broadcast mode and
;*0bit addressing
B #bility to add an additional - ) C device
B SP-ITo serial peripheral interfaces ith
full0duple, or single0ire bidirectionalK double0
buffered transmit and receiveK master or slave
modeK "SB0first or 4SB0first shifting
B Aaving to SP- allos to separate dedicated
devices, for e,ample, one SP- dedicated to a
JigBee L transceiver, and the other to "CUs or
peripherals
B Timer pulse idth modulation (TP")IUp to
si, channels
B 1ach channel may be input capture, output
compare or edge0aligned PH"
B -nput capture trigger on either rising or falling
edge
B Selectable polarity on PH" outputs
B Timer cloc! source selectable as prescaled bus
cloc!, fi,ed system cloc! or an e,ternal cloc!
pin
Inp.t;3.tp.t
B Up to seven Ceyboard -nterrupt (CB-) pins
ith
selectable polarity
B 1ach CB- pin is programmable as falling edge
only,
rising edge only, falling edge and lo level, or
rising
edge and high level interrupt sensitivity
B >F general purpose input&output ((P-?)s B $esults in a large number of fle,ible -&? pins
that
allo vendors to easily interface the device into
their on designs
System Protection
B Hatchdog computer operating properly (C?P)
reset ith option to run from dedicated ; !A2
internal cloc! source or bus cloc!
B #llos the device to recogni2e run0aay code
(infinite loops) and resets the processor to help
avoid loc!0up states
B 4o0voltage detection ith reset or interruptK
selectable trip points
B #lerts the developer to voltage drops outside
of the
typical operating range
B -llegal op code detection ith reset B #llos the device to recogni2e erroneous code
and
resets the processor to help avoid loc!0up states
B 'lash bloc! protection B Prevents unauthori2ed access to flash $#"
hich
greatly reduces the chance of losing vital system
code for vendor applications
6ard:are /e(elopment S.pport
B Single0ire bac!ground debug interface B This allos developers to use the same
interface
for multiple platforms
B Brea!point capability B #llos single brea!point setting during in0
circuit
debugging (plus to more brea!points in on0
chip
debug module)
B ?n0chip in0circuit emulator (-C1) debug
module (containing three comparators and
nine trigger modes). 1ight deep '-'? for
storing change0of0flo addresses and
event0only data, debug module supports
both tag and force brea!points.
B (rants full access to built0in chip emulation
ithout
the added e,pense of traditional emulator
hardare
USB /e(ice /e(elopment :it1 M#S09<M=0-In-dept1 Understandin+ of M#S09<M=0 USB
Mod.le
Introd.ction
"C8S*9:"<* devices form part of the 'reescale 'le,is series of microcontrollers. The 'le,is series
of microcontrollers is the connection point on the 'reescale Controller Continuum here 90bit and >)0
bit compatibility becomes reality.
The 90bit "C8S*9:"<* "CUs are devices ith a full0speed USB module I providing best0in0class
USB module performance, system integration, and softare support. The USB module on the :"
series "CU has seven endpoints and )=< bytes $#" for high efficiency data transfer.
"C8S*9:"<* "CUs provide many peripherals, such as USB, SP-, --C, SC-, #.C, TP", and $TC.
These "CUs are fle,ible and can easily be integrated into different applications such as game pads,
security control panels, printers and PC peripherals.
M#S09<M=0 USB Mod.le Introd.ction
'igure ; shos the bloc! diagram of the USB module for "C8S*9:"<* "CU.
-t includes7
?n0chip >.> 3 regulator (3$1()
USB transceiver (DC3$)
Serial interface engine (S-1)
USB $#"
'igure ) shos the layers of a typical USB device.
The physical layer involves data signaling, such as : and C signals, start of pac!et (S?P), and resume
signals. The USB PAM of "C8S*9:"<* corresponds to the physical layer.
The protocol layer lies above the physical layer. Transactions of different transfer type are managed
by this layer. The pac!et (handsha!e, etc.), in the USB lo0level protocol are processed in this layer.
-n the "C8S*9:"<* USB module, they are finished by S-1.
The command processor and data report handler layer lies beteen the protocol and application
layers. This layer corresponds to the USB stac! firmare described in this document. The USB
enumeration and configuration, the standard class re+uest, or the customi2ed protocol are all to be
processed by this layer.
The top layer is the application layer. -t it is based on the USB communication provided in the lo
layers. The program in this layer focuses on the customi2ed application.
!,1 USB "ndpoint
?ne important concept needs to be discussed before e,plaining the USB module I the endpoint.
1ach USB logical device consists of a collection of independent endpoints. #n endpoint is a uni+uely
identifiable portion of a USB device that is the terminus of a communication flo beteen the host
and device. USB pipe is an association beteen an endpoint on a device and softare on the host.
The "C8S*9:"<* device has seven endpoints that can be used to build seven communication pipes
beteen the USB host and device.
1ndpoint * is bidirectional (in and out)K it6s mainly used for control transfer. 1ndpoint * is re+uired for
all USB devices.
1ndpoint ;N< are directional7 they can be configured to do only in or out direction communication at a
time.
1ndpoint = and < are double buffering, that Ois also be calledP ping0pong buffer. 1ach of these has to
buffers. ?ne buffer can be operated by the CPU, hen the other communicates ith the host
(controlled by S-1). These to buffers e,change their roles after the current transaction is over. The
CPU has the control of one of the double buffers in turn. Hith this feature, the communication
efficiency improves because the CPU aiting time is shortened.
1ach endpoint can be enabled or disabled by the 1PCT4n register. The direction and handsha!e for all
endpoints are also controlled by the 1PCT4n register.
The control transfer, bul! transfer, isochronous transfer, and interrupt transfer are all supported by
each endpoint of "C8S*9:"<* series "CU. That matches all !inds of USB data transfer
re+uirements.
!,! VR"&
?n0chip regulator (3$1() provides a stable poer source to the USB internal transceiver and internal
(or e,ternal) pullup resistor. -t re+uires a voltage supply input in the range of >.8 3 to =.= 3, and its
output voltage range is from >.* 3 to >.< 3. The 3$1( shares the same poer supply ith the "CU,
but the "CU can or! ith the poer voltage from ).F 3 to =.= 3.
The corresponding pin to regulator output voltage is 3USB>.> , that can be used to supply the poer
for the e,ternal pullup resistor.
The on0chip regulator can be enabled or disabled by USB3$1@ bit of the USBCT4* register. -f it
isdisabled, an e,ternal >.> 3 voltage must be provided to USB module via 3USB>.> pin.
83%"
.amage to the part may occur if the e,ternal >.> 3 poer supply is provided hile the internal
regulator is enabled.
!,) USB %ranscei(er
USB transceiver belongs to the physical layer of the USB standard protocol. -t provides a differential
signal for USB communication. The USB.P and USB.@ pins are analog input&output lines for full0
speed data communication.
!,4 USB SI"
The USB serial interface engine (S-1) is mainly used to implement transferring and receiving of logic.
'or the S-1 transferring logic, the firmare immediately needs to configure three B. registers and
fills the data into endpoint bufferK then hands over the control to S-1. The S-1 ill send the data to the
host automatically after the host issues an -@ operation. #ll or! re+uired in the USB specification,
such as coding (@$J-), bit stuffing, C$C, SM@C, etc., are implemented by S-1 ithout firmare6s
intervention. The S-1 hands over the control to the CPU after the transfer is finished.
#s for the receiving logic, the S-1 can receive data pac!ets automatically. The receiving logic process
includes decoding, synchroni2ing, detection, bit stuff removal, 1?P detection, C$C validation, P-.
chec!, etc.
The data pac!et is filled into the endpoint buffer, and the B. registers are updated. Then the S-1 gives
the control to the CPU for reading data out. Some status and flag bits in the USB registers (-@ST#T,
ST#T, 1$$ST#T, and 1PCT4n) for this transaction are refreshed. The S-1 ons the control of the
B. and endpoint buffer before the data ends to receive.
The S-1 sends the ac!noledge (#CC) or non0ac!noledge (@#C) handsha!e to the host. -t also
stalls the current transfer (ST#44). The handsha!e is enabled or disabled by the 1PASAC bit in the
1PCT4n register. -f it is enabled, #CC is transferred to the host hen the transaction is correctly
received. The @#C is sent out by S-1 if the ?H@ bit in B. status and control register is *. The
ST#44 is issued by setting the 1PST#44 bit in the 1PCT4 register or the B.TST#44 bit in the B.
status and control register.
Hith the S-1 transferring and receiving logic, the or! of the firmare is greatly reduced resulting in
more CPU time being saved.
).= USB $#"
"C8S*9:"<* "CU provides )=< bytes $#" space for the USB module, in hich the USB B.
registers and endpoint buffer are located. The USB $#" can also be allocated by the system as
general purpose $#" hen the USB module is disabled or it still has free space.
The USB $#" runs at E9 "A2, hich is tice the speed of the bus cloc!. -t can be accessed by the
CPU system and S-1. This is an area to e,change data and information beteen the CPU and S-1.
#ll the USB control and the status registers (B. registers) and USB data buffer must be allocated in
the USB $#". -t is illegal to allocate them in other space.
The USB $#" occupies a separate space instead of a part of the "CU $#". 'rom the memory map
of "C8S*9:"<* in 'igure >, the USB $#" address range is from *,;9<* to *,;8=', but the EC
bytes of "CU $#" starts from *,**B*, ends at *,;*#'.
'igure > shos the USB $#" location of "C8S*9:"<* in the memory map. The organi2ation of
USB $#" is also illustrated.
!,5,1 B.ffer /escriptor %able $B/%'
Buffer descriptor table (B.T) is used to manage USB endpoint communication efficiently. -t provides
the status and control for each endpoint.
These registers for each endpoint are called buffer descriptor (B.). 1ach B. comprises three bytes, in
hich the endpoint data buffer6s location, length, control logic, and status are !ept.
The B.T locates at the beginning of USB $#". The B.s for seven endpoints are organi2ed and
placed one by one from 1P* in to 1P< out. There are ;* B.s in total and >* bytes are allocated from
*,;9<* to *,;9F. (offset7 *,**N*,;. in USB $#" space).
'igure E shos the B.s for seven endpoints and three B. registers for endpoint * (in direction). 'or
endpoint * (bidirectional), = and < (double buffer), each has to B.s. 1ndpoint of ;NE ons only one
B..
The first byte of the B. is the status and control register (see 'igure =). -t includes four bits that the
CPU reads or rites for controlling the USB communication. They are ?H@ (bit F), .#T#*&;(bit <),
.TS (bit >), and B.TST#44 (bit )).
B B.TST#44 can be set by the CPU to stall the ne,t transaction. # ST#44 handsha!e is issued on
its associated endpoint if the B.TST#44 bit is set.
B The .TS bit is used to enable or disable the data toggle synchroni2ation.
B .#T#*&; bit defines a .#T#* or .#T#; pac!et to be transmitted or received.
B ?H@ bit is implemented as the semaphore mechanism. -ts value determines hether the B. and
endpoint buffer is controlled by the CPU or S-1. Hhen it is set to logic *, the CPU has the control of
the B. and endpoint buffer, the CPU can modify the contents of the B. registers and the data in the
endpoint buffer. -f it is set to logic ;, the S-1 has the control of B. and endpoint buffer.
B The bitQ=7)R are updated by S-1 after a ne to!en pac!et is received. The to!en pac!et P-. is !ept
in these four bits.
The firmare designer must rerite all bits in the status and control the register in terms of the
configuration for the ne,t transaction. ?therise all the data pac!ets may not be received or
transferred. The rong setting for .#T#*&; results in the data being discarded by the S-1 or the host.
The .TS and B.TST#44 bits can also result in the data pac!et not being received or being stalled.
The values for these to bits are replaced by bit * and bit ; of the ne pac!et6s P-.. They must be
updated before the ne,t pac!et is allocated.
The second byte (BCQF7*R) is the length of the data pac!et to be transferred or the pac!et that has been
received. -t can be set to 2ero for some pac!ets (e.g, the transaction in the status stage of control
transfer). The ma,imum length is <E for the "C8S*9:"<* "CU. The BC register must be set to the
actual pac!et si2e to be transferred for the in direction endpoint, but it must be initiali2ed to be greater
than or e+ual to the pac!et si2e that is received for out direction endpoint.
The third byte (1P#..Q87)R) !eeps the start address of the endpoint buffer. -t must be filled ith the
bit 8N) of the relative address in USB $#". -t can be calculated by shifting to bits of the relative
address to right so the endpoint buffer address is four bytes alignment.
'igure < shos an e,ample for calculating the value of the 1P#.. register. Provided that the
endpoint buffer locates *,;99* (absolute address), the address relative to the start address of USB
$#" is *,)*.
Thus the value of 1P#.. for the endpoint can be calculated by shifting the value *,)* to bits to
right and the result is *,*9.
Setting these registers correctly is the basic re+uirement for successful endpoint communication.
'igure F is an e,ample of B.T configuration. -t shos the content in the B. registers of the endpoint
* and ;.
-n this e,ample, the buffer length is eight bytes for endpoint * (in and out) and four bytes for endpoint
;. The endpoint buffers are allocated continually from *,;99* (relative address *,)*).
B 1ndpoint * in direction7
-f the content of the status and control register is *,**, the CPU still has the control of B..
-f the BCQF7*R register is filled ith *,*9, it means that the pac!et si2e transmitted by 1P* in is eight
bytes. This value ta!es effect hen the S-1 controls this endpoint.
The ma,imum pac!et si2e for the endpoint is transferred to the host in the USB device enumeration
process. The value for the BC registers can be less than the ma,imum value I the data that e,ceeds
the ma,imum length must be divided into several pac!ets. The actual number to be transferred to the
host must be set to the BC register before the ?H@ bit of the status and control register is set (hand
over the control of B. to S-1).
The value of 1P#..Q87)R is *,*9. -t can be calculated by the start address allocated for endpoint * in
direction. -ts absolute address is *,;99*. The calculation method is illustrated in 'igure <.
B 1ndpoint * out direction7
The B. for endpoint * out direction is set to receive a .#T#* pac!et. The content of the status and
control register is *,99, hich means the control for B. and data buffer has handed over to S-1
(?H@ S ;), endpoint * ill receive .#T#* (.#T#*&; S *) pac!et, and the data toggle has been
enabled (.TS S ;), the correct data pac!et is received (ST#44 S T*6).
The S-1 changes the ?H@ bit to * for handing over the control to the CPU. Hhen one pac!et is
finished receiving, the e,act data length is updated and ritten to BC register.
B 1ndpoint ; in direction7
The endpoint ; is used for the in direction (transmitting data to the host). -t is configured to transfer
only four bytes.
@?T1
Hhen developing firmare, the programmer must avoid the address overlap for different endpoint
buffers. -n addition, the ma,imum si2e of the endpoint buffer must be the same as the length in the
USB configuration descriptor.
The start address of the endpoint buffer must be si,teen bytes aligned in USB $#".
#s for the space in USB $#" that is not assigned, the firmare can use them for another purpose.
The flochart in 'igure 9 shos the operation of B. registers used for in and out direction. -n out
direction, after the data pac!et is received from the host, the T?C.@1' bit is set, and the CPU
becomes the control of the B. and endpoint buffer (?H@ S *). 'irmare can deal ith this in an
interrupt service routine or in a polling routine. The program reads the length of the received data
from the BC register and then reads out the data from the endpoint buffer and processes it if necessary.
#fter that, firmare updates the B. register and hands over the control to S-1 for ne,t transaction.
Before the first pac!et is received, the firmare initiali2es the associated B. registers and hands over
the control to S-1. Then the USB module is ready to receive data from the host.
-n in direction of control transfer, the USB device receives one data pac!et that includes one re+uest
or command, then the device begins to prepare the data to be delivered to the host according to some
protocols. The firmare rites the data length to the BC register, rites the data to the endpoint data
buffer, then updates the status and control the register (.#T#*&;, ?H@, etc.). #fter that, the USB
module begins to ait for the host to read data (in operation).
The T?C.@1' bit is set after the host finishes reading out the data in the endpoint (the transaction
has finished). The USB interrupt is triggered if it is enabled. The ne data for the ne,t transaction can
be prepared in an interrupt service routine or in a polling routine.
!,5,! /o.ble B.ffer $Pin+-Pon+ B.ffer'
1ndpoints = and < of the "C8S*9:"<* "CU USB module are double0buffering endpoints (seeTable
; on page ;=). 1ither of them has to sets of B. (even and odd) registers. Hhen one B. and its
associated buffer are being operated by S-1 at the same timeK the CPU can access or control the other
B. and attached data buffer.
The CPU and S-1 e,change the control of the B. registers and endpoint buffer after they finish their
or!. The CPU gives the control to S-1 as processing ta!es place for the data operation and the
configuration of the B. registers. The S-1 returns the control to the CPU and tries to control the other
buffer hen it finishes the current transaction. Hith the communications going on, the CPU and S-1
have the control of to B.s and their attached data buffers in turn, so the double buffer is also called
the ping0pong buffer.
The mechanism of the double buffer ma!es the CPU and S-1 cooperate ell ithout aiting for each
other for a long time I hence the efficiency of communication is improved.
The flochart in 'igure 8 shos ho to use the ping0pong buffer. Both B.s and their attached buffers
are initiali2ed at first. The double buffer has to sets of B. and data buffers that occupy different
space in USB $#". They both belong to one endpoint and have same direction (in or out) and share
one 1PCT4,(= or <) register.
The ?.. bit in the ST#T register reflects the operation completed by S-1. The user6s program
understands that B. and attached buffer is dealt ith in terms of the value e,pressed in this bit. The
?.. bit can be reset to point to even buffer by setting the ??.$ST bit in the CT4 register.
The operation of a ping0pong buffer for in direction is illustrated in 'igure 8. #fter the transaction
ith in operation ends, the T?C.@1' bit is set and the "CU becomes the controller of B.. Then the
firmare reads the ?.. bit to determine hich B. and data buffer must be dealt. #fter that, the data
buffer, the BC register, and the control register are ritten or updated. The "CU hands over the
control to the S-1 at last.
'or ping0pong buffer operation, the firmare can set one B. to send or receive the .#T#* pac!et,
and the other for .#T#; pac!et ithout toggle (.TS S *). That is, the even buffer is for .#T#* and
the odd buffer is for .#T#;.
) USB /e(ice /e(elopment
>.; Aardare .esign
Aardare design for USB device ith "C8S*9:"<* is simple and fle,ible. The designer can choose
to use the on0chip regulator or e,ternal poer supply and to use the internal pullup or e,ternal pullup
resistor. Mou can use the internal pullup or e,ternal pullup resistor. The "CU provides many
interfaces such as SP-, SC-, --C, #.C, CB-, etc. The designers thus have more selections in design.
The hardare design of the USB interface is discussed in the folloing sections.
>.;.; Cloc!ing (eneration
USB module re+uires to cloc! sources. They are the )E "A2 bus cloc! and E9 "A2 reference
cloc!. #ccording to the "C( features, the "C( must or! in P11 mode (P44 engaged e,ternal) and
an e,ternal cloc! source is essential for matching this re+uirement. #n oscillator or crystal is used as
the e,ternal cloc! source.
1,ample ; shos the "C( initiali2ation routine by using an e,ternal ;) "A2 crystal. The system
cloc! is sitched from '1- mode to 'B1 mode and then to PB1 mode and finally to P11 mode. The
"C( status register ("C(SC) is chec!ed in each step to ensure that the cloc! is stable, loc!ed by
P44 (or '44), and sitched successfully.
1,ample ;. "C( -nitiali2ation $outine Using 1,ternal ;) "A2 Crystal
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
void "C(U-nit()
V
&W the "C( is set to '1- mode by default, it should be change to 'B1 mode at first W&
"C(C) S *,><K &WSelect high fre+uency, high gain, ?scillator re+uestedW&
hile(X("C(SC Y *,*)))K &WHait for the stable of ?scillator W&
"C(C; S *,8BK &W1,ternal cloc! is selected, $.-3 S *b*;; (to get ;.="A2)W&
hile(("C(SC Y *,;C ) XS *,*9)K
&WChec! hether the e,ternal reference cloc! is selected W&
&W Sitch to PB1 mode from 'B1W&
"C(C> S *,E9K &W1nable P44, 3.-3 S *b;***, multiply by >)W&
hile (("C(SC Y *,E9) XS *,E9)K &WHait for the P44 to be loc!ed W&
&WSitch to P11 mode from PB1 modeW&
"C(C; YS *,>'K &WP44 output is selectedW&
hile(("C(SC Y *,<C) XS *,<C)K
&WHait for the P44 output becoming the system cloc! source W&
returnK
Z
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
),1,! USB /e(ice Po:er
The dedicated on0chip regulator poers the USB transceiver. -t shares the same poer supply ith
"CU. The on0chip regulator is enabled or disabled by the USB3$1@ bit in the USBCT4* register.
Hhen the on0chip regulator is disabled (USB3$1@ S *), one e,ternal >.> 3 poer is connected to 3
USB >.> pin to provide the poer for USB transceiver and pullup resistor.
The nominal input range of this regulator is from >.8 3 to =.= 3, but the "CU or!s at loer voltage
().F 3 N =.= 3). Hhen the poer supply for "CU is belo >.8 3, an e,ternal poer supply must be
provided for the USB module and the internal regulator must be disabled.
-n addition, it is highly recommended that to capacitors are connected to the 3 USB >.> pin to
decrease the ripple on the output of the regulator. Their recommended values are *.EF [', and E.F ['.
(refer to 'igure ;*), and they must be placed to the 3 USB >.> pin as near as possible.
USB devices have to poer modes I self0poered and the bus0poered. $efer to the USB
specification for detailed information. The design for to different poer modes differ.
B Bus0Poered
Bus0poered USB devices are poered from the USB bus. The ma,imum current dran from the
host is =** m#. The USB device is poered hen it is attached to USB bus and the connection is
valid, then the host ill find it attached.
B Self0Poered
The self0poered USB device uses an individual poer supply to provide the current for all
components, so that its poer consumption is limited by the capability of e,ternal poer supply. The
USB device hose current consumption is more than =** m# must adopt self0poered mode.
-n self0poered applications, the "CU or!s ithout the USB connection. The firmare has the
capability to !no the status of USB connection (attached or not) for sitching its state machine
correctly. ?ne (P-? pin or CB- pin is recommended to help detect the USB poerK then the firmare
determines the connection status.
-n addition, connect the ferrite bead in series beteen the poer (or ground) of the host and USB
device to help to absorb the high fre+uency noise coupled in the poer system (decrease
electromagnetic interference). The ferrite bead is similar to a high permeability inductance herein
the high fre+uency impedance attenuates the high0fre+uency current, and the .C current passes freely.
),1,) P.ll.p Resistor
USB host uses the pullup resistor to detect the connection of the USB device and identifies the
device6s speed (lo, full, high). The USB module of "C8S*9:"<* choose the use of an internal or
e,ternal pullup resistor.
The internal pullup resistor is enabled by the USBPU bit of the USBCT4* register.
Hhen the internal pullup resistor is disabled, one ;.= !\ pullup resistor can be connected beteen the
3 USB >.> pin and the USB.P pin. See the connection mar!ed ith dash line in 'igure 9.
@?T1
The USB device can use internal pullup resistor or e,ternal pullup resistor, but only one pullup
resistor is alloed to be connected.
Table ;lists all the combinations USB regulator and pullup resistor. The designers can select one of
the combinations according to actual re+uirement.
),! USB >irm:are /esi+n
>.).; USB Communication "odel
?n the high layer of the USB data flo model, the USB pipe is built for communication beteen the
USB device and the host. # USB pipe is an association beteen an endpoint on a device and softare
on the host. Pipes represent the ability to move data beteen softare on the host via a memory buffer
and an endpoint on a device.
USB devices must build at least one control pipe to the host. The control pipe (also called default
control pipe) is essential for all USB devices. -t is based on endpoint *, uses control transfer type, and
supports bidirectional data communication. The other pipes can be designed in terms of the
application6s re+uirements. There are seven pipes available (seven endpoints) for "C8S*9:"<* to
support control, bul!, interrupt, or isochronous transfer.
The default control pipe is used by the USB system softare to determine device identification and
configuration re+uirements and to configure the device. The default control pipe can also be used by
device0specific softare after the device is configured. The USB enumeration and configuration is the
first step to design the firmare of a USB device.
The USB communication consists of transfers. The USB transfer comprises one or more transactions,
and each transaction includes several pac!ets. 'or "C8S*9:"<* USB devices, the firmare
immediately needs to do little or!. ?ne transaction is completed by the USB module automatically.
The programer can ignore or! related to lo level USB protocol, such as C$C calculation, building
pac!et and handsha!e. The programer can spend more effort on high0level protocol and data process.
The firmare design of USB device ith "C8S*9:"<* is discussed in the folloing
sections..etailed information about enumeration and configuration has also been covered.
),!,! Main >irm:are Str.ct.re
'igure ;; shos to flo charts of a USB firmare e,ample designed ith "C8S*9:"<* device.
?ne is the main routine, and the other is the USB module initiali2ation.
#fter the "CU is poered on the firmare performs system initiali2ation. #ll modules used in
application are initiali2ed one by one.
The firmare can complete the USB module initiali2ation by folloing the steps in 'igure ;;. -t
initiali2es the USB B.T according to the USB $#" assignment, then initiali2es the USB registers,
and sets the USB state to #TT#CA1. at last.
To set the USB registers, it configures the USB module (pullup resistor, USB regulator in terms of the
hardare design) first, then enables the 1P* and the USB interrupt. 'or self0poered devices, the
USB module can be enabled hen "CU detects the USB bus poer, and the USB device initial state
is P?H1$1..
@?T1
The 1PCT4* must be set to *,*. for control transfer on endpoint * before the enumeration starts.
-n the main loop of firmare, the program chec!s the USB status changes, e.g., attached or detached
to USB bus. The other customi2e tas!s are also located in main loop.
The firmare can use the polling or interrupt method to deal ith USB events. Hith the polling
method, all USB status bits in the -@TST#T register are chec!ed, the program ill %ump to associated
service routine if the flag bits are set. The USB interrupt must be enabled before entering suspend
mode if the "CU needs to or! in stop> mode.
-f the polling method is not adopted, the interrupt method is a good choice. #ll events involved in the
USB communication can be processed in real0time by the USB interrupt service routine, and all
unnecessary polling for the status flag bits hen no USB events occurred are avoided.
'igure ;) is an e,ample of USB interrupt service routine (-S$). The USB interrupt flags in the
-@TST#T register are chec!ed one by one. Hhen one USB event occurs, the associated interrupt flag
is set, then the program ill process these events in -S$ if this interrupt is enabled. The program ill
chec! the ne,t interrupt flag.
Hhen the USB device is in suspend mode, the resume interrupt flag and the resume interrupt
processing differ according to the or! mode of "CU (stop> or user mode). The 4P$1S' bit in the
USBCT4* register is set for resuming from stop> mode, and the $1SU"1' bit in the -@TST#T
register is set for resuming from the user mode. The processing is listed in 'igure ;). The designer can
select from these to ays. This is the reason hy the processing for $1SU"1' is mar!ed ith
dotted line.
The $1S1T bit is set hen the host sends a reset signal to the device. The program for processing a
$1S1T must stop all USB involved processes immediately, reset the USB registers (e.g, #..$S*),
and return to the state before enumeration begins.
The T?C.@1' bit is set hen one transaction is complete. The processing of T?C.@1' is the main
entry for all transactions.
The interrupt flag must be cleared after it is serviced. ?therise the interrupt is e,ecuted again and
again, ithout stopping.
),!,) USB State Mac1ine
USB device has the folloing states7
B Poered7 USB device is not attached to the USB bus, but the "CU has been poered on.
B #ttached7 USB device is attached to the USB bus, but enumeration has not started
B .efault7 USB device is reset by the host
B #..$UP1@.-@(7 USB device receives the SetU#ddress command from the host
B #ddressed7 The Set0#ddress command has e,ecuted successfully.
B Configured7 The USB device receives and e,ecutes the SetUConfiguration command successfully.
B Suspend7 The USB device enters suspend mode.
'igure ;> shos the sitches of the USB state machine. The suspend and reset mode can be entered
from all states e,cept the poered state.
The bus0poered USB device sets its state to attached directly after it is attached to the USB bus.
The state of #..$UP1@.-@( is set hen USB device receives the SetU#ddress setup to!en. -t is
changed to #..$1SS1. hen the SetU#ddress transfer has finished.
#fter the USB device is attached to the USB bus, the host starts the enumeration process, the USB
device state changes to configured from attached if the enumeration process succeeds.
),!,4 USB /e(ice "n.meration Process
-n the enumeration process, the host performs the identification and configuration for the USB device.
The folloing process is an e,ample for enumeration beteen a USB device and computer ith
Hindos DP operating system installed.
;. The host detects the connection of a ne device via the device6s pullup resistors on the data pair.
The host aits for at least ;** ms, alloing for the plug to be inserted fully and for poer to be stable
on the device.
). Aost issues a reset to ma!e the device in default state.
>. The "S Hindos host as!s for the first <E bytes of the device descriptor.
E. #fter receiving the first eight bytes of the device descriptor, host immediately issues another bus
reset.
=. The host no issues a SetU#ddress command to place the device in the addressed state.
<. The host as!s for the entire ;9 bytes of the device descriptor.
F. The host then as!s for nine bytes of the configuration descriptor to determine the overall si2e.
9. The host as!s for )=< bytes of the configuration descriptor.
8. Aost as!s for any string descriptors specified.
;*. Hindos ill as! for a driver for device. -t may re+uest all the descriptors again before it issues a
Set configuration re+uest.
;;. Aost sets the configuration of device. The USB device state changes to configured.
The enumeration process is similar for all USB devices. The host fetches a lot of descriptors from the
device, such as the devices descriptor, configuration descriptor, interfaces descriptors, endpoint
descriptors, and string descriptors. #ccording to the information in these descriptors, the operating
system finds the driver for the USB device, and the driver sets the configuration of device at last.
The enumeration process is carried on the endpoint *, hich the default control pipe is built in. The
control transfers constitute the enumeration process, so the program about control transfer is the most
important part for USB stac!.
The implementation for control transfer on endpoint * has been described in the sections that follo.
The setting for the B. registers and the endpoint buffer is also involved.
),!,4,1 USB R2M 2llocation and 2ccess
B.T is located at the beginning of the USB $#". Because the location of B. assigned for different
endpoint is fi,ed, you can define the folloing data structure for B.T access (defined ith C
language).
1,ample ). .ata Structure for B.T #ccess
typedef union UB.UST#T
V
byte UbyteK
structV
unsigned 7;K
unsigned 7;K
unsigned B.TST#447;K &WBuffer Stall 1nableW&
unsigned .TS7;K &W.ata Toggle Synch 1nableW&
unsigned 7;K &W#ddress -ncrement .isableW&
unsigned 7;K &WB. Ceep 1nableW&
unsigned .#T#7;K &W.ata Toggle Synch 3alueW&
unsigned ?H@7;K &WUSB ?nershipW&
Z"cuCtlBitK
structV
unsigned 7;K
unsigned 7;K
unsigned P-.*7;K
unsigned P-.;7;K
unsigned P-.)7;K
unsigned P-.>7;K
unsigned 7;K
unsigned ?H@7;K
ZSieCtlBitK
structV
unsigned 7)K
unsigned P-.7EK &WPac!et -dentifierW&
unsigned 7)K
Z$ecPidK
Z B.UST#TK &WBuffer .escriptor Status $egisterW&
typedef struct UBU''U.SC
V
B.UST#T StatK
byte CntK
byte #ddrK &WBuffer #ddressW&
Z BU''U.SCK &WBuffer .escriptor TableW&
typedef struct UB.T"#P
V
BU''U.SC ep*BiK &W1ndpoint * B. -nW&
BU''U.SC ep*BoK &W1ndpoint ; B. ?utW&
BU''U.SC ep;BioK &W1ndpoint ; B. -@ or ?UTW&
BU''U.SC ep)BioK &W1ndpoint ) B. -@ or ?UTW&
BU''U.SC ep>BioK &W1ndpoint > B. -@ or ?UTW&
BU''U.SC epEBioK &W1ndpoint E B. -@ or ?UTW&
BU''U.SC ep=BioU1venK &W1ndpoint = B. -@ or ?UT 1venW&
BU''U.SC ep=BioU?ddK &W1ndpoint = B. -@ or ?UT ?ddW&
BU''U.SC ep<BioU1venK &W1ndpoint < B. -@ or ?UT 1venW&
BU''U.SC ep<BioU?ddK &W1ndpoint < B. -@ or ?UT ?ddW&
H?$. $eservedK
ZB.T"#PK
B.T"#P :m<*UBdt ]*,;9<*K
byte 1P*U-nUBufQ9R ]*,;99*K
byte 1P*U?utUBufQ9R ]*,;98*K
byte 1P;U-nUBufQ<ER ]*,;9#*K
unsigned P-.>7;K
unsigned 7;K
unsigned ?H@7;K
ZSieCtlBitK
structV
unsigned 7)K
unsigned P-.7EK &WPac!et -dentifierW&
unsigned 7)K
Z$ecPidK
Z B.UST#TK &WBuffer .escriptor Status $egisterW&
typedef struct UBU''U.SC
V
B.UST#T StatK
byte CntK
byte #ddrK &WBuffer #ddressW&
Z BU''U.SCK &WBuffer .escriptor TableW&
typedef struct UB.T"#P
V
BU''U.SC ep*BiK &W1ndpoint * B. -nW&
BU''U.SC ep*BoK &W1ndpoint ; B. ?utW&
BU''U.SC ep;BioK &W1ndpoint ; B. -@ or ?UTW&
BU''U.SC ep)BioK &W1ndpoint ) B. -@ or ?UTW&
BU''U.SC ep>BioK &W1ndpoint > B. -@ or ?UTW&
BU''U.SC epEBioK &W1ndpoint E B. -@ or ?UTW&
BU''U.SC ep=BioU1venK &W1ndpoint = B. -@ or ?UT 1venW&
BU''U.SC ep=BioU?ddK &W1ndpoint = B. -@ or ?UT ?ddW&
BU''U.SC ep<BioU1venK &W1ndpoint < B. -@ or ?UT 1venW&
BU''U.SC ep<BioU?ddK &W1ndpoint < B. -@ or ?UT ?ddW&
H?$. $eservedK
ZB.T"#PK
B.T"#P :m<*UBdt ]*,;9<*K
byte 1P*U-nUBufQ9R ]*,;99*K
byte 1P*U?utUBufQ9R ]*,;98*K
byte 1P;U-nUBufQ<ER ]*,;9#*K
-n this e,ample, all bits in the B. registers are declared in the B.UST#T structure. The B.T"#P
structure includes all B.s for seven endpoints. The structure variable :m<*UBdt is declared, and its
address is fi,ed at *,;9<*. #ccording to the memory allocation rules for structure, all the B. registers
for different endpoint points to their location in USB $#".
'irmare accesses the ?H@ bit of the B. registers li!e this,:m<*UBdt.ep;Bio.Stat."cuCtlBit.?H@
S ;K &W hand over the control to S-1W&.
'irmare defines the endpoint buffers and assigns them in USB $#", that can be accessed
directly.1P*U?utUBufQ9R is defined and fi,ed to *,;98*.
>.).E.) Control Transfer
Control transfer has three stages. They are the setup, data, and status stages. To control transfer, the
data stage can be omitted, e.g, SetU#ddress.
The data transferring direction in data stage is determined by the re+uest type transferred to USB
device in the setup stage. The direction in the status stage is different from that in the data stage. -f the
direction in data stage is in (out), the direction in the status stage is out (in).
The data pac!et type for control transfer begins ith .#T#*, and toggles continuously in the setup
and data stages. The data pac!et type must be .#T#; in the status stage even if the last data type in
data stage is .#T#;.
#ccording to the data transfer direction in different stages, three states describe the control transfer.
B H#-TUS1TUPUT?C1@7 before the beginning of the control transfer
B CT4UT$'U.#T#UTD7 send data to the host (in direction) in current or the ne,t transaction
B CT4UT$'U.#T#U$D7 receive data from the host (out direction) in current or the ne,t transaction
The control transfer begins ith a S1TUP to!en issued by the host. Before the S1TUP to!en is
received by device, the state is H#-TUS1TUPUT?C1@. The firmare determines the ne,t state is
CT4UT$'U.#T#UTD or CT4UT$'U.#T#U$D according to the re+uest type in the first transaction.
The state transfer is demonstrated in 'igure ;E.
'igure ;= is a USB control transfer e,ample. The transfer in this chart is issued by the host to get the
device descriptor. -t comprises three transactions. The first transaction belongs to the setup stage. The
second and the third respectively attribute to the data stage and the status stage.
The state changes in control transfer are mar!ed on the right of 'igure ;=.
The .#T# toggle (.#T#*&;) for control transfer can also be found. -ts changing se+uence is .#T#*
(first transaction, the setup stage) .#T#; (second transaction, the data stage) .#T#; (third
transaction, the status stage).
The S?' pac!ets are hidden in 'igure ;=, so some pac!ets li!e the =>, =F, =9 pac!ets cannot be
found.
'rom the image displayed above, the firmare can determine the change from the data stage to the
status stage by detecting the sitch of the transaction direction (in&out). The in and out direction are
controlled by the host, the change means the data stage is complete, and the control transfer state is
also changed.
The firmare can also trace the state change beteen CT4UT$'U.#T#UTD and
CT4UT$'U.#T#U$D by calculating the data length transferred or received. -f all bytes have been
transferred or received, the data stage is complete.
Aoever this is not a good ay to determine that the data stage is complete. The USB device cannot
ma!e sure that the host has received all those data pac!ets. -t is not recommended to use this method
to change the control transfer state.
),!,4,) Process of USB #ontrol %ransfer
USB control transfer comprises to or more transactions. -f an endpoint is correctly set, the
transactions can be automatically controlled and processed by S-1. The T?C.@1' bit is set hen
one transaction completes. 'igure ;< shos the process of one complete transaction carried on
endpoint *, it belongs to the enumeration process.
The T?C.@1' bit in the USB interrupt flag register is set first. The firmare reads the ST#T register
to determine hether the transaction occurs on endpoint * or not. -f it is not on endpoint *, the
firmare ill %ump to the associated routine for that endpoint. -f it is on endpoint *, the firmare ill
chec! the transaction6s direction (in or out).
-f the transaction is in direction, the program ill verify hether the received pac!age is a S1TUP
pac!age or not. -f yes, the program determines the data source (or ob%ect) pointer and length to be
transferred (or received) according to the re+uest type. The re+uest type (USB standard re+uest or
class re+uest) determines the data transfer direction and the address and length of source or ob%ect
data. #fter that, the control transfer state is ad%usted to CT4UT$'U.#T#UTD (or
CT4UT$'U.#T#U$D) from H#-TUS1TUPUT?C1@ by the data transfer direction bit in the USB
re+uest.
-f the re+uest is not supported, the firmare ill stall the current transfer by setting the ST#44 bit in
the 1PCT4 register (1PST#44) or the B. control and status register. The USB module ill then
prepare the ne,t control transfer in the ST#44 interrupt service routine or at the location mar!ed ith
dotted line.
#fter that, if the direction is in, the firmare ill rite the data to the buffer according to the
ma,imum length supported by the endpoint. The B. registers are also updated according to the
re+uirements.
#t last, the CT4UTSUSP1@. bit in the CT4 register is cleared for processing the ne,t pac!et "CU
hands over the control to S-1. This routine ends ($1T- or $1T).
-f the transaction is out direction, and it is not for S1TUP, the firmare ill chec! if the control
transfer is CT4UT$'U.#T#U$D. -f the result is true, the firmare ill read out the data from the
endpoint out buffer according to the length in the BC register. Then firmare ill prepare for the ne,t
transaction.
-f the control transfer state is CT4UT$'U.#T#UTD and this transaction is in the end of the status
stage of current transfer, this transfer has finished. The firmare needs to begin the preparation for the
ne,t transfer.
-f this transaction is for endpoint *, e add a supplementary chec! for the USB state. Hhen the USB
SetU#ddress standard re+uest is issued, the USB state is changed to #..$UP1@.-@( in the first
transaction of this transfer. #n in transaction is issued no.
-n the status stage of SetU#ddress transfer, the ne USB device address is ritten to the USB address
register. -f the USB state is not #..$UP1@.-@(, the firmare ill chec! the current control
transfer state. -f it is true, the firmare ill rite the data to be delivered to the endpoint buffer, then
update the B. registers for transferring. -f it is false, this transaction belongs to the status stage,
current transfer ends.
The interrupt flag must be cleared in the service routine by riting ; to T?C.@1' bit.
The program illustrated 'igure ;< can be implemented ith the interrupt method or the polling
method. -n both methods, each interrupt flag bit in the -@TST#T register is chec!ed and processed.
),!,5 USB %ransactions on "P1-=
'irmare designer can assign the endpoint direction, buffer si2e, location, and transfer type according
to the re+uirements of the application. Some information is included in the endpoint descriptor and
reported to the host in the enumeration process.
Hhen a transaction is complete in any one of the endpoint ;N <, the T?C.@1' bit is set, and the
firmare can process it li!e the transactions in control transfer. -n 'igure ;<, if the firmare finds the
transaction did not occur on endpoint *, it %umps to an associated routine for a different endpoint.
1,ample >. Processing for Transaction on .ifferent 1ndpoints
void USBUTransactionUAandler(void)
V
unsigned char stat S ST#TK

if((stat Y *,'* ) SS *,**)
V
...... &Wthe processing for the transaction on endpoint *W&
Z
else
V
if((stat Y *,'*) SS *,)*)
A-.U$ecU.ata()K
&Wadd the code for other endpointsW&
Z
returnK
Z
-n 1,ample >, the firmare processes the transaction on a different endpoint by chec!ing the ST#T
register. The code for other endpoints can be inserted li!e the A-.U$ecU.ata routine. The
A-.U$ecU.ata is used to process the received data from the host on endpoint ).
#ll endpoints and their operations have similar B. registers and endpoint buffers. The control,
interrupt, and bul! transfer operation on these endpoints are also similar. The isochronous transfer is
different. -t does not need to set the 1PASAC bit in the 1PCT4, register and toggle the .#T#*&;,
because lo0level USB protocol does not allo handsha!es to be returned to the transmitter of an
isochronous pipe. 'or isochronous transfers, the protocol is optimi2ed by assuming transfer normally
succeeds because timeliness is more important than correctness&retransmission.
),!,= S.spend and Res.me
USB host can ma!e the USB device or hole USB bus enter the suspend state at any time. #s per the
USB specification, the USB device enters suspend mode hen the USB bus is idle for more than >
ms. This process must be completed by the "CU in F ms, after the first > ms have elapsed.
The current consumed by the USB device from the USB bus must be less than =** [# for a lo0
poer device ().= m# for a high0poer device). The "C8S*9:"<* "CU supports lo0poer
devices. To achieve the current consumption in suspend mode, the "C8S*9:"<* "CU must or! in
stop> mode if it is bus0poered. -t is not essential if the USB device is self0poered.
'or the bus0poered USB device, the USB$1S"1@ bit in the USBCT4* register must be set to ;
before the "CU enters stop> mode. This enables an asynchronous interrupt to a!e up the "CU
from stop> mode. 'or the self0poered device, firmare can set $1US"1 in the -@T1@B register to
enable USB resume if the "CU does not need to enter stop> mode.
There are to !inds of resume methods for the "C8S*9:"<* "CU resumed by the host and remote0
a!eup.
The host sends out the resume signal (C state for at least )* ms), then the $1SU"1' flag in the
-@TST#T register is set. The USB interrupt is triggered hen the "CU is in or! mode and the
$1SU"1 is enabled. The 4P$1S' bit in the USBCT4* register is set hen USB$1S"1 bit is set
and "CU is in stop> mode.
#t the same time, an asynchronous interrupt is triggered and brings the "CU out of stop> mode. This
interrupt has the same vector as USB interrupt. The USB$1S"1 bit must be cleared immediately in
the interrupt service routine. -n addition, the firmare must chec! hether the resume signal on USB
bus is caused by noise. "CU must enter stop> mode again if the noise causes this.
The USB module of the "C8S*9:"<* "CU supports remote0a!eup. The remote0a!eup signal
can be generated by setting the C$1SU"1 bit in the CT4 register. The firmare can set this bit, then
clear it after a delay beteen = to ;= ms. This signal brings the USB bus out of suspend mode.
The folloing program (ne,t page) is an e,ample of USB suspend and resume (from stop>). The
USBUSuspend routine is called hen the suspend is issued by the host. The USB$1SU"1@ bit in the
USBCT4* register is set to enable the resume in stop> mode, then the USB state is changed to
USBUSUSP1@.. USBUSuspend routine calls the USBUHa!eup to enter stop> mode.
-n stop> mode, the "CU poer consumption decreases greatly, to appro,imately )F* [#. This value
is tested ith = 3 poer supply, CB- module enabled, USB in suspend mode, and all other modules
are off.
-n the USBUHa!eup routine, the USB bac!s to C?@'-(U$#T1. state hen the "CU is o!en up
by USB bus or other interrupt source. -f the "CU is a!en up by CB- interrupt, the USBUHa!eup
routine returns ) if it supports remote0a!eup. ?therise it returns *. The USBUHa!eup routine
returns ; if it is o!en by USB bus resume signal. The delay and chec! for $1SU"1' bit helps to
avoid the pseudo resume signal introduced by noise, because the $1SU"1' has enough time to be
set after the "CU is a!en up and the cloc! is recovered.
The USBUSuspend routine determines to call the UsbU$emoteUHa!eup routine, enters stop> mode, or
continues e,ecution according to the return value of USBUHa!eup.
The other interrupt source can also bring "C8S*9:"<* "CU out from stop> mode. The firmare
can use remote0a!eup to resume the USB bus or return to stop> mode according to the application
re+uirement. The $TC interrupt is disabled in 1,ample E in case the "CU is a!en up by $TC
interrupt.
1,ample E. USB Suspend and $esume $outine
void USBUSuspend(void)
V
unsigned char $esultK
&W -@T1@BU$1SU"1 S ;K W& &W"CU run mode, self0poeredW&
USBCT4*UUSB$1S"1@ S ;K &Wstop> mode, Bus0poeredW&
UsbU.eviceUState S USBUSUSP1@.K &WUSB state changesW&
&Wreturn at here, if it is self0poered, and does not eneter into stop>W&
$TCU.-SB#41()K &Wdisable $TCW&
do
V
$esult S USBUHa!eUp() K

if($esult SS ))
USBU$emoteUHa!eup()K
$TCU1@#B41()K
returnK
Z
unsigned char USBUHa!eUp(void )
V
int delayUcountK
asm ST?PK &W"CU enters stop>W&
UsbU.eviceUState S C?@'-(U$1.UST#T1K
if((X USBCT4*U4P$1S') YY (CbiUStat))
V
if(UsbUStat.BitCtl.$emoteHa!eup SS ;)
return )K
else
return *K
Z
else
V
delayUcount S =*K
do
V
delayUcount00K
Zhile(delayUcount)K
if(-@TST#TU$1SU"1')
V
return ;K
Z
else
return *K
Z
Z
-f the USB device does not need to enter stop> mode, the firmare can set $1SU"1 bit, clear
S411P' bit, and change the USB device state to suspend. #fter this, it can return to the main routine.
The 4P$1S' bit in USBCT4* is chec!ed in the USB interrupt service routine (USBU-S$ routine in
1,ample =). -t is set hen the USB device is resumed from stop> mode. The USB$1SU"1@ bit
must be cleared immediately to clear 4P$1S' I lo poer resume bit in USB -S$. The S411P' bit
is set hen the USB bus is idle for more than > ms. The firmare sets the UsbU.eviceUState to
H#-TUSUSP1@. and clears the S411P' bit in the USB interrupt routine.
The firmare calls USBUSuspend routine to avoid entering stop in the USB interrupt service routine
hen the USB state changes to H#-TUSUSP1@.. The H#-TUSUSP1@. state is a middle state that
is sitched to suspend instantaneously, so it does not appear in the USB state machine.
The USBU$emoteUHa!eup is called hen the remote0a!eup signal is issued by the USB device. -t
sets the C$1SU"1 bit in the CT4 register to generate the remote0a!eup signal on the USB bus,
then clears this bit in ;= ms.
1,ample =. USB Suspend and $esume Processing and $emote Ha!eup $outine
void interrupt F USBU-S$()
V
if(USBCT4*U4P$1S')
V
USBCT4*UUSB$1S"1@ S *K&Wclear this bit immediately
Z
^^ &WThe processing for other USB interrupt flagW&
if(-@TST#TUS411P')
V
UsbU.eviceUState S H#-TUSUSP1@.K
-@TST#TUS411P' S ;K
Z
returnK
Z
void USBU$emoteUHa!eup(void)
V
static ord delayUcountK
USBUHa!e'romUSuspend()K

CT4UC$1SU"1 S ;K &W Start $1SU"1 signalW&

delayUcount S 9***K &W Set $1SU"1 line for ;0;= msW&
do
V
delayUcount00K
Zhen(delayUcount)K

CT4UC$1SU"1 S *K &W Clear $1SU"1 signalW&
returnK
Z
4 S.mmary
USB PAM implements the physical layer of USB protocol.
The S-1 of the USB module implements the transferring and receiving logic. -t can complete most of
the USB lo0level protocol automatically. The programer immediately needs to set some registers and
read or rite data.
#ll )=< bytes of USB $#" are separate from "CU $#". -t provides the space for USB B.T and
data buffer of the endpoint. The ping0pong buffer can be used to improve the data throughput.
The USB device designer can use the on0chip or e,ternal regulator ith the pullup resistor.
Based on all the features described in this document, the "C8S*9:"<* USB module provides an
easy ay for the USB device development. The designer ill spend considerably less time on the lo
level of USB protocol. This enables efficient design of the USB stac! firmare.
The "C8S*9:"<* USB firmare design has also been discussed. The illustration for firmare
structure, USB initiali2ation, USB interrupt processing, the USB device state machine, the
implementation of control transfer for enumeration, and the USB suspend and resume provides a lot
of information for USB stac! design. Hith the A-. e,ample attached and detailed information that
must be noted during the design process given in this document, the designers can port the USB stac!
to their applications and focus on the application layer.
2ppendi? 2 %1e >irm:are for 6I/ Mo.se
#n e,ample pro%ect is provided for reference. The pro%ect is based on the "C8S*9:"<* .emo board
and CodeHarrior for AC(S)*9 3=.; ith the "C8S*9:"<* service pac!.
This pro%ect demonstrates the firmare design for an A-. class device and most of the detailed
information is illustrated in this application note. Mou can compile the pro%ect and donload it into the
"C8S*9:"<* demo board. #ttach it on the USB bus. The indos system (DP) can identify this
device. #fter that, the demo board can or! as a mouse.
2ppendi? B "n.meration Process of an 6I/ Mo.se
The enumeration process of A-. mouse is shos as follos. -t is captured by 4ecroy USB #naly2er.
Pro-ect@s Moti(ation
$ecent motivation for a separate USB ).* protocol engine stems from the fact that PCs have
increasingly higher performance and are capable of processing vast amounts of data. #t the
same time, PC peripherals have added more performance and functionality. User applications
such as multimedia applications demand a high performance connection beteen the PC and these
highly sophisticated peripherals.
The separate Protocol 1ngine addresses this need by or!ing in parallel ith the USB
5Controller hence releasing the microprocessor from the burden of dealing ith basic data
transfer assignments such as to!en encoding and decoding, C$C chec! etc. This architecture
ill increase the parallel or! of the USB device and increase its overall speed.
Today6s Aigh speed USB ).* compliant protocol engines are mostly firmare based and are not
hardare based. -n general firmare based solutions have much sloer response rate and are less
efficient than hardare based solutions, hoever in our case, since a high speed USB).* is re+uired
to deliver pac!ets at a ma,imum speed rate of only E9*"bps this is not much of an issue. Hith
an 90bit bus, the protocol engine ill have ;<.<< ms to handle each ord of data, hich
could be translated into a <* A2 cloc!. Today_s devices have cloc! rates of more than ;**C times
that. -n our case, the main motivation to use the hardare based solution is to reduce the poer
re+uirements for the device. This is a consideration especially for battery poered devices that
consume more than =3 and cannot use the USB built in poer supply.
%ec1nical Bac4+ro.nd
Introd.ction
The Universal Serial Bus (USB) is a specification developed by Compa+, -ntel,"icrosoft and
@1C, %oined later by Aelett0Pac!ard, 4ucent and Philips. These companies formed the USB
-mplementers 'orum, incorporated as a non0profit corporation to publish the specifications and
organi2e further development in USB. The USB is specified to be an industry0standard
e,tension to the PC architecture ith a focus on PC peripherals that enable consumer and
business applications. "ain goal of the USB protocol as to replace the over groing number of
different ports of PC connectivity. 'or e,ample, parallel, ps&) ports and serial could no be
replaced by one simple connection. The USB ill do the same role of all the replaced ports and
suitable for all applications and peripherals. USB ).* is an -ndustry0ide, host oriented
protocol, employing serial bus, supporting up to ;)F devices and hot insertion. Several criteria
ere applied in defining the architecture for the USB7 1ase0of0use for PC peripheral
e,pansion. USB ).* represents a great advance in speed hile !eeping a lo0cost solution that
supports transfer rates of up to E9* "bps. Hith full support for real0time data, voice, audio, and
video it is the chosen protocol for most PC peripherals today. Comprehension of various PC
configurations and form factors ma!e the USB a multifunctional protocol capable of servicing
various solutions. The USB is a generic protocol ma!ing its interface capable of +uic!
diffusion into product. #ugment the PC6s capability by enabling ne classes of devices giving the
USB a capability to be implemented in ne developed devices, advancing ith technology.
'ully bac!ard compatibility of USB ).* for devices built to previous versions of the USB
specification.
Rob.stness
The !ey advantage of the USB protocol is its robustness. The USB has signal integrity
hich enables it to use differential drivers, receivers, and shielding. C$C protection over
control and data fields. .etection of attach and detach and system0level configuration of resources.
Self0recovery in protocol, using timeouts for lost or corrupted pac!ets. 'lo control for
streaming data to ensure isochrony and hardare buffer management. .ata and control pipe
constructs for ensuring independence from adverse interactions beteen 'unctions.
"rror /etection
The core bit error rate of the USB medium is e,pected to be close to that of a bac!plane
and any glitches ill very li!ely be transient in nature. To provide protection against such
transients, each pac!et includes error protection fields. Hhen data integrity is re+uired, such
as ith lossless data devices, an error recovery procedure may be invo!ed in hardare or
softare. The protocol includes separate C$Cs for control and data fields of each pac!et. #
failed C$C is considered to indicate a corrupted pac!et. The C$C gives ;**` coverage on
single0 and double0bit errors.
"rror 6andlin+
The protocol allos for error handling in hardare or softare. Aardare error handling
includes reporting and retry of failed transfers. # USB Aost Controller ill try a transmission that
encounters errors up to three times before informing the client softare of the failure. The
client softare can recover in an implementation0specific ay.
/ata SpeedsA
The USB specification defines three data speeds7
Bo: Speed
This as intended for cheap, lo data rate devices li!e mice. The lo speed captive cable is thinner
and more fle,ible than that re+uired for full and high speed.
>.ll Speed
This as originally specified for all other devices.
6i+1 Speed
The high speed additions to the specification ere introduced in USB ).* as a response to
the high speed of 'ireire
/e(ice@s "ndpoints
#n endpoint is a uni+uely identifiable portion of a USB device that is the final stop of a
communication flo beteen the host and device. 1ach USB logical device is composed of
up to >* independent endpoints and a control endpoint. To reach an endpoint the host must
send a pac!et to the correct device address assigned by the system at device attachment time, and
the correct endpoint number given at the design time. 1ach endpoint has a device0determined
direction of data flo, up to ;= -@ and ;= ?UT endpoints are available and an additional control
endpoint hich is alays referred to as endpoint 2ero. The combination of the device address,
endpoint number, and direction allos each endpoint to be uni+uely referenced.

/escriptor %ables
USB devices report their attributes using descriptors. # descriptor is a data structure ith a
defined format. 1ach descriptor begins ith a byte0ide field that contains the total number of
bytes in the descriptor folloed by a byte0ide field that identifies the descriptor type. Using
descriptors allos concise storage of the attributes of individual configurations
because each configuration may reuse descriptors or portions of descriptors from other
configurations that have the same characteristics. -n this manner, the descriptors resemble
individual data records in a relational database.
/e(ice /escriptor %able
# device descriptor describes general information about a USB device. -t includes
information that applies globally to the device and all of the device6s configurations. # USB device
has only one device descriptor.

#ll USB devices have a .efault Control Pipe. The ma,imum pac!et si2e of a device6s .efault
Control Pipe is described in the device descriptor. 1ndpoints specific to a configuration and
its interface(s) are described in the configuration descriptor. # configuration and its
interface(s) do not include an endpoint descriptor for the .efault Control Pipe. ?ther than the
ma,imum pac!et si2e, the characteristics of the .efault Control Pipe are defined by this
specification and are the same for all USB devices.
Table ;* in the #ppendi, section shos the Standard .evice .escriptor Table.
#onfi+.ration /escriptor %able
The configuration descriptor describes information about a specific device configuration.
The descriptor contains a bConfiguration3alue field ith a value that, hen used as a parameter
to the SetConfiguration() re+uest, causes the device to assume the described configuration. The
descriptor b@um-nterfaces field describes the number of interfaces provided by the configuration.
1ach interface may operate independently. 'or e,ample, an -S.@ device might be
configured ith to interfaces, each providing <E Cb&s bi0directional channels that have
separate data sources or sin!s on the host. #nother configuration might present the -S.@ device
as a single interface, bonding the to channels into one ;)9 Cb&s bi0directional channel.
Hhen the host re+uests the configuration descriptor, all related interface and endpoint
descriptors are returned. # USB device has one or more configuration descriptors. 1ach
configuration has one or more interfaces and each interface has 2ero or more endpoints. #n
endpoint is not shared among interfaces ithin a single configuration unless the endpoint is
used by alternate settings of the same interface. 1ndpoints may be shared among interfaces
that are part of different configurations ithout this restriction.
Table ;; N Configuration .escriptor Table in the #ppendi, section shos the Configuration
.escriptor Table.

Interface /escriptor %able
The interface descriptor describes a specific interface ithin a configuration. # configuration
provides up to four interfaces, each ith 2ero or more endpoint descriptors describing a
uni+ue set of endpoints ithin the configuration. Hhen a configuration supports more than
one interface, the endpoint descriptors for a particular interface follo the interface
descriptor in the data returned by the (etConfiguration() re+uest. The descriptor contains a
b-nterface@umber field that specifies the number of the interface.
#n interface descriptor is alays returned as part of a configuration descriptor. -nterface
descriptors cannot be directly accessed ith a (et.escriptor() or Set.escriptor() re+uest.
1rrorX $eference source not found. in the #ppendi, section shos the -nterface .escriptor
Table.
"ndpoint /escriptor %able
1ach endpoint used for an interface has its on descriptor. This descriptor contains the information
re+uired by the host to determine the bandidth re+uirements of each endpoint. The
descriptor contains a b1ndpoint#ddress field that specifies the direction and endpoint
number. bm#ttributes field is used to determine the endpoint type (i.e Bul!, -sochronous,
Control or -nterrupt). "a,Pac!etSi2e field contains the value of the "a,imum pac!et si2e this
endpoint is capable of sending or receiving. 'or isochronous endpoints, this value is used to
reserve the bus time in the schedule, re+uired for the per0microframe data payloads. #n
endpoint descriptor is alays returned as part of the configuration information returned by a
(et.escriptor(Configuration) re+uest. There is never an endpoint descriptor for endpoint 2ero.
Table ;> in the #ppendi, section shos the 1ndpoint .escriptor Table.
%o4en Pac4ets
# to!en pac!et consists of a P-., #..$ and 1@.P fields. Table ) shos the field formats
and their respective number of bits. Pac!et -. specifies either -@, ?UT or S1TUP pac!et
type. P-. codes table is available in Table ;E in the #ppendi,. 'or ?UT and S1TUP
transactions, the address and endpoint fields uni+uely identify the endpoint that ill receive the
subse+uent .ata pac!et. 'or -@ transactions, these fields uni+uely identify hich endpoint
from a uni+ue addressed device should transmit a .ata pac!et. ?nly the host can issue
to!en pac!ets. #n -@ P-. defines a data transaction from a function to the host. ?UT and
S1TUP P-.s define data transactions from the host to a function. The to!en6s correctness is
assured by the combination of to mechanisms. The E bits representing the P-. field are
duplicated and negated to become 9 bits long. The #..$ and 1@P. fields are protected by the
C$C= field.
/ata Pac4ets
# data pac!et consists of a P-., data field containing 2ero or more bytes of data, and a C$C;< as
shon in Table E. There are four types of data pac!ets, identified by different P-.s7 .#T#*,
.#T#;, .#T#) and ".#T#. .#T#* and .#T#; are defined to support data toggle
synchroni2ation in bul!, setup and interrupt transactions. #ll four data P-.s are used in data
P-. se+uencing for high bandidth high0speed isochronous endpoints. .ata must alays be sent
in integral even number of bytes. Similar to the to!en pac!et, the data C$C;< is computed over
only the data field in the pac!et and does not include the P-., hich has its on chec! field.
6ands1a4e Pac4ets
Aandsha!e pac!ets, as shon in 1rrorX $eference source not found., consist of only a P-..
Aandsha!e pac!ets are used to report the status of a data transaction.
#ssuming successful to!en decode, a device, upon receiving a data pac!et, may return any
one of the three handsha!e types7
B -f the data pac!et as corrupted, the function returns no handsha!e.
B -f the data pac!et as received error0free and the function6s receiving endpoint is halted,
the function returns ST#44.
B -f the transaction is maintaining se+uence bit synchroni2ation and a mismatch is
detected, then the function returns #CC and discards the data.
B -f the function can accept the data and has received the data error0free, it returns #CC.
B -f the function cannot accept the data pac!et due to flo control reasons li!e out of space, it
returns @#C.
Upon receiving a S1TUP to!en, a device must accept the data. # device may not respond
to a S1TUP to!en ith either ST#44 or @#C, and the receiving device must accept the data
pac!et that follos the S1TUP to!en. -f a non0control endpoint receives a S1TUP to!en, it
must ignore the transaction and return no response. -sochronous transactions have a to!en and data
phase, but no handsha!e phase. The host issues an ?UT to!en folloed by the data phase in
hich the host transmits data. -sochronous transactions do not support a handsha!e
phase or retry capability.
Set.p Pac4et
1very USB device must respond to re+uests from the host on the device6s endpoint 2ero. The setup
pac!ets are used for detection and configuration of the device and carry out common functions
such as setting the USB device6s address, re+uesting a device descriptor or chec!ing the status
of an endpoint. These re+uests are made using control transfers hich ill be discussed
later on. The re+uest and the re+uest6s parameters are sent to the device in the Setup pac!et.
1very Setup pac!et has eight bytes ith the folloing fields7 bm$e+uestType N ?ne byte field
hich identifies the characteristics of the specific re+uest. -n particular, this field identifies the
direction of data transfer in the second phase of the control transfer. The state of the .irection bit is
ignored if the 4ength field is 2ero, signifying there is no .ata stage. The bitmap
ofbm$e+uestType field is specified in the table belo.
b$e+uest N This 9 bit field specifies the particular re+uest based on the Table < N
b$e+uest codes belo.
3alue N To byte field ith variable content according to the re+uest. -t is used to pass a
parameter to the device, specific to the re+uest.
-nde, N To byte field ith variable content according to the re+uest. -t is used to pass a
parameter to the device, specific to the re+uest. The -nde, field is often used in re+uests to specify
an endpoint or an interface.
4ength 0 To byte field hich specifies the length of the data transferred during the second
phase of the control transfer. The direction of data transfer (host0to0 device or device0to0
host) is indicated by the .irection bit of the bm$e+uestType field. -f this field is 2ero, there is
no data transfer phase.
"n.meration Process
#fter a device is poered on it must follo the enumeration process to receive an address from the
host and configuration. Hhen in poered state it must not respond to any bus transactions until it
has received a reset from the bus. #fter receiving a reset, the device is then addressable at the
default address. Then the system enters the Aigh Speed Aandsha!e .etection protocol hich
includes the detection of a series of at least si, :0C0:0C0:0C chirps terminated by S1* as
described in 'igure ). The device then enters high speed mode and sitch to a .efault State.
The device then aits for a setup to!en hich precedes the setup pac!et for
theS1TU#..$1SS re+uest. #fter the setup to!en has been received correctly, the host ill
send a setup pac!et to endpoint 2ero, ith address 2ero and ith pac!et -. .#T#*. The
setup pac!et contains the S1TU#..$1SS re+uest hich contains the device ne address
assigned by the host. The ne address is saved in the 3alue field of the setup pac!et
(see Table F for 3alue description). #fter the device changes its address it enters the
#ddressed state.
The device ill enter its final state called Configured State hich starts once the device
receives the S1TUC?@'-(U$#T-?@ re+uest ith a non02ero 3alue field.
USB #omm.nications >lo:
#ll communications on the USB bus are initiated by the host. This means, for e,ample,
that there can be no communication directly beteen USB devices. # device cannot initiate
a transfer, but must ait to be as!ed to transfer data by the host. -n any USB system there
is only one host and up to ;)F peripherals. The attached peripherals share USB bandidth
through a host scheduled, to!en0based protocol
The USB is a polled bus. 1ach transaction begins hen the host controller, on a scheduled basis,
sends a USB pac!et describing the type and direction of transaction, the USB device address, and
the endpoint number. This pac!et is referred to as the to!en pac!et. The USB device that is
addressed selects itself by decoding the appropriate address fields from the to!en pac!et. -n a given
transaction, data is transferred either from the host to the device or from the device to the host. The
source of the transaction then sends a data pac!et. -f transfer as successful the destination,
e,cluding isochronous type of transactions, responds ith a handsha!e pac!et indicating the
transfer as successful.
Transaction Types
The USB architecture comprehends four basic types of data transfers7
;. Control Transfers 0 Control data is used by the USB System Softare to configure devices
hen they are first attached. "andatory using 1ndpoint * ?UT and 1ndpoint * -@.
). Bul! Transfers 0 Bul! data typically consists of larger amounts of data, such as that
used for printers or scanners. Bul! data is se+uential. $eliable e,change of data is ensured.
Bul! transfers are designed to transfer large amounts of data ith error0free delivery,
but ith no guarantee of bandidth. The host ill schedule bul! transfers after the
other transfer types have been allocated.
>. -nterrupt Transfers 0 # limited0latency transfer to or from a device is referred to as interrupt
data. Such data may be presented for transfer by a device at any time and is
delivered by the USB at a rate no sloer than is specified by the device
E. -sochronous Transfers N -sochronous data is continuous and real0time in
creation, delivery, and consumption. Timing0related information is implied by the
steady rate at hich isochronous data is received and transferred. -sochronous
data must be delivered at the rate received to maintain its timing. # typical e,ample of
isochronous data is voice. The timely delivery of isochronous data is ensured at the
e,pense of potential transient losses in the data stream, here it is important to
maintain the data flo, but not so important if some data gets missed or corrupted.
-n other ords, any error in electrical
transmission is not corrected by hardare mechanisms such as retries.
/ata %o++le Sync1roniCation
The USB provides a mechanism to guarantee data se+uence synchroni2ation beteen data
transmitter and receiver across multiple transactions. This mechanism provides a
means of guaranteeing that the handsha!e phase of a transaction as interpreted correctly
by both the transmitter and receiver. Synchroni2ation is achieved via use of the .#T#*
and .#T#; P-.s and separate data toggle se+uence bits for the data transmitter and
receiver. $eceiver se+uence bits toggle only hen the receiver is able to accept data and receives
an error0free data pac!et ith the correct data P-.. Transmitter se+uence bits toggle only hen the
data transmitter receives a valid #CC handsha!e. The data transmitter and receiver must
have their se+uence bits synchroni2ed at the start of a transaction. The synchroni2ation
mechanism used varies ith the transaction type. .ata toggle synchroni2ation is not supported for
isochronous transfers.