|
`
`SECOND EDITION
`
`ey aaa:
`
`
`5csiaORR USB 2.iyUSB
`
`Q Peripherals
`
`Everything You
`Need to Develop
`Custom USB
`
`FISI Ex 2006-1
`
`T=PONToh
`
`FISI Ex 2006-1
`LG v FISI
`IPR2018-00461
`
`

`

`IPR2018-00461
`
`
`Everything You Need
`to Develop Custom USB Peripherals
`
`Lakeview Research
`
`Madison, WI 53704
`
`FISI Ex 2006-2
`LG v FISI
`
`USB Complete
`
`Second Edition
`
`Jan Axelson
`
`FISI Ex 2006-2
`LG v FISI
`IPR2018-00461
`
`

`

`copyright 2001 by Jan Axelson. All rights reserved.
`Published by Lakeview Research
`Cover by Rattray Design. Cover Photo by Bill Bilsley Photography.
`Index by Broccoli Information Management
`
`Lakeview Research
`5310 Chinook Ln.
`Madison, WI 53704
`USA
`
`Phone: 608-241-5824
`Fax: 608-241-5848
`Email: info@Lvr.com
`Web: http://www.Lvr.com
`
`14413 121110987654321
`
`Products and services named in this book are trademarks or registered trademarks of
`their respective companies. In all instances where Lakeview Research is aware of a
`trademark claim, the product name appears in initial capitalletters, in all capital letters,
`or in accordance with the vendor's capitalization preference. Readers should contact the
`appropriate companies for complete information on trademarks and trademark registra-
`tions. All trademarks and registered trademarks in this book are the property of their
`respective holders.
`No part of this book, except the programs andprogram listings, may be reproduced in
`any form, or stored in a database or retrieval system, or transmitted or distributed in any
`form, by any means, electronic, mechanical photocopying, recording, or otherwise,
`without the prior written permission of Lakeview Research or the author. The programs
`and program listings, or any portion of these, may be stored and executed in a computer
`system and may be incorporated into computer programs developed by the reader.
`The information, computer programs, schematic diagrams, documentation, and other
`material in this book are provided “as is,’ without warranty of any kind, expressed or
`implied, including without limitation any warranty concerning the accuracy, adequacy,
`or completeness of the material or the results obtained from using the material. Neither
`the publisher nor the author shall be responsible for any claims attributable to errors,
`omissions, or other inaccuracies in the materialin this book. In no event shall the pub-
`lisher or author be liable for direct, indirect, special, incidental, or consequential dam-
`ages in connectionwith, or arising outof, the construction, performance, or other use of
`the materials contained herein.
`
`ISBN0-9650819-5-8
`
`Printed and bound in the United States of America
`
`FISI Ex 2006-3
`LG v FISI
`IPR2018-00461
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`FISI Ex 2006-3
`LG v FISI
`IPR2018-00461
`
`

`

`Inside USB Transfers
`
`5 device. If
`can access
`
`-o the chip
`
`about how
`i make the
`xose of the
`
`Inside USB Transfers
`
`> Complete
`
`39
`
`IPR2018-00461
`
`To design and program a USB device, you need to know a certain amount
`aboutthe inner workings of the interface. This is true even though the hard-
`ware and system software handle manyofthe details automatically.
`This and the next three chapters are a tutorial on how USBtransfers data.
`This chapter has essentials that applyto all transfers. The following chapters
`cover the four transfer types supported by USB, the enumeration process,
`and the standard requests used in controltransfers.
`You dont need to know every bit of this information to get a project up and
`running, but I’ve found that understanding something about how the trans-
`fers work helps in deciding which transfer types to use, in writing the firm-
`ware for the controller chip, and in tracking down theinevitable bugs that
`show up when you try out your circuits and code.
`The USB interface is complicated, and much of what you need to know is
`interwoven with everything else. This makes it hard to know where to start.
`In general,
`| begin with the big picture and work down to the details,
`Unavoidably, some of the things I refer to aren't explained in detail until
`
`
`
`
`
`
`
`FISI Ex 2006-4
`LG v FISI
`
`FISI Ex 2006-4
`LG v FISI
`IPR2018-00461
`
`

`

`
`
`
`
`
`
`
`Chapter 3
`
`
`
`
`
`later. And some things are repeated because they're important and relevant
`in more than oneplace.
`The information in these chapters is dense. If you don't have a background
`in USB, you won't absorbit all in one reading. You should, however, get a
`feel for how USB works, and will know where to look later when you need
`to check the details.
`The ultimate authority on the USBinterface is the specification published
`by its sponsoring members. The specification document, titled not surpris-
`ingly, Universal Serial Bus Specification,
`\s available on the USB Implement-
`ers Forum’s website (www.usb.org). However, by design, the specification °
`omits information andtips that are unique to any operating system or con-
`troller chip. This type of information is essential when you're designing a
`productfor the real world, so I’ve includedit.
`
`
`
`
`
`
`
`
`
`
` FISI Ex 2006-5
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Transfer Basics
`You can divide USB communications into two categories, depending on
`whetherthey're used in configuring andsetting up the device orin the appli-
`cations that carry out the device’s purpose. In configuration communica-
`tions, the host learns about the device and prepares it for exchanging data.
`Most of these communications take place when the host enumerates the
`device on power up or attachment. Application communications occur
`when the host exchanges data for use with applications. These are the com-
`munications that perform the functions the device is designed for. For
`example, for a keyboard, the application communicationsare the sending of
`keypress data to thehostto tell an application to display a character.
`
`
`
`
`
`
`
`
`
`
`Configuration Communications
`During enumeration, the device's firmware responds to a series of standard
`requests from the host. The device must
`identify each request, return
`requested information, andtake other actions specified by the requests.
`
`
`On PCs, Windows performs the enumeration, so there's no. user program-
`
`
`ming involved. However,
`to complete the enumeration, Windows must
`
`
`USB Complete
`
`
`
`LG v FISI
`IPR2018-00461
`
`FISI Ex 2006-5
`LG v FISI
`IPR2018-00461
`
`

`

`Inside USB Transfers
`
`d relevant
`
`ickground
`ever, get a
`you need
`
`published
`dt surpris-
`aplement-
`scification
`mor con-
`ssigning a
`
`|
`
`nding on | os
`the appli-
`mmunica-
`zing data.
`ons
`erates the
`yns occur
`
`|
`
`the com-
`| for. For
`ending of
`T.
`
`.
`"standard
`t return
`Lests.
`
`program-
`yws must
`
` -
`
`have two files available: an INF file that identifies the filename and location
`of the device's driver, and the device driveritself. If the files are available and
`the firmwareis in order, the enumerationprocessis invisible to users.
`Depending on the device and how it will be used, the device driver may be
`one that’s included with Windows or one provided by the product vendor.
`The INFfile is a textfile that you can usually adapt if needed from an exam-
`ple provided by the driver’s provider. Chapter 11 has more details about
`device drivers and INFfiles.
`.
`.
`Application Communications
`After the host has exchanged enumeration information with the device and
`a device driver has been assigned and loaded, the application communica-
`tions can befairly straightforward. At the host, applications can use standard
`Windows API functions to read and write to the device. At the device, trans-
`ferring data typically requires placing data to send in the USB controller's
`transmit buffer, reading received data from thereceive buffer, and on com-
`pleting a transfer, ensuring that the device is ready for the next transfer.
`Most devices also require additional firmware support for handling errors
`and other events.
`
`TEER
`
`
`,
`Each data transfer on the bus uses one offour transfer types: control, inter-
`.
`.
`.
`rupt, bulk, or isochronous. Each has a format and protocol suited for partic-
`ular uses.
`
`Managing Data on the Bus
`USB’s two signallines carry data to and from all of the devices on the bus.
`The wires form a single transmission path thatall of the devices must share.
`(As explainedlater in this chapter, a cable segment between a 1.x device and
`a 2.0 hub on a high-speed bus is an exception, buteven here,all data shares
`the path between the hub andhost.) Unlike RS-232, which has a TX line to
`carry data in one direction and an RX line for the other direction, USB’s
`pair of wires carries a single differential signal, with the directions taking
`turns.
`
`‘omplete
`
`USB Complete
`
`
`
`RENE
`Rena
`
`FISI Ex 2006-6
`LG v FISI
`IPR2018-00461
`
`

`

`
`
`
`
`
` DEVICE1,
`
`
`
`
`
`
`
`ENDPOINT2DEVICE2,ENDPOINT2DEVICE5,ENDPOINT3
`DEVICE5,ENDPOINT3
`
`DEVICE5S,ENDPOINT3
`DEVICE2,ENDPOINT®
`
`ENDPOINT2DEVICE2,ENDPOINT@
`DEVICE2,ENDPOINT@
`DEVICES,ENDPOINT3
`DEVICES,ENDPOINT3
`ENDPOINT2
`(~[startOFFRAME
`STARTOFFRAME
`STARTOFFRAME
`
`
`
`DEVICEi,
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Thehostis in charge ofseeing thatall transfers occur as quickly as possible.
`It managesthetraffic by dividing time into chunkscalled frames, or microf-
`ramesat high speed. The host gives each transfer a portion of each frame or
`microframe (Figure 3-1). For low- and full-speed data, the frames are one
`millisecond. For high speed data,
`the host divides each frame into eight
`125-microsecond microframes. Each frame or microframe begins with a
`Start-of-Frame timingreference.
`Each transfer consists of one or more transactions. Control transfers always
`have multiple transactions because they have multiple stages, each consisting
`of one or more transactions. Other transfers use multiple transactions when
`they have more data than will fit in a single transaction. Depending on how
`the host schedules the transactions and the speed of a device's response, a
`transfer’s transactions mayall be in a single frame or microframe, or they
`maybe spread over multiple (micro)frames.
`
`
`
`
`Becauseall of the transfers share a data path, each transaction must include a
`device address. Every device has a unique address assigned by the host, and
`all data travels to or from the host. Each transaction begins when the host
`
`
`sends a block of information that includes the address of the receiving device
`
`
`and a specific location, called an endpoint, within the device. Everything a
`
`device sendsis in response to receiving a request from the host to send data
`Figure 3-2:
`
`low and full
`or status information.
`
`
`
`USB Complete
`
`
`
`is a
`ware:
`
`than
`
`The
`
`upstr
`
`
`
`
`
`| i
`
`Figure 3-1: At low and full speeds, the host schedules transactions within
`1-millisecond frames. Each frame begins with a Start-of-Frame packet, followed
`by transactions that transfer data to or from device endpoints. The host may
`schedule transactions anywhereit wants within a frame. The processis similarat
`high speed, but using 125-microsecond microframes.
`
`Chapter 3
`
`
`
`UNUSED
`
`DEVICE1,
`
`UNUSED
`
`F
`
`-MILLTSECOND FRAME
`
`1-MILLISECOND FRAME
`
`.
`
`1-MILLISECOND FRAME
`
`
`
`
`
`
`
`FISI Ex 2006-7
`LG v FISI
`IPR2018-00461
`
`HI
`
`HIGH- SP
`DEVIC
`
` USB Com
`
`FISI Ex 2006-7
`LG v FISI
`IPR2018-00461
`
`

`

`eed and Bus Speed
`Host Sp
`A 1.x host supports low and full speeds. A 2.0 host with user-accessible ports
`must supportlow,full, and high speeds.
`A 1.x hub doesn't convert between speeds; it just passes received traffic on,
`changing only the edge rate of the signals to match the destination's speed.
`In contrast, a 2.0 hub acts as a remote processor. It converts between high
`speed and low or full speed as needed and performs other functions that
`help make efficient use of the bus time. The added intelligence of 2.0 hubs
`is a major reason why the high-speed bus remains compatible with 1.x hard-
`ware. It also means that 2.0 hubs are much more complicated internally
`than 1.x hubs.
`Thetraffic on a bus segmentis high speed only if the host controller and all
`upstream (toward the host) hubs are 2.0-compliant. Figure 3-2 illustrates. A
`
`IPR2018-00461
`
`LOW SPEED
`FULL SPEED
`
`
`HIGH-SPEED
`DEVICE
`
`
`
`FULL SPEED *
`
`FULL $PEE
`
`
`
`
`-
`HIGH-SPEED
`DEVICE
`
`LOW=S PEED
`DEVICE
`
`FULL- SPEED
`DEVICE
`
`LJ
`FULL -S PEED
`DEVICE
`
`*FULL-SPEED ENUMERATION 1S REQUIRED.
`ADDITIONAL FULL-SPEED FUNCTIONALITY
`IS OPTIONAL.
`Figure 3-2: A USB 2.0 bus uses high speed whenever possible, switching to
`low and full soeeds when necessary.
`
`Complete
`
`USB Complete
`
`Inside USB Transfers
`
`2,@ HOST
`AND
`
`ROOT HUB
`
`
`
`rl
`
`HIGH SPEED
`
`LOW/FULL SPEED
`
`1GH_S$ PEED
`
`LOW SPEED
`
`
`
`HIGH-SPEED
`DEVICE
`
`
`
`
`FULL-SPEED
`DEVICE
`
`
`
`FULL SPEED
`
`
`
`
`
`
`
`Tice”
`EVICE
`
`
`
`
`
`
`——_—_——]
`FRAME
`
`within
`cet, followed
`ost may
`sis similar at
`
`y as possible.
`$, or microf-
`ach frame or
`mes are one
`e into eight
`‘gins with a
`
`isfers always
`h consisting
`ctions when
`ling on how
`response, a
`me, or they
`
`st include a
`e host, and
`en the host
`ving device
`verything a
`9 send data
`
`
`
`FISI Ex 2006-8
`LG v FISI
`
`FISI Ex 2006-8
`LG v FISI
`IPR2018-00461
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Chapter 3
`
`high-speed bus mayalso have 1.x hubs, and if so, any bus segments down-
`stream (away from the host) are low orfull speed. Traffic to and from low-
`and full-speed devices travels at high speed between the host and any 2.0
`hubs that connect to the host with no 1.x hubs in between. Traffic between
`a 2.0 hub and a 1.x hub or another low- or full-speed device travels at low or
`full speed. A bus with only a 1.x host controller supports only low andfull
`speeds, even if the bus has 2.0 hubs and devices.
`
`
`
`
`
`Elements of a Transfer
`
`
`levels
`Understanding USB transfers requires looking inside them several
`deep. Each transfer is made up of transactions. Each transaction is made up
`
`
`of packets. And each packet contains information. To understand transac-
`
`
`tions, packets, and their contents, you also need to know about endpoints
`
`
`and pipes. So that’s where we'll begin.
`
`
`
`Device Endpoints
`
`
`All transmissions travel to or from a device endpoint. The endpoint is a
`buffer that stores multiple bytes. Typically it’s a block of data memory or a
`
`
`register in the controller chip. The data stored at an endpoint may be
`
`
`received data, or data waiting to transmit. The host also has buffers for
`
`
`received data and for data ready to transmit, but the host doesn’t have end-
`
`
`points. Instead, the host serves as the starting point for communicating with
`
`
`the device endpoints.
`
`
`
`
`Thespecification defines a device endpoint as “a uniquely addressable por-
`tion of a USB device thatis the source or sink of information in a communi-
`cation flow between the host and device.” This suggests that an endpoint
`
`
`carries data in one direction only. However, as [ll explain, a control end-
`
`
`pointis a special case thatis bidirectional.
`
`
`
`
`The unique address required for each endpoint consists of an endpoint
`numberand direction. The number may range from 0 to 15. The direction
`
`
`is from the host’s perspective: IN is toward the host and OUT is away from
`
`
`the host. An endpoint configured to do control transfers must transfer data
`
`
`IPR2018-00461
`
`
`
`USB Complete
`
`FISI Ex 2006-9
`LG v FISI
`
`FISI Ex 2006-9
`LG v FISI
`IPR2018-00461
`
`

`

`
`
`
`
`
`
`
`
`on the |
`Transaq
`or PING
`
`
`
`Our
`
`Table
`|
`
` Setup
`
`
`ACK
`ACK(acknowledge) indicates that a host or device has received data without
`error. Devices must return ACK in the handshake packets of Setup transac-
`tions. Devices may also return ACK in the handshake packets of OUT
`transactions. The host returns ACK in the handshake packets of IN transac-
`tions.
`
`NAK
`NAK(negative acknowledge) means the device is busy or has no data to
`return. If the host sends data at a time whenthedevice is too busy to accept
`it, the device sends a NAKin the handshake packet. If the host requests data
`from the device when the device has nothing to send, the device sends a
`NAK in the data packet. In either case, NAK indicates a temporary condi-
`tion, and the hostretrieslater.
`
`
`
`USB Complete
`
`FISI Ex 2006-10
`LG v FISI
`IPR2018-00461
`
`
`Chapter 3
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Handshaking
`Like other interfaces, USB uses status and control, or handshaking, infor-
`mation to help to manage the flow of data. In hardware handshaking, dedi-
`cated lines carry the handshaking information. An example is the RTS and
`CTSlines in the RS-232 interface. In software handshaking, the samelines
`that carry the data also carry handshaking codes. An example is the XON
`and XOFFcodes transmitted on the data lines in RS-232links.
`USB uses software handshaking. A code indicates the success or failure ofall
`transactions except in isochronous transfers. In addition, in control trans-
`fers, the Status stage enables a device to report the success or failure of the
`entire transfer.
`Most handshakingsignals transmit in the handshake packet, though some
`use the data packet. The defined status codes are ACK, NAK, STALL,
`NYET, and ERR.A sixth status indicator is the absence of an expected
`handshake code, indicating a more serious buserror. In all cases, the receiver
`of the handshake, or lack of one, uses the informationto help it decide what
`to do next. Table 3-5 showsthe status indicators and where they transmitin
`each transaction type.
`
`
`
`
`
`
`
`
`
`
`
`feitoaanhERSIREN
`
`
`
`FISI Ex 2006-10
`LG v FISI
`IPR2018-00461
`
`

`

`INS» infor.
`cng, dedi.
`- RTS and
`same lines
`XON |
`the
`lure ofall
`rol trans-
`ire of the
`
`
`
`
`
`
`
`
`
`device
`
`gh some
`STALL,
`hy
`expected
`TACK,
`
`(high speed only)
`receiver
`NAK,
`de what
`STALL
` asMit in
`Hosts never send NAK.Isochronous endpoints don’t support NAK because
`they have no handshake packet for returning the NAK.If a device or the
`host misses isochronousdata, it’s gone,
`
`Inside USB Transfers
`
`STALL,
`NYET(high
`
`
`
`
`
`Table 3-5: The location, source, and contents of the handshake signal depend
`on the type of transaction.
`[Transaction type|Data packet
`Data packet
`Handshake
`Handshake
`
`r PING query
`source
`contents
`packet source
`packet
`|?
`contents
`Setup
`host
`data
`[device
`ACK
`|
`
`Po
`;
`NAK,
`:
`OUT
`host
`data
`device
`ACK,
`speedonly),
`ERR(fromhub in
`complete split)
`
`device
`data,
`ACK
`NAK,
`STALL,
`completesplit)
`ERR(from hub in
`none
`
`IPR2018-00461
`
`
`vithout
`ransac-
`
`SS
`
`STALL
`
`“OUT
`tfansac-
`
`The STALL handshake can have any of three meanings: unsupported con-
`trol request, control requestfailed, or endpointfailed.
`When a device receives a control-transfer request that the endpoint doesn’t
`support, the device returns a STALL to the host. The device also sends a
`STALLifit supports the request but for some reason can’t take the requested
`action. For example, if the host sends a Set_Configuration request that
`requests the device to set its configuration to 2, and the device supports only
`configuration 1, the device returns a STALL. To clear this type of STALL,
`the host just needs to send another Setup packet to begin a new control
`transfer. The specification calls this type ofstall a protocolstall.
`
`USB Complete
`
`FISI Ex 2006-11
`LG v FISI
`
`FISI Ex 2006-11
`LG v FISI
`IPR2018-00461
`
`

`

`Enumeration: How the Host Learns about Devices
`
`
`
`
`
`
`
`TPE Reyhl
`
`
`Enumeration:
`How the Host Learns
`about Devices
`,
`Before applications can communicatewith a device, the host needsto learn
`about the device and assign a device driver. Enumeration ts the initial
`exchange of information that accomplishes this. The process includes
`assigning an address to the device, reading data structures from the device,
`assigning and loading a device driver, and selecting a configuration from the
`options presented in the retrieved data. The device is then configured and
`ready to transfer data using any of the endpoints in its configuration.
`This chapter describes the enumeration process, including the structure of
`the descriptors that the host reads from the device during enumeration. You
`don’t need to know every detail about enumeration in orderto design a USB
`peripheral, but understanding a certain amount is essential in creating the
`
`arantee a rare
`
`im at the g
`e time to e4
`nder Windy
`atanteed Cp
`
`ming in the -
`educingth
`
`USB Complete
`
`Eee
`LG vFIsl
`
`FISI Ex 2006-12
`LG v FISI
`IPR2018-00461
`
`

`

`
`
`
`
`
`
`
`
`
`actions.
`
` Chapter 5
`
`
` descriptors that will reside in the device and writing the firmware that
` The Process
`
`
`One of the duties of a hub is to
`detect the attachment and removal of
`devices. Each hub has an interru
`pt IN pipe for reporting these events to the
`host. On system boot-up, the host polls its root hub to learn ifany devices
`
`
`
`
`are attached, including additional hubs and devices attached to the first tier
`
`
`ofdevices. After boot-up, the host continues to poll periodically to learn of
`
`
`
`any newly attached or removed devices.
`On learning of a new device,
`the host sends a series of requests to the
`
`device's hub, causing the hubto establish a communications path between
`the host and the device. The host then attempts to enumerate the device by
`
`
`sending control transfers containing standard USB requests to Endpoint0.
`All USB devices must support control transfers, the standard requests, and
`
`
`
`
`Endpoint 0. For a successful enumeration, the device must respond to each
`
`
`
`
`request by returning the requested information and taking other requested
`
`
`
`
`
`Figure 5-1:|
`
`
`From the user’s perspective, enumeration should be invisible and automatic,
`and others
`USB device
`
`
`except for possibly a window that announces the detection of a new device
`
`and whether or not the attempt to configure it succeeded. Sometimes on
`Ina
`
`first use, the user needs to provide a disk containing the INFfile and device
`the I
`
`
`
`driver.
`and
`
`When enumeration is complete, Windows adds the new device to the
`/
`frm
`
`;
`chip
`
`DeviceManagerdisplayin the Control Panel. Figure 5-1 shows an example.
`cod
`
`
`
`To view the Device Manager, in Windows 98, click the Start menu > Set-
`
`
` tings > Control Panel >System > Device Manager. In Windows 2000,it’s the
`
`
`same except that after clicking System, you click Hardware, then Device
`
`
`
`Manager. When a user disconnects a peripheral, Windows automatically
`
`
`removesthe device from the display.
`
`
`
`
`USB Complete
`
`responds to enumeration requests.
`
`
`
`
`
`
`
`
`
`
`
`
`FISI Ex 2006-13
`LG v FISI
`IPR2018-00461
`
`FISI Ex 2006-13
`LG v FISI
`IPR2018-00461
`
`

`

`firmware thar
`
`J remoyal of
`events to the
`F
`.
`ny devices
`2.
`the first ter
`7 to lea
`f
`
`rn of
`
`=
`
`:
`
`:
`
`e
`
`‘ests to the
`th between
`* device by
`adpoint 0.
`
`uests, and
`id to each
`requested
`
`W device
`
`tomatic,
`imes on
`
`d device
`
`Tape drives
`Universal Setial Bue controllers
`» ios General purpose USE Hub
`> POC-5NDN
`: oe Intel 82371.4B/ER PCI tg USB Universal Hast Controller
`tareeta
`Properties |
`| Belesh
`
`os
`__ Pemave | Fig
`
`|
`
`oe ee a :
`:
`
`
`al Bus controllers,
`
`IPR2018-00461
`
`
` Figure 5-1: The Device Manager in Windows’ Control! Panellists all detected
`USB devices. Some devices are listed under Universal Seri
`and others arelisted by type, such as keyboard or modem.
`|
`In a typical peripheral, the device’s program code contains the information
`the host will tequest, and a combination ofhardware and firmware decodes
`and responds to requests for the information. Some application-specific
`chips (ASICs) manage the enumeration entirely in hardware and require no
`firmware support. On thehost side, under ‘Windowsthere’s no need to write
`code for enumerating, because Windows handles it automatically. Windows
`will look for a specialtextfile called an INFfile that identifies the driver to
`use for the device.
`.
`Enumeration Steps
`During the enumeration process, a device moves through four of the six
`device states defined by the specification: Powered, Default, Address, and
`
`Enumeration: How the Host Learns about Devices
`
`
`J Modem
`Monitors
`
`by Mouse
`Network adapters
`so? Ports (COM &, LPT)
`4 SCSIcontraliars
`a
`Sound,video and game controllars
`System devices
`
`+
`f
`
`
`
`
`
`
`
`
`
`
`
`FISI Ex 2006-14
`LG v FISI
`
`:
`
`to the
`ample.
`S Set-
`its the
`Device
`ticall
`»
`
`USB Complete
`
`95
`
`FISI Ex 2006-14
`LG v FISI
`IPR2018-00461
`
`

`

`-
`
`
`
`
`
`ate, the
`
`
`
`
`
`
`
`
`
`
`1. The user plugs a device into a USB
`port. Orthe system powers UP with
`a device alreadyplugged into a port, The port may be on theroot hub at the
`
`
`host or attached to a hub that connects downstream ofthe host. The huh
`Provides powerto the port, and the deviice is in the Poweredstate.
`
`
`2. The hub detects the device.
`
`
`The hub monitors the voltages on thesignal
`lines of each ofits ports. The
`
`
`hub has a 15-kilohm pull-downresistor on
`each of the port’s two signal
`lines (D+ and D-), while a device has a
`
`
`1.5-kilohm pull-up resistor on
`either D+ for a full-speed device or D- for
`‘low-speed device. High-speed
`devices attach at full speed. When a device
`
`
`plugs into a port, the device’s Pp
`ull-up brings thatline high, enabling the hub
`to detect that a device is attach
`ed. Chapter 18 has more on how hubsdetect
`
`devices,
`
`
` Each hub usesits interruptpipe to
`3. The host learns of the new device.
`report events at the hub. The report in
`dicates only whether the hub ora
`port (and if so, which port) has experien
`
`
`ced an event. When the host learns
`
`
`
`
`of an event, it sends the hub a Get_Po
`
`
`rt_Status request to find out more.
`Get_Port_Status and the other Tequests described here are standard
`
`
`hub-class requests that all hubs understand. The information returned tells
`
`
`the host when a deviceis newly attached.
`
`
`4. The hub detects whether a
`device is low or full speed. Just before the
`hubresets the device, the hub
`
`
`determines whether the device is low or full
`speed by examining the voltage
`
`
`s on the twosignallines. The hub detects the
`
`
`speed of a device by determin
`ing which line has the higher voltage when
`
`
`idle. The hub send
`s the information to the host in response to the next
`
`
`
`
`
`
`
`
`IPR2018-00461
`
`USB Complete
`
`FISI Ex 2006-15
`LG v FISI
`
`Chapter 5
`
`Configured. (The otherstates are Attached and Suspend.) In each st
`device has defined capabilities and behavior.
`The steps below are 4
`typical sequenceofevents that occurs during enumey.
`ation under Windows
`. The device firmware shouldn't assumethat the eny.
`Meration requests and events will occur
`in a particular order, however. The
`device should be ready to detect and res
`pond to any control request at any
`time.
`
`
`
`
`
`
`
`
`
`
`
`
`FISI Ex 2006-15
`LG v FISI
`IPR2018-00461
`
`

`

`IPR2018-00461
`
`6. The hostlearnsif a full-speed device supports high speed. Detecting
`whether a device supports high speed uses two specialsignal states. In the
`ChirpJ state, the D+ line only is driven and in the ChirpKstate, the D- line
`only is driven.
`During. the reset, a device that supports high speed sends a Chirp K. A
`high-speed hub detects the chirp and responds with a series of alternating
`Chirp Ks and Js. When the device detects the pattern KJKJKJ,it removesits
`full-speed pull up and performsall further communications at high speed.If
`the hub doesn’t respond to the device’s Chirp K, the device knows it must
`continue to communicateatfull speed. All high-speed devices must be capa-
`ble of responding to enumeration requests at full speed.
`7. The hub establishes a signal path between the device and the bus.
`The host verifies that the device has exited the reset state by sending a
`Get_Port_Status request. A bit in the data returned indicates whether the
`deviceis still in the reset state. If necessary, the host repeats the request until
`the device has exited the resetstate.
`When the hub removes the reset, the device is in the Default state. The
`device's USB registers are in their reset states and the device is ready to
`respondto control transfers over the default pipe at Endpoint 0. Thedevice
`can now communicate with the host, using the default address of 00h. The
`device can draw up to 100 milliamperes from the bus.
`
`
`
`FISI Ex 2006-16
`LG v FISI
`
`Enumeration: How the Host Learns about Devices
`
`Get_Port_Status request. USB 1.x allowed the hub the option to detect
`device speed just after reset. USB 2.0 requires speed detection to occur
`before reset so it knows whether to check for a high-speed-capable device
`during reset, as described below.
`5. The hubresets the device. When a host learns of a new device, the host
`controller sends the hub a Set_Port_Feature request that asks the hub to
`reset the port. The hub places the device’s USBdatalines in the Reset condi-
`tion for at least 10 milliseconds, Reset is a special condition where both D+
`and D-are a logic low. (Normally, the lines have opposite logic states.) The
`hub sendsthereset only to the new device. Other hubs and devices on the
`bus dontseeit.
`
`USB Complete
`
`FISI Ex 2006-16
`LG v FISI
`IPR2018-00461
`
`

`

`Chapter 5
`
`8. The host sends a Get_Descriptor request to learn the maximum
`packet size of the default pipe. The host sends the request to device
`address 0, Endpoint 0. Because the host enumerates only one device at a
`time, only one device will respond to communications addressed to device
`address 0, even if several devices attach at once.
`
`The eighth byte of the device descriptor contains the maximum packetsize
`supported by Endpoint 0. A Windows host requests 64 bytes, but after
`receiving just one packet (whetheror notit has 64 bytes), it begins the status
`stage of the transfer. On completion of the status stage, a Windows host
`requests the hub to reset the device (step 5). The specification doesn’t
`require a reset here, because devices should be able to handle the host's aban-
`doning a control transfer at any time by responding to the next Setup
`packet. Butresetting is a precaution that ensures that the device will be in a
`known state when thereset ends.
`
`IPR2018-00461
`
`
`
`
`9. The host assigns an address. The host controller assigns a unique
`address to the device by sending a Set_Address request. The device reads the
`request, returns an acknowledge, and stores the new address. The device is
`now in the Address state. All communications from this point on use the
`new address. The address is valid until the device is detached or reset or the
`system powers down. On the next enumeration, the device may be assigned
`a different address.
`
`the device’s abilities. The host sends a
`learns about
`10. The host
`Get_Descriptor request to the new address to read the device descriptor, this
`time reading the whole thing. The descriptoris a data structure containing
`the maximum packetsize for Endpoint 0, the numberof configurations the
`device supports, and otherbasic information aboutthe device. The host uses
`this information in the communicationsthatfollow.
`
`The host continues to learn about the device by requesting the one or more
`configuration descriptors specified in the device descriptor. A device nor-
`mally responds to a request for a configuration descriptor by sending the
`descriptor followed by all of that descriptors subordinate descriptors. But a
`Windows host begins by requesting just the configuration descriptor’s nine
`
`USB Complete
`
`FISI Ex 2006-17
`LG v FISI
`
`FISI Ex 2006-17
`LG v FISI
`IPR2018-00461
`
`

`

`IPR2018-00461
`
`
`IDs and (optional) Release Numberretrieved from the device. Ifthere is no
`match, Windows looks for a match with any class, subclass, and protocol
`om the device. After the operating system assigns and
`quests the device to resend descriptors or
`send other class-specific descriptors,
`... An exception to this sequence is composite devices, which have multiple
`interfaces, with each interface requiring a driver, The host can assign these
`drivers only after the interfaces are enabled, which requires the device to be
`configured (as described in the next step).
`12. The host’s device driver selects a configuration. After learning about
`the device from the descriptors, the device driver requests a configuration by
`sending a Set_Configuration request with the desired configuration num-
`ber. Many devices support only one configuration, Ifa device supports mul-
`tiple configurations, the driver can decide which to u
`information it has about how the device will be used, orit may ask the user
`whatto do, or it mayjust select thefirst configuration. The device reads the
`
`ssigned
`
`levice is
`use the
`t or the
`ends a :
`or, this
`taining
`ons the
`
`Enumeration: How the Host Learns about Devices
`bytes. Includedin these bytes is the total length ofthe configuration descrip-
`tor and its subordinate descriptors,
`.
`.
`.
`.
`Windowsthen requests the configuration descriptor again, this time using
`the retrieved total length, up to FPh bytes. This causes the device to send the
`configuration descriptor followed by the interface descriptor(s) for each