usb project book

8/10/2019 USB Project Book

1/60

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

Proect &.ide

/ Rama risna

2ssitant Professor

3smania Uni(ersity


2/60

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 eternal). The -nput section of transceiver ill be interfaced ith

"C&'P#(internally or eternally) 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.


3/60

Proect 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.l a reliable transfer that includes the handsha!e phase.

Isocrono.s real0time, saves overhead by ecluding handsha!e phase.

Interr.pt a limited0latency transfer to or from a device.

The Protocol 1ngine pro%ect as donloaded into 8S*9 development board for simulation and

verification.


4/60

62R/2R" /"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.


5/60

"-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 ;

"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

irect0page registers (***** through ***#')

Aigh0page registers (*;9** through *;9=')

@onvolatile registers (*''B* through *''B')


6/60

Bloc! iagram of "C8S*9:";< 7

The 90bit "C8S*9:";< device further etends 'reescale6s entry0level 90bit embedded USB

controller family ith up to ;< B 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 CC 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'

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

?ffers strong performance throughout the

entire

voltage range

Support for up to > peripheral interrupt&

re+uest resources

#llos for eceptional softare fleibility and

optimi2ation for real0time applications

3n-#ip Memory

Up to ;


7/60

'lash contents help to reduce system poer

consumption

=< Byte USB $#" -mprove data transfer speed by providing

data buffering

Po:er-Sa(in+ Modes

Hait plus to stop modes #llos continuation of sampling applicationin a reduced

poer state hich reduces system poer

consumption

"ulti0purpose cloc! generator ("C) 're+uency0loc!ed loop ('44)7 -nternal or

eternal

reference can be used to control the '44

Phase0loc!ed loop (P44)7 3oltage controlled

oscillator (3C?). "odulo 3C? fre+uency

divider.

4oc! detector ith interrupt capability -nternal reference cloc!7 Can be selected as

the

cloc! source for the "CU

1ternal 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.

$eference divider provided

Cloc! source can be divided by ;, , E or 9

Peripherals USB device module 'ull0speed USB .* (; "bps) module ith

dedicated on0chip >.>3 regulator

Supports control, interrupt, isochronous and

bul! transfers

#nalog comparators (#C"P)I#nalog

comparator ith option to compare to

internal reference

$e+uires only single pin for input signal,

freeing up

other pin for other use

#llos other system components to see

comparator result ith minimal delay

Can be used for single slope #C and $Ctime

constant measurements

#nalog0to0digital converter (#C)I1ight0

channel, ;0bit resolution

?utput formatted in ;0, ;*0 or 90bit

right0%ustified format

Single or continuous conversion

?peration in lo0poer modes for loer

noise operation

#synchronous cloc! source for loer

noise operation

To serial communications interface(SC-) modules offering asynchronous

communications

Provides standard U#$T communicationsperipheral

#llos full0duple, asynchronous, @$J serial


8/60

communication beteen "CU and remote

devices

- C ith up to ;** !bps ith maimum bus

loadingK multi0master operationK programmable

slave addressK interrupt driven byte0by0byte

data transferK supports broadcast mode and

;*0bit addressing

#bility to add an additional - C device

SP-ITo serial peripheral interfaces ith

full0duple or single0ire bidirectionalK double0

buffered transmit and receiveK master or slave

modeK "SB0first or 4SB0first shifting

Aaving to SP- allos to separate dedicated

devices, for eample, one SP- dedicated to a

JigBee L transceiver, and the other to "CUs or

peripherals

Timer pulse idth modulation (TP")IUp to

si channels

1ach channel may be input capture, output

compare or edge0aligned PH"

-nput capture trigger on either rising or falling

edge

Selectable polarity on PH" outputs

Timer cloc! source selectable as prescaled bus

cloc!, fied system cloc! or an eternal cloc!

pin

Inp.t;3.tp.t

Up to seven eyboard -nterrupt (B-) pins

ith

selectable polarity

1ach B- pin is programmable as falling edge

only,

rising edge only, falling edge and lo level, or

rising

edge and high level interrupt sensitivity

>F general purpose input&output (P-?)s $esults in a large number of fleible -&? pinsthat

allo vendors to easily interface the device into

their on designs

System Protection

Hatchdog computer operating properly (C?P)

reset ith option to run from dedicated ; !A2

internal cloc! source or bus cloc!

#llos the device to recogni2e run0aay code

(infinite loops) and resets the processor to help

avoid loc!0up states

4o0voltage detection ith reset or interruptK

selectable trip points

#lerts the developer to voltage drops outside

of the

typical operating range

-llegal op code detection ith reset #llos the device to recogni2e erroneous code

and

resets the processor to help avoid loc!0up states

'lash bloc! protection Prevents unauthori2ed access to flash $#"

hich

greatly reduces the chance of losing vital system

code for vendor applications

6ard:are /e(elopment S.pport

Single0ire bac!ground debug interface This allos developers to use the sameinterface

for multiple platforms


9/60

Brea!point capability #llos single brea!point setting during in0

circuit

debugging (plus to more brea!points in on0

chip

debug module)

?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.

rants full access to built0in chip emulation

ithout

the added epense of traditional emulator

hardare


10/60

USB /e(ice /e(elopment :it M#S09


11/60

-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 signals, start of pac!et (S?P), and resume

signals. The USB PAM of "C8S*9:"


12/60

!,1 USB "ndpoint

?ne important concept needs to be discussed before eplaining 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:".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 eternal pullup resistor.

The on0chip regulator can be enabled or disabled by USB3$1@ bit of the USBCT4* register. -f it

isdisabled, an eternal >.> 3 voltage must be provided to USB module via 3USB>.> pin.


13/60

83%"

amage to the part may occur if the eternal >.> 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 USBP 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 (#C) or non0ac!noledge (@#) handsha!e to the host. -t also

stalls the current transfer (ST#44). The handsha!e is enabled or disabled by the 1PASA bit in the

1PCT4n register. -f it is enabled, #C is transferred to the host hen the transaction is correctly

received. The @# 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 BTST#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.


14/60

.= USB $#"

"C8S*9:", the USB $#" address range is from *;9


15/60

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 BT locates at the beginning of USB $#". The Bs for seven endpoints are organi2ed and

placed one by one from 1P* in to 1P< out. There are ;* Bs in total and >* bytes are allocated from

*;9


16/60

The bitQ=7R 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 net 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 BTST#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 net 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 maimum length is


17/60

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 maimum 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 maimum value I the data that eceeds

the maimum 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#Q87R 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


18/60

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@ ;), endpoint * ill receive #T#* (#T#*&; *) pac!et, and the data toggle has been

enabled (TS ;), the correct data pac!et is received (ST#44 *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 eact data length is updated and ritten to BC register.

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 maimum 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 siteen 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?@1' bit is set, and the CPU

becomes the control of the B and endpoint buffer (?H@ *). '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 net transaction.


19/60

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?@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 net 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:"


20/60

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 Bs and their attached buffersare 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


21/60

) USB /e(ice /e(elopment

>.; Aardare esign

Aardare design for USB device ith "C8S*9:"


22/60

hile (("CSC Y *E9) X *E9)K &WHait for the P44 to be loc!ed W&

&WSitch to P11 mode from PB1 modeW&

"CC; Y *>'K &WP44 output is selectedW&

hile(("CSC Y *


23/60

-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.

Bus0Poered

Bus0poered USB devices are poered from the USB bus. The maimum 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.

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 eternal 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 B- 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:".> pin and the USBP pin. See the connection mar!ed ith dash line in 'igure 9.


24/60

@?T1

The USB device can use internal pullup resistor or eternal 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 ofthe combinations according to actual re+uirement.


25/60

),! 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 softareon 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:"


26/60

'igure ;; shos to flo charts of a USB firmare eample designed ith "C8S*9:"


27/60

Hhen the USB device is in suspend mode, the resume interrupt flag and the resume interruptprocessing 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, #$*),

and return to the state before enumeration begins.


28/60

The T?@1' bit is set hen one transaction is complete. The processing of T?@1' is the main

entry for all transactions.

The interrupt flag must be cleared after it is serviced. ?therise the interrupt is eecuted again and

again, ithout stopping.

),!,) USB State Macine

USB device has the folloing states7

Poered7 USB device is not attached to the USB bus, but the "CU has been poered on.

#ttached7 USB device is attached to the USB bus, but enumeration has not started

efault7 USB device is reset by the host

#$P1@-@7 USB device receives the Set#ddress command from the host

#ddressed7 The Set0#ddress command has eecuted successfully.

Configured7 The USB device receives and eecutes the SetConfiguration command successfully.

Suspend7 The USB device enters suspend mode.


29/60

'igure ;> shos the sitches of the USB state machine. The suspend and reset mode can be entered

from all states ecept the poered state.

The bus0poered USB device sets its state to attached directly after it is attached to the USB bus.

The state of #$P1@-@ is set hen USB device receives the Set#ddress setup to!en. -t ischanged to #$1SS1 hen the Set#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 eample 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


30/60

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

BT is located at the beginning of the USB $#". Because the location of B assigned for different

endpoint is fied, you can define the folloing data structure for BT access (defined ith C

language).

1ample . ata Structure for BT #ccess

typedef union BST#T

V

byte byteK

structV

unsigned 7;K

unsigned 7;K

unsigned BTST#447;K &WBuffer Stall 1nableW&

unsigned TS7;K &Wata Toggle Synch 1nableW&

unsigned 7;K &W#ddress -ncrement isableW&

unsigned 7;K &WB eep 1nableW&

unsigned #T#7;K &Wata Toggle Synch 3alueW&

unsigned ?H@7;K &WUSB ?nershipW&

Z"cuCtlBitK


31/60

structV

unsigned 7;K

unsigned 7;K

unsigned P-*7;K

unsigned P-;7;K

unsigned P-7;K


32/60

unsigned P->7;K

unsigned 7;K

unsigned ?H@7;K

ZSieCtlBitK

structV

unsigned 7K

unsigned P-7EK &WPac!et -dentifierW&

unsigned 7K

Z$ecPidK

Z BST#TK &WBuffer escriptor Status $egisterW&

typedef struct BU''SC

V

BST#T StatK

byte CntK

byte #ddrK &WBuffer #ddressW&

Z BU''SCK &WBuffer escriptor TableW&

typedef struct BT"#P

V

BU''SC ep*BiK &W1ndpoint * B -nW&

BU''SC ep*BoK &W1ndpoint ; B ?utW&

BU''SC ep;BioK &W1ndpoint ; B -@ or ?UTW&

BU''SC epBioK &W1ndpoint B -@ or ?UTW&

BU''SC ep>BioK &W1ndpoint > B -@ or ?UTW&

BU''SC epEBioK &W1ndpoint E B -@ or ?UTW&


33/60

BU''SC ep=Bio1venK &W1ndpoint = B -@ or ?UT 1venW&

BU''SC ep=Bio?ddK &W1ndpoint = B -@ or ?UT ?ddW&

BU''SC ep


34/60

byte #ddrK &WBuffer #ddressW&

Z BU''SCK &WBuffer escriptor TableW&

typedef struct BT"#P

V

BU''SC ep*BiK &W1ndpoint * B -nW&

BU''SC ep*BoK &W1ndpoint ; B ?utW&

BU''SC ep;BioK &W1ndpoint ; B -@ or ?UTW&

BU''SC epBioK &W1ndpoint B -@ or ?UTW&

BU''SC ep>BioK &W1ndpoint > B -@ or ?UTW&

BU''SC epEBioK &W1ndpoint E B -@ or ?UTW&

BU''SC ep=Bio1venK &W1ndpoint = B -@ or ?UT 1venW&

BU''SC ep=Bio?ddK &W1ndpoint = B -@ or ?UT ?ddW&

BU''SC ep


35/60

'irmare defines the endpoint buffers and assigns them in USB $#", that can be accessed

directly.1P*?utBufQ9R is defined and fied to *;98*.

>..E. Control Transfer

Control transfer has three stages. They are the setup, data, and status stages. To control transfer, thedata stage can be omitted, e.g, Set#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.

H#-TS1TUPT?1@7 before the beginning of the control transfer

CT4T$'#T#TD7 send data to the host (in direction) in current or the net transaction

CT4T$'#T#$D7 receive data from the host (out direction) in current or the net 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#-TS1TUPT?1@. The firmare determines the net state is

CT4T$'#T#TD or CT4T$'#T#$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 eample. 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.


36/60

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 CT4T$'#T#TD and

CT4T$'#T#$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.


37/60

),!,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?@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.


38/60

The T?@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 CT4T$'#T#TD (or

CT4T$'#T#$D) from H#-TS1TUPT?1@ 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 net 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

maimum length supported by the endpoint. The B registers are also updated according to the

re+uirements.

#t last, the CT4TSUSP1@ bit in the CT4 register is cleared for processing the net 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 CT4T$'#T#$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 net

transaction.

-f the control transfer state is CT4T$'#T#TD 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

net transfer.

-f this transaction is for endpoint *, e add a supplementary chec! for the USB state. Hhen the USB

Set#ddress standard re+uest is issued, the USB state is changed to #$P1@-@ in the first

transaction of this transfer. #n in transaction is issued no.

-n the status stage of Set#ddress transfer, the ne USB device address is ritten to the USB address


39/60

register. -f the USB state is not #$P1@-@, 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?@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


40/60

&Wadd the code for other endpointsW&

Z

returnK

Z

-n 1ample >, 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-$ecata routine. The

A-$ecata 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 1PASA 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:" 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:"


41/60

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:"). The

USBSuspend 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

USBSUSP1@. USBSuspend routine calls the USBHa!eup to enter stop> mode.

-n stop> mode, the "CU poer consumption decreases greatly, to approimately F* [#. This value

is tested ith = 3 poer supply, B- module enabled, USB in suspend mode, and all other modules

are off.

-n the USBHa!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 B- interrupt, the USBHa!euproutine returns if it supports remote0a!eup. ?therise it returns *. The USBHa!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 USBSuspend routine determines to call the Usb$emoteHa!eup routine, enters stop> mode, or

continues eecution according to the return value of USBHa!eup.

The other interrupt source can also bring "C8S*9:"


42/60

unsigned char $esultK

&W -@T1@B$1SU"1 ;K W& &W"CU run mode, self0poeredW&

USBCT4*USB$1S"1@ ;K &Wstop> mode, Bus0poeredW&

UsbeviceState USBSUSP1@K &WUSB state changesW&

&Wreturn at here, if it is self0poered, and does not eneter into stop>W&

$TC-SB#41()K &Wdisable $TCW&

do

V

$esult USBHa!eUp() K

if($esult )

USB$emoteHa!eup()K

$TC1@#B41()K

returnK

Z

unsigned char USBHa!eUp(void )

V

int delaycountK

asm ST?PK &W"CU enters stop>W&

UsbeviceState C?@'-U$1ST#T1K

if((X USBCT4*4P$1S') YY (biStat))

V

if(UsbStat.BitCtl.$emoteHa!eup ;)

return K


43/60

else

return *K

Z

else

V

delaycount =*K

do

V

delaycount00K

Zhile(delaycount)K

if(-@TST#T$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 (USB-S$ routine in

1ample =). -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 UsbeviceState to

H#-TSUSP1@ and clears the S411P' bit in the USB interrupt routine.

The firmare calls USBSuspend routine to avoid entering stop in the USB interrupt service routine


44/60

hen the USB state changes to H#-TSUSP1@. The H#-TSUSP1@ state is a middle state that

is sitched to suspend instantaneously, so it does not appear in the USB state machine.

The USB$emoteHa!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.

1ample =. USB Suspend and $esume Processing and $emote Ha!eup $outine

void interrupt F USB-S$()

V

if(USBCT4*4P$1S')

V

USBCT4*USB$1S"1@ *K&Wclear this bit immediately

Z

^^ &WThe processing for other USB interrupt flagW&

if(-@TST#TS411P')

V

UsbeviceState H#-TSUSP1@K

-@TST#TS411P' ;K

Z

returnK

Z

void USB$emoteHa!eup(void)

V

static ord delaycountK

USBHa!e'romSuspend()K


45/60

CT4C$1SU"1 ;K &W Start $1SU"1 signalW&

delaycount 9***K &W Set $1SU"1 line for ;0;= msW&

do

V

delaycount00K

Zhen(delaycount)K

CT4C$1SU"1 *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 BT 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 eternal regulator ith the pullup resistor.

Based on all the features described in this document, the "C8S*9:"


46/60

2ppendi? 2 %e >irm:are for 6I/ Mo.se

#n eample pro%ect is provided for reference. The pro%ect is based on the "C8S*9:"


47/60

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.


48/60

Proect@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 maimum speed rate of only E9*"bps this is not much of an issue. Hith

an 90bit bus, the protocol engine ill have ;


49/60

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 epected 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

o: Speed


50/60

This as intended for cheap, lo data rate devices li!e mice. The lo speed captive cable is thinner

and more fleible than that re+uired for full and high speed.

>.ll Speed

This as originally specified for all other devices.

6i+ 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.


51/60

/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 maimum 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

maimum 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


52/60

descriptor b@um-nterfaces field describes the number of interfaces provided by the configuration.

1ach interface may operate independently. 'or eample, an -S@ device might be

configured ith to interfaces, each providing


53/60

%oen Pacets

# 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 issueto!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 Pacets

# 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.

6andsae Pacets

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.


54/60

#ssuming successful to!en decode, a device, upon receiving a data pac!et, may return any

one of the three handsha!e types7

-f the data pac!et as corrupted, the function returns no handsha!e.

-f the data pac!et as received error0free and the function6s receiving endpoint is halted,

the function returns ST#44.

-f the transaction is maintaining se+uence bit synchroni2ation and a mismatch is

detected, then the function returns #C and discards the data.

-f the function can accept the data and has received the data error0free, it returns #C.

-f the function cannot accept the data pac!et due to flo control reasons li!e out of space, it

returns @#.

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 @#, and the receiving device must accept the datapac!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 Pacet

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 isignored if the 4ength field is 2ero, signifying there is no ata stage. The bitmap

ofbm$e+uestType field is specified in the table belo.


55/60

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.


56/60

"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 :00:00:0 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

theS1T#$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 S1T#$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 S1TC?@'-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 eample,


57/60

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,

ecluding isochronous type of transactions, responds ith a handsha!e pac!et indicating the

transfer as successful.


58/60

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 echange 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 eample of

isochronous data is voice. The timely delivery of isochronous data is ensured at the

epense 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


59/60

transmission is not corrected by hardare mechanisms such as retries.

/ata %o++le SyncroniCation

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 #C 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 forisochronous transfers.


60/60

usb project book

Documents