embedding usb - the implementation challenges and limitations · there is a suspend mode (no bus...

Renesas Electronics America Inc.© 2012 Renesas Electronics America Inc. All rights reserved.

Embedding USB - The Implementation Challenges and Limitations

Micriµm

© 2012 Renesas Electronics America Inc. All rights reserved.2 Micriµm

Renesas Technology & Solution Portfolio


Hardware Architecture

Mechanical Specifications

Electrical Specifications

Software Specifications

Compliance

Final Comments

Agenda


Universal Serial Bus: Serial bus standard to interface devices. Peripheral communication protocol of choice for keyboards,

printers, and memories Automatic error detection and recovery. Large number of devices. (127) Replaced RS-232 This document covers USB and differentiate USB Host

protocol stack from USB Device protocol stack and On-The-Go. It goes over the design implications and some solutions.

USB for Embedded Systems


USB Products

http://images.google.ca/imgres?imgurl=http://www.edgetechcorp.com/Repository/ProductImages/0/DiskGO!-USB-Watch-Drive.gif&imgrefurl=http://www.edgetechcorp.com/store/EDGDM00USBWATCH.htm&h=413&w=208&sz=34&hl=en&start=8&tbnid=ezGuvJI4bYIpNM:&tbnh=121&tbnw=60&prev=/images?q=USB&svnum=10&hl=en&lr=�

http://us.st11.yimg.com/us.st.yimg.com/I/meritline_1954_81605082�

http://images.google.com/imgres?imgurl=http://www.core77.com/corehome/dlite.jpg&imgrefurl=http://www.core77.com/blog/archive/200506.asp&h=382&w=312&sz=21&hl=en&start=7&um=1&tbnid=Gr_S8vlMMlgAWM:&tbnh=123&tbnw=100&prev=/images?q=USB+accessories<&svnum=10&um=1&hl=en&rls=com.microsoft:en-us:IE-SearchBox&rlz=1I7GGLG&sa=N�

http://headsetplus.com/product426/product_info.html�

http://www.google.com/product_url?q=http://adfarm.mediaplex.com/ad/ck/711-5256-8196-2?loc=http://cgi.ebay.com/SONY-Silver-1GB-USB-2-0-Walkman-MP3-Player-NWE003F_W0QQitemZ320136248769QQcmdZViewItem&fr=ADEFi94RyEAt8Av44TDkI-JjhBaAOyGc7AAAAAAAAAAA&gl=us&hl=en�


1969 Serial port (RS-232C)

1995 The USB consortium is formed by Compaq, DEC, IBM, Intel, Microsoft, NEC and Nortel.

1996 USB 1.0 standard was released. Plug Fest

1999 USB 1.1 was released. Corrected bugs

2000 USB 2.0 was released specifying the implementation of a 480 Mbps bus

2001 USB On-The-Go (OTG) supplement was added which allowed devices to talk to each other

2005 Wireless USB standard was released which is a point to point wireless communications link

2008 USB 3.0 delivers over 10 times the speed of USB 2.0

Brief History


USB 2.0

Star network configuration

Only one host

Maximum of seven levels of tiers, hub at center

Host and hubs provide power to slaves

Maximum of 5m per cable

Maximum of 127 devices (hubs included)

Host schedules and initiates data transfers

Devices implements one or more functions

Architecture Topology

USB Speed Low Speed Full Speed High Speed

Speed 1.5 Mbits/sec 12 Mbits/sec 480 Mbits/sec

USB 1.1


USB 1.1 OHCI – Compaq, Microsoft, and National; hardware burden UHCI – Intel, software burden

USB 2.0 EHCI – USB with Intel, simplified software and reduced cost

USB 3.0 SuperSpeed - Hewlett-Packard, Intel, Microsoft, NEC, NXP

Semiconductors and Texas Instruments November 17, 2008 The first certified USB 3.0 consumer products were announced

January 5, 2010

Host Controllers


Device A device is a logical or physical entity that performs one of more

functions.

Composite device A composite device has one address but multiple interfaces or

association of interfaces each providing a function (i.e. a multi-function printer, scanner, fax, copier)

Compound device A compound device contains a hub with one or more

permanently attached devices. A host treats the hub and its functions as if they were separate physical devices.

Device


Compound Device

HostRoot Hub

Device Device

DeviceDevice

Device

DeviceDevice

Hub Hub

Root Hub (RH) = embedded hub part of the Host Provides 1 or more attachment points

(i.e. ports) Equivalent to external Hub

– Presents standard hub functions

– Presents standard states as other USB devices

Host and Root Hub

Responsible for: Device connection/disconnection Device reset Port power


When the Host stack starts, the 1st device to be enumerated is always the Root Hub (RH).

During enumeration, the RH returns the Hub descriptor which contains features supported by the RH. bNbrPorts: Number of downstream facing ports that this hub

supports Hub driver (part of Host core layer) will handle hub events: Device attachment/detachment event Port power/enable/reset/suspend/resume events

Host and Root Hub

Host stack

Host controller

Hub

Function 1

Function 2

Function 3

Por

t 1P

ort 2

Root HubHub descriptor

Enumerating RH

Enumerating Function 1

Enumerating HubHub descriptor

Enumerating Function 2 & 3

bNbrPorts = 2

bNbrPorts = 2



Cable:• Cable is made of 4 28-AWG conductors:

– Vbus Power Red – Gnd Power Black – D+ Data Green – D- Data White

• Data pair is twisted• Maximum cable length is 5 meters

Connector:• Connector Type A connects to host• Connector Type B connects to device• Connector power pins are longer for hot-swap

1 2 3 4

Type A USB Connector

Type B USB Connector

12

3 4

D+ D- +-

D+

D-+

-


Mini-B Plug

Mini connectors were added in USB 2.0 and OTG supplement

An alternative to the standard B connector on handheld and portable devices. The mini-B connecter has a fifth pin, named ID. It is not connected.

Vbus Power Red Gnd Power Black D+ Data Green D- Data White Shell Drain wire ID No connection

Mini-B USB Connector

1 2 3 4 5


ContactNumber

Signal Name

Typical WiringAssignment

1 VBUS Red2 D- White

3 D+ Green4 ID <10Ω = Micro-A

>100kΩ = Micro-B

5 GND Black

Shell Shield Drain Wire

Micro connector Pin Assignments

OTG Connectors

Micro-A USB Connector

Micro-B USB Connector

15

White insulator

15

Black insulator


Electrical Specifications


The complexities and speed of the USB protocol are such that it is not practical to expect a general purpose microcontroller to be able to implement the protocol using an instruction-driven basis.

Dedicated hardware is required to deal with the time-critical portions of the specification, and the circuitry grouping which performs this function is referred to as the Serial Interface Engine (SIE).

Serial Interface Engine


Device Detection

Current is limited to 100mA Either the D+ or the D- line will be pulled high D+ is high, the device is a full or high speed D- is high, the device is a low speed

High Speed negotiation protocol occurs during the Bus Reset phase After detecting the reset signal, the high speed device will signal the host

with a 480 Mbps chirp

Host Controller Device Controller

Vbus Vbus

D+ D+

D- D-

Gnd Gnd

1.5K

15K 15K

USB Cable

Current Limiter


The USB bus 5V supply is a very attractive feature. A USB device with a single connection is also attractive to the user

Supply voltage can fall to 4.35V at the device When other devices are being plugged, there can be transients

lowering the supply voltage by 0.4V

Devices can be classified as:– Bus powered– Self powered– Hybrid powered

Device Powering


Self-powered devices provide power requirements on descriptor (see descriptor in the software section). Initially provides 100mA, this can be increased up to 500mA (high power)

Self-powered hubs have a limitation on self-powered devices of 100mA

A device may draw up to 500mA after it has been configured as a high-power device. Being configured is dependent on the Hub being able to supply 500mA, which implies a self-powered hub. So there is always a degree of uncertainty whether more than 100mA will be available. It is a good design practice to offer the option of external power via a socket on such a device.

Devices requiring more than 500mA are obliged to be self-powered. (It is dangerous to attempt to draw power from two adjacent USB ports using a modified cable. It is not permitted by the specification and can easily damage the ports)

Device Powering


There is a suspend mode (no bus activity). In suspend mode, devices consume up to 500µA (where 200 µA already used by the pull up and pull-down resistors)

Devices containing a micro-controller need a sleep mode which meets this requirement. Do not forget that a badly placed resistor can very easily draw current which you hadn't expected. Measure your suspend current with a meter

High power devices (up to 500 mA) with remote wakeup feature enabled are allowed to draw up to 2.5mA during suspend

This suspend condition will occur at least once before the device is configured

Device Powering


Place a capacitance of at least 1uF across Vbus and GND to prevent from flyback voltage when unplugging a cable at the far end from the device

The maximum value of the shunt capacitor across Vbus and GND is limited by the specification to 10uF. This is to avoid other devices to crash because plugging device in, a capacitance between Vbus and GND will cause a dip in voltage across the other ports of the hub

For the same reason, the hub port supply must be bypassed with at least 120uF

Hot-Pluggable


If you pull, say D+, high in the absence of Vbus then you will risk faulty operation with On-The-Go hosts

When designing a self-powered device, you must not pull a D+ or D- line above the Vbus voltage supplied. This means that you must sense when Vbus is connected

The D+ or D- resistor should be pulled up to a 3.3V supply derived from Vbus, or controlled by Vbus in such a way that the resistor never sources current to the data line when Vbus is switched off

Self-Powered Devices


On-The-Go and Battery Charging Specification both add new powering modes to the USB specification.

Powered USB (aka Retail USB, USB Plus Power, and USB + Power) +5 volts DC at up to 6 amps per connector (up to 30 watts) +12 volts DC at up to 6 amps per connector (up to 72 watts) +24 volts DC at up to 6 amps per connector (up to 144 watts)

Powered USB uses standard USB signaling with the addition of extra power lines for point-of-sale terminals

IBM owns the intellectual rights to Powered USB and charges a licensing fee for its use

More Power


SYNC PATTERN PACKET INFORMATIONIDLE



RAW DATA

BIT STUFFED DATA

NRZ ENCODING

Physical Layer Signaling

Asynchronous communications Differential signal with a 4VDC sweep (300mV HS) Data on the bus is encoded using Non-Return-to-Zero-Inverted

(NRZI) Use of bit stuffing to avoid loosing synchronization The bits are transmitted least-significant-bit (LSB) first.


Given that there are 2 data lines, many different conditions are signaled using them:

Bus States

Bus State Levels

Differential '1' D+ high, D- lowDifferential '0' D- high, D+ lowSingle Ended Zero (SE0) D+ and D- lowSingle Ended One (SE1) D+ and D- highData J State:Low-speedFull-speed

Differential '0' Differential '1'

Data K State:Low-speedFull-speed

Differential '1' Differential '0'

Idle State:Low-speedFull-speed

D- high, D+ lowD+ high, D- low

Resume State Data K stateStart of Packet (SOP) Data lines switch from idle to K stateEnd of Packet (EOP) SE0 for 2 bit times followed by J state for 1 bit timeDisconnect SE0 for >= 2usConnect Idle for 2.5usReset SE0 for >= 2.5 us

Simplified from the USB specification


High Speed


Packet Sync

Just prior to the packet sync, both data lines are low. The sync is sent using the NRZI sequence

KJKJKJKJKJKJKJKJ KJKJKJKJKJKJKJKK

A hub may drop up to 4 bits from the sync pattern. After 5 hubs the sync field of a packet may be only 12 bits long.


On a low or full speed link, a brief Single Ended Zero (SE0) state is used to indicate End Of Packet (EOP), and idle is indicated by a J condition.

On a high speed link, the idle state is effectively a SE0, so that state is not available to indicate EOP, and a different method for indicating the end of packet is used.

During normal data transmission there can not be a run of more than 6 1's in a row, because a 0 is automatically inserted (and will be removed on reception), for clock recovery reasons.

At high speed, the EOP is indicated, by deliberately sending a byte which contains a bit-stuffing error; '01111111'. This applies at the end of all packets except SOF.

Each high speed SOF packet is terminated with 5 NRZI bytes containing bit-stuffing errors: 01111111 - 11111111 -11111111 -11111111 -11111111. This pattern allows the 'disconnection envelope detector' to detect a rise in data amplitude above 625 mV, in the event that the device, along with its termination resistors, has been unplugged.

End of Packet


Negotiating High Speed

A high speed device will always present itself initially as a Full Speed device (by a 1.5K pullup resistor on D+).

The negotiation for High Speed takes place during the Reset, which is the first thing a host (root or tier hub) must do to a device before attempting data communication.

The high speed detection handshake is initiated by the device. A hub will respond to it, if it is high speed capable.

3.3V

0.8VIdle

DeviceK Chirp

Hub K-J Chirp pairs

End ofReset

Device appliestermination


High Speed Hubswith Full and Low Speed Devices

Traffic directed at full or low speed devices uses high speed links, as high speed split transactions.


SYNCIDLE PACKET INFORMATION EOP

PID

Packets

The fundamental element of communications is the packet

A packet is made of three parts: START, INFORMATION, and END-OF-PACKET (EOP)

At the START of a packet will be a sequence of transitions which is called SYNC

The SYNC pattern is a chirp of either 8 bits (full-/low-speed) or 32 bits (high-speed) where each bit is a J or K state:

KJKJKJKJKJKJKJKJKJKJKJKJKJKJKJKJKK The INFORMATION varies from 1 byte up to 1024 bytes Packet Identifier (PID) – 4bits + complement Payload and CRC – Not present in handshake packets

The EOP is indicated by having both D+ and D- low for 3 bits (full-/low-speed) or 8 bits (high-speed).


SYNC

All packets must start with a SYNC field. The SYNC field is 8 bits long at low and full speed or 32 bits long for high speed and is used to synchronize the clock of the receiver with that of the transmitter. The last two bits indicate where the PID fields starts.

USB Packet FieldsSYNC


PID

PID stands for Packet ID. This field is used to identify the type of packet that is being sent.

USB Packet FieldsPID


Group PID Value Packet Identifier

Token 0001 OUT

1001 IN

0101 SOF (Start of frame)

1101 SETUP

Data 0011 DATA0

1011 DATA1

0111 DATA2

1111 MDATA

Handshake 0010 ACK

1010 NAK

1110 STALL

0110 NYET (No Response Yet)

Special 1100 PRE (Host-issued preamble. Enables downstream bus traffic to low-speed devices)

1100 ERR (Split Transaction Error Handshake (reuses PRE value))

1000 SPLIT (High-speed Split Transaction Token)

0100 PING (High-speed flow control probe for a bulk/control Endpoint)

0000 Reserved


The first 2 bits of a Token which are transmitted determine which of the 4 groups it falls into. SOF is officially considered to be a Token PID. Bits are transmitted LSB first.


The first byte in every packet is the Packet Identifier (PID) byte. This byte needs to be recognized quickly by the USB controller. This is why it is not included in any CRC checks. It has its own validity check.

There are 4 bits to the PID. The check method uses the PID 4 bits by repeating and complementing them, making an 8 bit PID field in total.


PID0 PID1 PID2 PID3 nPID0 nPID1 nPID2 nPID3

PID shown in transmission order, LSB first.


ADDR

The address field specifies which device the packet is designated for. Being 7 bits in length allows for 127 devices to be supported. Address 0 is not valid, as any device which is not yet assigned an address must respond to packets sent to address zero.

USB Packet FieldsADDR


ENDP

The endpoint field is made up of 4 bits, allowing 16 possible endpoints. Low speed devices, however can only have 2 additional endpoints on top of the default pipe. (4 endpoints max)

USB Packet FieldsENDP


A CRC is a value calculated from a number of data bytes to form a unique value which is transmitted along with the data bytes, and then used to validate the correct reception of the data

USB uses two different CRCs a 5 bits long (CRC5) and a 16 bits long (CRC16)

The USB specification contains all the details for the algorithms used to compute the CRCs

Cyclic Redundancy Code (CRC)


EOP

End of packet is signalled by a Single Ended Zero (SE0) for approximately 2 bit times followed by a J for 1 bit time.

USB Packet FieldsEOP


For a general embedded system, silicon vendors have resolved most of the hardware and electrical issues for the embedded engineer. You need not be concerned with the detail of syncs, bit stuffing, and End Of Packet conditions. You should just be aware that the Serial Interface Engine can recognize the start and end of a packet, and that the packet contains a whole number of bytes.

The packet is where we leave the hardware realm to enter the software realm.

USB Controllers


Software Specifications


Packet types

Transfer types

Transactions

Frames

Endpoints

USB Protocols


USB has four different packet types:

Start of Frame Packets Token Packets Data Packets Handshake Packets & Split Transaction Special Token Packets

USB Packet Types


PID FRAME NUMBER

CRC5SOF

8 11 5

0101

Start of frame packets indicate the start of a new frame. The SOF packet consisting of an 11-bit frame number is sent by the host every 1ms ± 500ns on a full speed bus or every 125 µs ± 0.0625 µs on a high speed bus.

The first transaction in each (micro)frame. An SOF allows endpoints to identify the start of the (micro)frame and synchronize internal endpoint clocks to the host.

Start of Frame Packets


PID ADDR CRC5

INOUTSETUP

8 7 5

100100011101

ENDP

4

Token packets indicate the type of transaction to follow. They are always the first packet in a transaction, identifying the targeted endpoint, and the purpose of the transaction.

There are three types of token packets: In

– Informs the USB device that the host wishes to read information.

Out– Informs the USB device that the host

wishes to send information. Setup

– Used to begin control transfers.

Token Packets


Data packets contain the payload. There are two types of data packets each capable of

transmitting up to 1024 bytes of data.

Data0 Data1

Data PacketsLow and Full speed

PID PAYLOAD DATA CRC16

DATA0DATA1DATA2MDATA

8 0 to 1024 16

0011101101111111

DATA0 and DATA1 PIDs are used in Low and Full speed links as part of an error-checking system.

When used, all data packets on a particular endpoint use an alternating DATA0 / DATA1 so that the endpoint knows if a received packet is the one it is expecting. If it is not the expected packet, it will still acknowledge (ACK) the packet as it is correctly received, but will then discard the data, assuming that it has been retransmitted because the host missed seeing the ACK after the previous data packet.


High Speed mode defines two additional data PIDs, DATA2 and MDATA.

DATA2 This data packet token has been added as part of a system for controlling

multiple isochronous IN packets during one microframe at high speed. For each isochronous IN packet requested, the suffix of the DATAx PID represents the remaining number of packets to be transferred during the current micro-frame.

MDATA This data packet token has been added as part of a system for controlling

multiple isochronous OUT packets during one microframe at high speed. All but the last packet sent during a microframe use the MDATA PID. The last packet sent uses DATA0, DATA1 or DATA2 depending on whether one, two or three packets were sent.

Data PacketsHigh Speed


DATA0DATA1DATA2MDATA

8 0 to 1024 16

0011101101111111


PID

8

ACKNAKSTALLNYET

0010101011100110

Handshake packets are used for acknowledging data or reporting errors. There are four type of handshake packets which consist simply of the PID.

ACKAcknowledgment that the packet has been successfully received.

NAKReports that the device temporary cannot send or receive data. Also used during interrupt transactions to inform the host there is no data to send.

STALLThe device finds itself in a state that requires intervention from the host (Endpoint is halted, or control pipe request is not supported)

NYETThe device is not ready to answer (High Speed only).

Handshake Packets


PID

8

SPLIT 1000 HUB ADDR

CRC5

7 5

SC PORT SE E

T

71 1 1 2

Split Transaction Special Token Packets

The split transaction token is used to support split transactions between the host controller communicating with a hub operating at high speed with full-/low-speed devices to some of its downstream facing ports.


Packet Token: OUT, IN, SOF, SETUP Data: DATA0, DATA1, DATA2, MDATA Handshake: ACK, NAK, STALL, NYET Special: PRE, ERR, SPLIT, PING

Hierarchy of Data

Transfer (Control, Interrupt, Isochronous, Bulk)

Transaction 1 Transaction 2 Transaction 3 Transaction n…..

Packet 1 Packet 2 Packet 3 Packet 1 Packet 2 Packet 1 Packet 2… … …


A successful transaction is a sequence of three packets which performs a simple but secure

transfer of data.

For IN and OUT transactions used for isochronous transfers, there are only 2 packets; the handshake packet on the end is omitted. This is because

error-checking is not required.

There are three types of transaction. In each of the following illustrations, the packets from the host

are indicated with the blue line, and the packets from the device with the red line.

Transactions


A successful SETUP transaction comprises three sequential packets. This is similar to an OUT transaction, but the data payload is exactly 8 bytes long, and the SETUP PID in the token packet informs the device that this is the first transaction in a Control Transfer (see standard requests).

SETUP transaction always uses a DATA0 to start the data packet.

SETUP Transaction

TokenPacket

DataPacket

HandshakePacket

From HostFrom Device1 SETUP transaction

ADDRSETUP

ENDP

CRC5

DATA0

8 bytesSETUP DATA CRC16 ACK


A successful OUT transaction comprises two or three sequential packets. Isochronous Transfer does not use the handshake packet from the device as data checking is counter productive for real-time data.

On a low or full speed link, the PID shown as DATAx will be either a DATA0 or a DATA1. An alternating DATA0/DATA1 is used as a part of the error control protocol to (or from) a particular endpoint.

OUT Transaction

TokenPacket

DataPacket

HandshakePacket

From HostFrom Device1 OUT transaction

ADDROUT

ENDP

CRC5

DATAx

PAYLOAD DATA CRC16 ACK


A successful IN transaction comprises two or three sequential packets. Isochronous Transfer does not use the handshake packet from the device as data checking is counter productive for real-time data.

Here again, the DATAx is either a DATA0 or a DATA1.

IN Transaction

TokenPacket

DataPacket

HandshakePacket

From HostFrom Device1 IN transaction

ADDRIN

ENDP

CRC5

DATAx



All USB communication links are broken into frames The first packet of each frame is the Start-Of-Frame packet

(SOF) A frame is transmitted every 1 ms in low and full speed At high speed the 1 ms frame is divided into 8 microframes

of 125 us. A SOF is sent at the start of each of these 8 microframes, each having the same frame number, which then increments every 1 ms. A high-speed microframe is 125µs to minimize the buffer

requirement

On a low speed link, to preserve bandwidth, a Keep Alive signal is sent every millisecond, instead of a Start of Frame packet. In fact Keep Alives may be sent by a hub on a low speed link whenever the hub sees a full speed token packet.

Frames


Frames and Microframes

SOF SOF

n n+18 High Speed Microframes (125 us)

Full Speed Frames (1 ms)

SOF

SOF

SOF

SOF

SOF

SOF

SOF

SOF

SOF

n n n n n n n n n+1


A transfer is made of one of more transactions

Transfers Types

Transfers type DescriptionControl Is non-periodic. It is used mostly for commands and

status operations. Mandatory using Endpoint 0 OUT and Endpoint 0 IN.

Isochronous Has a fixed number of bytes per frame. The bandwidth is guaranteed. No error-checking

Interrupt Is periodic and the latency between transactions is guaranteed. Error-free and low throughput

Bulk Is not periodic and it is used mostly to transfer large amounts of data. Error-free high volume throughput when bandwidth available


Frames and Microframes

Packet LengthThe maximum length of packets was increased for high speed, see table.

Packets per (Micro)frameAt high speed it is possible to specify up to 3 isochronous or interrupt transfers per microframe, rather than the 1 transfer per frame at full speed; giving a maximum possible isochronous or interrupt transfer rate of 192 Mb/s.

Transfer TypeMaximum packet size

High Speed Full Speed Low SpeedControl 64 8,16,32 or 64 8

Bulk <=512 8,16,32 or 64 NA

Interrupt <=1024 <=64 <=8

Isochronous <=3072 <=1023 NA


Enpoints have several attributes in addition to their type. One of them being the maximum quantity of data that the endpoint can provide or consume in a single transaction.

A single transfer can involve less than the maximum quantity of data an endpoint can handle.

Maximum DATA Packet Size


The host is responsible in managing the bandwidth of the bus.

No more than 90% of any frame to be allocated for periodic transfers (Interrupt and Isochronous) on a full speed bus. (80% in high speed)

In a highly saturated bus with periodic transfers, the remaining 10% is left for control transfers and once those have been allocated, bulk transfers will get its slice of what is left.

Bandwidth Management


A transaction is made of 3 Token Data Handshake

A transfer is made of multiple transactions and contains 2 or 3 phases: Setup Data Status [Optional for

Isochronous transfers]

All USB transactions are performed in 1mSec frames (LS and FS) or 125 µSec frames (HS) initiated by the Host. Time Division Multiplexing is used to separate packets or transactions from different sources within each frame.

Bandwidth Management


PIDSYNCEOP

PID ADDR

CRC5

ENDP

SYNCEOP

HANDSHAKE PACKET

DATA PACKETSYNCEOP

TOEKN PACKET

TOEKN PACKET … DATA PACKET(S) ... HANDSHAKE PACKET

TRANSACTION 1 TRANSACTION 2 ………………….. TRANSACTION N

1 ms 1 ms 1 ms


Control TransferExample: Control Read

SETUP Stage

ADDRSETUPENDP

CRC5

DATA

08 bytes

SETUP DATA CRC16 ACK

ADDRINENDP

CRC5

DATA

1 PAYLOAD DATA CRC16 ACK

ADDRINENDP

CRC5

DATA

0 PAYLOAD DATA CRC16 ACK

DATA Stage (optional)

STATUS Stage

ADDROUTENDP

CRC5

DATA

1 CRC16 ACK

From HostFrom Device


Bulk TransferExample

ADDROUT

ENDP

CRC5

DATA0




Interrupt TransferExample

ADDRIN

ENDP

CRC5

DATA1




Isochronous TransferExample

ADDRIN

ENDP

CRC5

DATA1

PAYLOAD DATA CRC16



Isochronous IN Protocol When requesting IN transactions, the device packages them

in DATA2, DATA1 or DATA0 packets, depending on how many packets per microframe are specified.

High Speed Isochronous Transfers

One transaction per microframe

Two transactions per microframe

Three transactions per microframe

DATA0

DATA0

DATA0

DATA1

DATA1DATA2


Isochronous OUT Protocol When sending OUT transactions, the host packages them

either in MDATA or DATA0 or DATA1 or DATA2 packets.

High Speed Isochronous Transfers

One transaction per microframe

Two transactions per microframe

Three transactions per microframe

DATA0

DATA1

DATA2

MDATA

MDATA MDATA


Transaction Translator The Transaction Translator in a high speed hub handles the

full or low speed transactions to particular ports.

Split Transactions


Typical split transaction sequence Split interrupt IN

Example Split Transaction Sequence


Interrupt and Isochronous

Bandwidth guarantee on low/full speed bus need to be transferred to high speed bus.

Periodic transactions on full or low speed bus are transferred in packets of data of at most 188 bytes.

The longest low/full speed periodic transfer of 1023 bytes is transferred in multiple split transactions.

A split packet covering multiple microframes will use the MDATA PID to indicate that is it not completed.

An Interrupt IN at 64 bytes maximum can take up to 2 microframes.

An Isochronous IN at 1023 bytes maximum will span up to 6 microframes.

Periodic Split Transactions


All packets are sent to and received by the USB device via endpoints.

Endpoints are buffers where a device either puts or gets data

Each endpoint has a direction, IN or OUT and an address

Up to 32 endpoints can reside within a device Endpoint 0 is always the control endpoint and is bidirectional

(IN/OUT) A device can have up to 15 additional OUT and 15 additional IN

endpoints with each its buffer The endpoint direction is implicit in the PID.

– OUT and SETUP PIDs refer to the OUT endpoint– IN PID refers to the IN endpoint.

Never share endpoints between interfaces

Endpoints


Protocol AnalyzerStrongly Recommended


Function of: target device's ability to source or sink data, the bandwidth consumption of other devices on the bus, and the efficiency of the host's USB software stack.

Assuming Host and Device CPU can follow line speed, it is a function of: Transfer type and Signaling rate

(In practice, most hosts can reach the maximum isochronous and interrupt bandwidths with a single target endpoint. With bulk transfers, typical transfer rates are around 900kb/s to a single endpoint, increasing to near ideal transfer rates with multiple endpoints.)

USB's Actual Throughput


Each transfer type determines various characteristics of the communication flow including the following: Data format imposed by the USB Direction of communication flow Packet size constraints Bus access constraints Latency constraints Required data sequences Error handling

The designers of a USB device choose the capabilities for the device’s endpoints.

Transfer Impacts on Communication Flow


Each table shows: The protocol overhead required for the specific transfer type (and speed) For some sample data payload sizes:

– The maximum sustained bandwidth possible for this case– The percentage of a (micro)frame that each transaction requires– The maximum number of transactions in a (micro)frame for the specific case– The remaining bytes in a (micro)frame that would not be required for the specific case– The total number of data bytes transported in a single (micro)frame for the specific case

A transaction of a particular transfer type typically requires multiple packets.

The protocol overhead for each packet includes: a 8-bits (FS/LS) or 32-bits (HS) SYNC field a PID byte A 3-bits (FS/LS) or 8-bits (HS) EOP In a token packet: endpoint number + device address + CRC5 = 16 bits In a data packet: 16-bits CRC16 + any data field (8 bits per byte) For transaction with multiple packets, the inter packet gap or bus turnaround time

required.

For these calculations, there is assumed to be no bit-stuffing required.

Table Calculation for the Transfer Impacts


Low-speed Control Transfer Limits


Full-speed Control Transfer Limits


High-speed Control Transfer Limits


Full-speed Isochronous Transaction Limits


High-speed Isochronous Transaction Limits


Low-speed Interrupt Transaction Limits


Full-speed Interrupt Transaction Limits


High-speed Interrupt Transaction Limits


Full-speed Bulk Transaction Limits


High-speed Bulk Transaction Limits


Once the device is attached, enumeration starts

Host requests a number of data structures called descriptors

Enumeration occurs on the default bidirectional endpoint 0

Host assigns a unique 7-bit address to the device

Enumeration

Device attachment

Reset device

Get device descriptor

Assign address

Get configuration descriptor

Get other descriptors

Select device driverSet Configuration

Reset device


Describes attributes about the peripheral

Peripherals typically have more than one descriptor

It is typically stored in an EEPROM in the device’s circuit

There are few types of descriptors: Standard Class Vendor

Among the standard descriptors: Device descriptor - general information

about device Configuration descriptor - device

configuration Interface descriptor – number of endpoints Endpoint descriptor - properties of an

endpoint

DescriptorsDevice Descriptor:bcdUSB: 0x0110bDeviceClass: 0x00bDeviceSubClass: 0x00bDeviceProtocol: 0x00bMaxPacketSize0: 0x08 (8)idVendor: 0x058FidProduct: 0x9380bcdDevice: 0x0100iManufacturer: 0x01iProduct: 0x02iSerialNumber: 0x00bNumConfigurations: 0x01

ConnectionStatus: DeviceConnectedCurrent Config Value: 0x01Device Bus Speed: FullDevice Address: 0x04Open Pipes: 2

Endpoint Descriptor:bEndpointAddress: 0x01Transfer Type: BulkwMaxPacketSize: 0x0040 (64)bInterval: 0x00

Endpoint Descriptor:bEndpointAddress: 0x00Transfer Type: ControlwMaxPacketSize: 0x0507 (1287)wInterval: 0x0282bSyncAddress: 0x40


Device States

Default After reset but before receiving Set Address. In the Default state, the only valid requests are Get Descriptor, and Set Address.

Addressed After the device has been assigned an address via Set Address. Now the device must recognize the following additional requests:

– Get Configuration – Set Configuration – Set Feature – Clear Feature – Get Status – Set Descriptor (optional)

Configured After the host has sent Set Configuration with a non-zero value, to select a configuration. The device

is now operational. In the Configured state, only Set Address is not a valid request. Three additional requests are

restricted to Configured state only:– Get Interface – Set Interface – Synch Frame

This is only a brief overview. The complete USB specifications is a lot more complex and complete.

Valid Request Sequence


Enumeration

Device Descriptor

Configuration Descriptor 1


Configuration Descriptor n…

Interface 0 Descriptor


Endpoint Descriptor 1





HID Descriptor



wTotalLength


wTotalLength

General

HID


A control transfer starts with a SETUP transaction which conveys 8 bytes.

These 8 bytes define the request from the host.

Standard Descriptor Requests

TokenPacket

DataPacket

HandshakePacket


1 SETUP transaction

ADDRSETUP

ENDP

CRC5

DATA0

8 bytesSETUP DATA CRC16 ACK


The host loads the appropriate driver using a PID/VID (Product ID/Vendor ID) combination used during the enumeration.

Abstract from a .inf file:

[DeviceList]%USB\VID_8765&PID_1234.DeviceDesc%=USBBulkInstall,

USB\VID_8765&PID_1234

Device Driver


HID Enumeration

USB Host(PC) MCU

CONTROL pipe

INTERRUPT-IN pipe

Request for Device Descriptor

Reply with Device Descriptor

Request for Configuration DescriptorRequest for Report Descriptor

Reply with Configuration Descriptor(s)Reply with Interface Descriptor(s)Reply with Endpoint DescriptorReply with Report Descriptor

Set Configuration

IN Packet

IN Report

Reply with HID Descriptor

HID Driver

Endpoint 0 (EP0)CONTROL endpoint

Endpoint 3 (EP3)INTERRUPT-IN endpoint

Connect USB cable


USB Functionsi.e. Classes


The USB standard makes references to USB functions which can be seen as USB devices which provide a capability or function such as a Printer, Mass Storage Drive, Scanner, Modem or other peripheral.

In Software, Classes implements the Functions.

A USB Class describes a group of devices or interfaces with similar attributes or services. It is a software interface for common devices.

A Class Specification defines the requirements for such a related group.

A single device can belong to multiple classes. Currently more than 13 device classes specified by the USB

specification, and growing (plus the subclasses).

USB Classes


Approved Class Specification Documents

Source: http://www.usb.org/developers/devclass_docs#approved

Class DocumentsAudio Class Audio Device Class Spec for Basic Audio Devices and Adopters Agreement

Audio Device Document 1.0 Audio Data Formats 1.0 Audio Terminal Types 1.0 USB MIDI Devices 1.0 Audio Devices Rev. 2.0 Spec and Adopters Agreement

Battery Charging Battery Charging v1.1 Spec and Adopters Agreement

Cable and Connector Cable and Connector Class 2.0Series 'A' Plug form factor Guideline 1.0 USB Connector for Mezzanine Applications Guidelines Rev. 1.0 Micro-USB Cables and Connectors v1.01 Spec and Adopters Agreement

Common Class (CCS) Common Class Base Specification 1.0

Communications Device Class

Class definitions for Communication Devices 1.2 Components of CDC are organized as separate documents:

CDC Subclass for Asynchronous Transfer Mode DevicesCDC Subclass for Communications DevicesCDC Subclass for Ethernet Control Model DevicesCDC Subclass for ISDN DevicesCDC Subclass for PSTN devices including Serial devicesCDC Subclass for Wireless Mobile Communication Devices 1.1CDC v1.2 WMC v1.1 Adopters AgreementCDC Subclass Specification for Ethernet Emulation Model Devices 1.0 Network Control Model Devices Specification v1.0 and Adopters Agreement




Class DocumentsContent Security Device Class Definition for Content Security Devices 1.0

Content Security Method 1 - Basic Authentication Protocol 1.0 Content Security Method 2 - USB Digital Transmission Content Protection Implementation 1.0

Device Firmware Upgrade Group Device Firmware Upgrade 1.1 (new version 31-Aug-2004)

HID Class HID Information

Imaging Class Still Image Capture Device Definition 1.0 and Errata as of 16-Mar-2007

IrDA IrDA Bridge Device Definition 1.0

Mass Storage Mass Storage Class Specification Overview 1.4 Mass Storage Bulk Only 1.0 Mass Storage Control/Bulk/Interrupt (CBI) Specification 1.1Mass Storage UFI Command Specification 1.0 Mass Storage Bootability Specification 1.0 Lockable Mass Storage Specification 1.0 and Adopters Agreement- Lockable Mass Storage IP Disclosure

USB Attached SCSI Protocol (UASP) v1.0 and Adopters Agreement

Media Transfer Protocol Media Transfer Protocol v.1.0 Spec and MTP v.1.0 Adopters Agreement

Monitor Monitor Device Document 1.0




Class DocumentsOpenUSBDI OpenUSBDI Specification 1.0

Personal Healthcare Personal Healthcare Rev. 1.0, Errata for USB Personal Health Care Device Class and Personal Healthcare Adopters Agreement

Physical Interface Devices Device Class Definition for PID 1.0

Power Power Device Class Document 1.0

Printer Class Printer Device Class Document 1.1

Smart Card Class Smart Card CCID version 1.1 Smart Card ICCD version 1.0

Test & Measurement Class Test & Measurement Class Specifications

Video Class Video Class 1.1 document setUSB_Video_Class_1.1USB_Video_Identifiers_1.1USB_Video_Payload_DV_1.1USB_Video_Payload_Frame_Based_1.1USB_Video_Payload_MJPEG_1.1USB_Video_Payload_MPEG-2_TS_1.1USB_Video_Payload_Uncompressed_1.1USB_Video_Payload_Stream_Based_1.1USB_Video_Transport_1.1USB_Video_Example_1.1USB_Video_FAQ_1.1


Windows Windows supports most of the USB classes with the

exception of DFU, IrDA bridge, Personal Healthcare, Test and Measurement.

Host Driver Support


Class Specification bDeviceClass Code Driver Name Windows Support

Bluetooth class 0xE0 Bthusb.sys Windows VistaWindows XP

Chip/smart card interface devices (CCID) 0x0B Usbccid.sys

Windows Server 2008Windows VistaWindows Server 2003*Windows XP* Windows 2000*

Hub class 0x09 Usbhub.sys

Windows Server 2008Windows VistaWindows Server 2003Windows XPWindows 2000

Human interface device (HID) 0x03 Hidusb.sys


Mass storage class (MSC) 0x08 Usbstor.sys


Printing class 0x07 Usbprint.sys


Windows

Source: http://www.microsoft.com/whdc/connect/usb/USBFAQ_intro.mspx


Class Specification bDeviceClass Code Driver Name Windows Support

Scanning/imaging (PTP) 0x06

WpdUsb.sys

___________________Usbscan.sys

Windows Server 2008Windows VistaWindows Server 2003Windows XP_______________________Windows 2000

USB Audio class 0x01 Usbaudio.sys


Modem class (CDC) 0x02 Usbser.sys


Video class (UVC) 0x0E Usbvideo.sys Windows VistaWindows XP

Windows

Source: http://www.microsoft.com/whdc/connect/usb/USBFAQ_intro.mspx


Linux

Class type StatusHub WorkingHID (Human Interface Devices) Keyboards, mice, joysticks, digitizers workingHID Power WorkingHID Monitor NoneCDC ACM Communications class(Modems, ISDN TAs) Working

CDC Ethernet Model Communications class(many Cable Modems and networked devices) Experimental/2.4, Working/2.6

Audio (non-midi) Working, support continuingAudio Midi NonePrinters and printer cables WorkingMass Storage (HD, Floppy, Zip, CD, etc.) Working, mostly stableStill Image Capture Working; user mode driverIrDA ExperimentalBluetooth ExperimentalContent Security NoneOpenUSBDI NonePID (Physical Interface Devices) NoneFirmware Upgrade NoneCCID (Chip/SmartCard Interfaces) User mode driverCCS (Common Class) NoneOBEX (Object Exchange) Working

Source: http://www.linux-usb.org/devices.html


The Apple USB Class Drivers are based on the Device Class Specifications that are available from the USB-IF Device Class Documents web page.

MacOS

Source: http://developer.apple.com/mac/library/qa/qa2004/qa1370.html

Source code on http://www.opensource.apple.com/index.html

USB OHCI Controller in the IOUSBFamily project

USB EHCI Controller in the IOUSBFamily project

USB Composite Class driver in the IOUSBFamily project

USB HID driver in the IOUSBFamily project - which supports both keyboards and pointing devices

USB CDC Device in the AppleUSBCDCDriver project

USB Mass Storage Bulk Only Device in the IOUSBMassStorageClass project

USB Mass Storage Control/Bulk/Interrupt (CBI) Device in the IOUSBMassStorageClass project

USB Mass Storage Uniform Floppy Interface(UFI) Device in the IOUSBMassStorageClass project

USB Audio Class Driver in the AppleUSBAudio project


Very Popular Classes

Class Descriptor where Class is defined

Examples

Audio Interface Speakers, microphones, headsets

Communication(CDC) Device or Interface Modems, USB to serial adapters

Human Interface (HID) Interface Mice, Keyboards, joysticks, digitizers

Mass storage Interface Hard drives, flash drives, CD-ROMs

Personal Healthcare Interface or Device (Interface preferred)

Heart rate monitors, Glucose meters

Printer Interface well…printers

Smart card Interface Access cards, banking cards, prepaid cards

Still Image capture Interface Digital Cameras, scanners

Video Interface Webcams, Security cameras


Audio class uses isochronous transfers for audio streams or bulk transfers for data encoded using the MIDI (Musical Instrument Digital Interface) protocol.

Audio Class Version 2.0 is not backward compatible with Audio Class Version 1.0

Audio Class Version 2.0 supports high speed, uses Interface Association Descriptor (IAD) and has new capabilities and support.

Audio


USB Audio Class


Telecommunications Analog phones and modems Digital phones (including cell phones) ISDN terminal adapters Virtual COM-port

Networking ADSL modems Cable modems Ethernet adapters and hubs

Communications


Communications

SubClasses• ATM – Asynchronous Transfer Mode• EEM – Ethernet Emulation Model• ECM – Ethernet Control Model• ISDN – Integrated Service Digital Network• PSTN – Public Switched Telephone Network• WMC – Wireless Mobile Communications

Microsoft defined Network Driver Interface Specification (NDIS) for using USB and other buses to configure network interfaces and carry Ethernet data. Remote NDIS defines a protocol to manage communications with network adapters and higher-level drivers. NDIS and RNDIS are supported on Windows only.


CDC are often composite devices For example, network control generally use an interrupt pipe.

Data interface use bInteraceClass = 0x0A

For performance, some Virtual-COM port devices use vendor specific drivers and thus cannot be considered as part of the communications device class.

Communications


Communications Device Class (CDC)

Typical CDC PSTN ACM usage

The Virtual-COM port


USB Control Device Class (CDC)

Typical Windows RNDIS usage

Communication interfacebInterfaceSubClass = 0x02 (ACM)bInterfaceProtocol = 0xFF (Vendor Specific)

One Interrupt endpointOne Data Interface with two bulk endpoints (TX and RX)


HID exchange data in reports

Introduction of a Report Descriptor Size of each report data Usage values for report data

HID Usage Tables contains Usage-tag values for Keyboards, pointing devices, game controllers, displays,

telephone controls and more

Class Definition for Physical Interface Devices (PID) Force-feedback joysticks

Human Interface Device (HID)


Montior Control Display user controls and power management

Usage Tables for HID Power Devices Typical usage is UPS devices Other devices where the host monitors and controls batteries or

other power components

Point of Sale (POS) Usage Tables Barcode reader, weighing devices and magnetic stripe reader

Human Interface Device (HID)


Mass Storage communications are complex Many possible transport protocols

Recommended to Use bulk transfer to exchange data Use

– bInterfaceSubClass = 0x06 (generic SCSI Media)– bInterfaceProtocol = 0x50 (bulk-only)

Have a serial number in a USB string descriptor Allows to retain the driver letter and access policies when moving

the MSD or having mutliple MSD with the same VendorID and ProductID

Mass Storage


Mass storage has 2 or 3 stages: Command transport Data transport (optional) Status transport

Command Block Wrapper (CBW) Data Command Status Wrapper (CSW)

Mass Storage


Mass Storage


Personal Healthcare Devices may send data that is episodic Data can be collected and stored and transmitted to the host

only when connected

Examples: heart-rate monitor blood-pressure monitor glucose meter pulse oximeter motion sensors pill monitors

Personal Healthcare


Vendor specific When a function does not match a USB class

May fit Test and Measurement or DFU class No driver in OS – Look for third party solution

Custom Functions


HID Limited to control and interrupt Can transfer any data

Virtual COM port Data exchange using bulk transfer

Mass storage For data transfer in files (file system required)

Custom FunctionsDrivers with Vendor Specific Capabilities


Custom Drivers

Microsoft WinUSB

Third party vendors– Well ……– Micrium, Inc.– of course

Custom Functions


The Stacks


Device Stack

Application

USB Class API

Class Drivers

USB Device core stack

Device Controller Driver

Device Controller Hardware

Kernel A

bstraction

Mass storageHID CDC Custom

drivers

Kernel


Memory FootprintDevice-Bulk

SystemThe following table shows the hardware and the toolchain details of the project:

Detail Description

CPU Philips LPC2148

Toolchain IAR Embedded Workbench v4.30a

ARM/Thumb mode Thumb mode

Compile options Size optimization (Low)

Memory requirementsThe following table shows the memory requirement of the project:

Detail ROM[bytes]

RAM[bytes]

USB code and const data 6309 --

USB data -- 32

USB receive buffer -- 512

Total

6309 544

The USB receive buffer is listed separately because this buffer can be reduced to a trivial size if optimal performance is not required.


Memory FootprintDevice-MSD

SystemDetail Description

CPU Philips LPC2148


ARM/Thumb mode Thumb mode

Compile options Size optimization (Low)

Memory requirements (RAMDisk)Detail ROM

[bytes]RAM

[bytes]

USB code and const data 6736 --

USB data -- 32

USB receive buffer -- 512

MSD sector buffer -- 512

Total

6736 1056

ROM and RAM will vary depending on the storage device used.

RAM space beyond that which is reflected by the table will also be needed, of course, if RAM is chosen as the application's storage medium.

The sector buffer's size corresponds to the sector size utilized by the actual storage device, more than 512 bytes may be necessary.

The USB receive buffer is listed separately because this buffer can be reduced to a trivial size if optimal performance is not required.


Host Stack

Application

USB Class API

Class Drivers

USB Host core stack

Host Controller Driver

Host Controller Hardware

Mass storageHID CDC Hub Custom

drivers

Kernel A

bstraction

Kernel


Memory FootprintHost-HID


Detail Description

CPU ARM9


ARM/Thumb mode ARM mode

Compile options None


Detail ROM[bytes]

RAM[bytes]

Host driver 11572 440

HID Class driver 6864 36

Mouse and keyboard demo code 2392 8036

USB core 18837 66121

Total

39665 74633

64k of the RAM data is a memory pool in the usbh_lib module. For a keyboard/mouse interface, a 64k memory pool is necessary.


Memory FootprintHost-MSD


Detail Description

CPU ARM9


ARM/Thumb mode ARM mode

Compile options None


Detail ROM[bytes]

RAM[bytes]

Host driver 11572 440

MSD Class driver 7842 548

Mouse and keyboard demo code 2392 8036

USB core 18837 2121

Total

40643 11145


Supplement to USB 2.0

Allows two USB devices to talk without a PC as host.

DRD (Dual Role Devices).

Unique mini-AB receptacle.

OTG High Speed and Full Speed.

Low power requirements on battery powered devices.

USB On-The-Go


USB On-The-Go

Application

Device stack

OTG Controller Driver

Host Controller Hardware

Device stack

OTG stack

Device Controller Hardware


Certified Wireless USB is the new wireless extension to USB that combines the speed and security of wired technology with the ease-of-use of wireless technology

Certified Wireless USB is the first high-speed wireless personal interconnect technology to meet the needs of multimedia consumer electronics, PC peripherals, and mobile devices.

Certified Wireless USB will preserve the functionality of wired USB while also unwiring the cable connection and providing enhanced support for streaming media CE devices and peripherals.

Certified Wireless USB performance is targeted at 480Mbps at 3 meters and 110Mbps at 10 meters.

Wireless USB


Compliance


The USB organization has created a compliance program

Two main criteria are: checklists and compliance testing

Checklists contain questions relating to a product and its behavior

USB-IF provide a Compliance Program for a small membership fee

Usage of the USB logo requires a product to be compliant

There are a set of registered USB logos which are not interchangeable

Compliance


USB Command Verifier


USB Gold Tree

• A Host PC with different USB controllers

• EHCI• OHCI• UHCI• xHCI (USB 3.0)

• 5 HS self powered hubs• 1 FS self powered hub• 1 FS keyboard/hub• 5 5 meter USB cables• 1 mouse• 2 mass storage devices• 1 video camera

http://compliance.usb.org/index.asp?UpdateFile=Interoperability


Summary


Appealing features: Ease of use Bus power Auto-detection and self configuration Expandability Speed Availability of peripherals Flexibility and reliability

The tradeoff is complex implementation and cost

Summary


Typical MCU can not keep up with High speed USB controllers.

USB device controllers are sometimes troublesome to port. This is partly because a USB device controller port deals more closely with more complicated hardware than, say,a TCP/IP NIC port. Partly, this is because USB device controllers are much more various than NICs.

The Device can never initiate a communication.

If using MSD & a file system, either the device or the host (but not both) can access the disk at any time.

Have Reasonable Expectations


Documentation Universal Serial Bus Specification, Revision 2.0 www.usb.org/developers/docs/usb_20_071607.zip www.usb.org/developers/onthego/. USB Design by Example: A Practical Guide to Building I/O

Devices by John Hyde USB Complete by Jan Axelson

Web Sites www.beyondlogic.org/index.html#USB www.usb.org www.everythingusb.com www.usbman.com

References

And soon…USB Device by Micriµmon a Renesas RX63N

http://www.usb.org/developers/docs/usb_20_071607.zip�

http://www.usb.org/developers/onthego/�


Questions?