US-
`
`COMPLETE
`
`
`Perzp/aemls
`
`SECOND EDITION
`
`Everything Ybu
`Need to Develop
`Custom USB
`
`FISI EX 00000 1
`
`|PR2018—00461
`
`FISI Ex 2006-1
`LG v FISI
`IPR2018-00461
`
`

`

`
`
`USB Complete
`
`Second Edition
`
`Jan Axelson
`
`Everything You Need
`to Develop Custom USB Peripherals
`
`
`
`
`Lakeview Research
`
`Madison, WI 53704
`
`FISI EX 2006—2
`LG V FISI
`|PR2018—00461
`
`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.corn
`Web: http://www.Lvr.com
`
`1413121110987654321
`
`are trademarks or registered trademarks of
`
`Products and services named in this book
`Lakeview Research is aware of a
`their respective companies. In all instances where
`
`trademark claim, the product name appears in initial capital letters, 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 and‘program 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 material in this book. In no event shall the pub-
`
`
`lisher or author be liable for direct, indirect, special, incidental, or consequential dam-
`
`
`ages in connection with, or arising out Of, the construction, performance, or other use of
`the materials contained herein.
`
`
`
`
`
`
`
`
`ISBN‘0—9650819-5-8
`
`Printed and bound in the United States of America
`
`FISI EX 2006—3
`LG V FISI
`
`|PR2018—00461
`
`FISI Ex 2006-3
`LG v FISI
`IPR2018-00461
`
`

`

`inside USB Transfers
`
`5 device. If
`can access
`
`:0 the chip
`
`about how
`
`L make the
`
`Dose of the
`
`
`
`You don’t 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 the inevitable bugs that
`Show up when you try out your circuits and code.
`
`Inside USB Transfers
`
`To design and program a USB device, you need to know a certain amount
`about the inner workings of the interface. This is true even though the hard—
`ware and system software handle many of the details automatically.
`
`This and the next three chapters are a tutorial on how USB transfers data.
`This chapter has essentials that apply to all transfers. The following chapters
`cover the four transfer types supported by USB, the enumeration process,
`and the standard requests used in control transfers.
`
`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,
`I begin with the big picture and work down to the details.
`‘UHHVOidably, some of the things I refer to aren’t explained in detail until
`
`Complete
`
`39
`
`
`
`
`
`
`
`FISI EX 2006—4
`LG V FISI
`|PR2018—00461
`
`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 one place.
`The information in these chapters is dense. If you don’t have a background
`in USB, you won’t absorb it 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 USB interface is the specification published
`by its sponsoring members. The specification document, titled not surpris—
`ingly, Universal Serial Bus Specification,
`is available on the USB Implement—
`ers Forum’s website (www.mhorg). However, by design, the specification‘
`omits information and tips that are unique to any operating system or con—
`troller chip. This type of information is essential when you’re designing a
`product for the real world, so I’ve included it.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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, and take 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
`
`
`
`
`
`
`Transfer Basics
`
`You can divide USB communications into two categories, depending on
`whether they’re used in configuring and setting up the device or in 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 corn—
`munications that perform the functions the device is designed for. For
`example, for a keyboard, the application communications are the sending of
`keypress data to the host to tell an application to display a character.
`
`
`
`
`
`
`
`Configuration Communications
`
`USB Complete
`
`FISI EX 2006—5
`LG V FISI
`|PR2018—00461
`
`FISI Ex 2006-5
`LG v FISI
`IPR2018-00461
`
`

`

`Inside USB Transfers
`
`have two files available: an INF file that identifies the filename and location
`of the device’s driver, and the device driver itself. If the files are available and
`the firmware is in order, the enumeration process is 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 INF file is a text file 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 INF files
`
`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 be fairly 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 the receive 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.
`
`.
`Each data transfer on the bus uses one of four transfer types: control, inter-
`.
`.
`.
`rupt, bulk, or isochronous. Each has a format and protocol suited for partic-
`ular uses.
`
`_
`
`_,
`
`_.y
`
`Managing Data on the Bus
`
`d relevant
`
`_
`
`i
`
`ickground
`5V“, get a
`you need
`
`published ‘
`)t surpris_
`1plement-
`zcification
`
`m or con'
`:signing a
`
`’
`
`:nding on _
`the appli—
`nmunica— .
`3in data.
`3 g
`erates the
`)HS OCCUI‘
`
`the com—
`
`l. for. For
`_
`ending of
`:r.
`
`‘
`i standard
`it’ return
`LCStS .
`
`‘
`
`program— ‘
`)WS must
`
`,
`
`i
`
`
`
`
`USB’S two signal lines carry data to and from all of the devices on the bus.
`The wires form a single transmission path that all of the devices must share.
`(As explained later in this chapter, a cable segment between a 1.x device and
`a 2.0 hub on a high-speed bus is an exception, but even here, all data shares
`the path between the hub and host.) 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.
`
`iomplete
`
`USB Complete
`
`
`
`FISI EX 2006—6
`LG V FISI
`|PR2018—00461
`
`FISI Ex 2006-6
`LG v FISI
`IPR2018-00461
`
`

`

`
` Chapter 3
`
`
`
`Host Spe
`
`
`ENDPOINT2
`
`ENDPOINT2
`
`
`ENDPOINT2
` I—STARTOFFRAME
`
`
`
`DEVICEZlENDPOINT2 DEVICE5.ENDPOINT3
`DEVICE5,ENDPOINT3
`DEVICE5,ENDPOINT3
`DEVICE2‘ENDPOINT0
`DEVICES.ENDPOINT5
`DEVICE2,ENDPOINTa
`DEVICE2.ENDPOINT0
`DEVICES,ENDPOINT5
`STARTOFFRAME
`STARTOFFRAME
`
`
`
`DEVICEI,
`DEVICEll
`
`
`
`
`
`
`Figure 3-1: At low and full speeds, the host schedules transactions within
`
`
`f—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 anywhere it wants within a frame. The process is similar at
`
`
`high speed, but using 125-microsecond microframes.
`
`
`
`
`
`DEVICEl,
`
`UNUSED
`
`UNUSED
`
`l-MILLISECOND FRAME
`
`l-MILLISECOND FRAME
`
`UNUSED
`
`f
`
`I-MILLISECOND FRAME
`
`
`
`A 1.):
`must
`
`A 1.
`
`Chan
`
`In co
`
`spee
`
`help
`isa
`ware.
`
`than
`
`The host is in charge of seeing that all transfers occur as quickly as possible.
`It manages the traffic by dividing time into chunks called frames, or microf—
`rames at 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 timing reference.
`
`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 may all be in a single frame or microframe, or they
`may be spread over multiple (micro)frames.
`
`USB Complete
`
`USB Corn
`
`FISI EX 2006—7
`LG V FISI
`|PR2018—00461
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Because all 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 sends is in response to receiving a request from the host to send data
`Figure 3—2:
`
`:I
`low and full
`or status information.
`
`
`
`
`
`
`
`The
`
`upstr
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`FISI Ex 2006-7
`LG v FISI
`IPR2018-00461
`
`

`

`*‘l
`FRAME
`
`within
`
`(et, followed
`
`ost may
`; is similar at
`
`V as possible.
`s, or microf—
`
`ach frame or
`mes are one
`
`e into eight
`:gins with a
`
`1sfers 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
`3 send data
`
`
`HIGH-SPEED
`DEVICE
`
`
`
`
`_
`HIGH SPEED
`DEVICE
`
`LOW=SPEED
`DEVICE
`
`FULLESPEED
`DEVICE
`
`FULL-SPEED
`DEVICE
`
`'FULL-SPEED ENUMERATION IS REQUIRED.
`ADDITIONAL FULL-SPEED FUNCTIONALITY
`[S OPTIONAL.
`
`Figure 3-2: A USB 2.0 bus uses high'speed whenever possible, switching to
`low and full speeds when necessary.
`
`Complete
`
`USB Complete
`
`Host speed and Bus Speed
`A 1.x host supports low and full speeds. A 2.0 host with user-accessible ports
`must support low, 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 destinations 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.): hubs.
`
`
`
`Inside USB Transfers
`
`The traffic on a bus segment is high speed only if the host controller and all
`upstream (toward the host) hubs are 2.0—compliant. Figure 3—2 illustrates. A
`
`2.0 HOST
`AND
`
`ROOT HUB
`
`
`F
`
`LOW/FULL SPEED
`
`HIGH SPEED
`
`IGH SPEED
`
`LOW SPEED
`
`
`
`
`
`
`
`
`
`PEED
`FULL-SPEED
`HIGH-SPEED
`CE
`DEVICE
`DEVICE
`
`
`
`:ULL SPEED'
`Low SPEED
`FULL SPEED
`
`FULL SPEE
`
`FULL SPEED
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`HSIEX2006£
`LG\/HS|
`|PR2018—00461
`
`FISI Ex 2006-8
`LG v FISI
`IPR2018-00461
`
`

`

`
`
`
`Chapter 3
`
`
`
`
`high-speed bus may also have 1.x hubs, and if so, any bus segments down—
`stream (away from the host) are low or full 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 and full
`speeds, even if the bus has 2.0 hubs and devices.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Elements of a Transfer
`
`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.
`
`
`
`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. 80 that’s where we’ll begin.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`The specification defines a device endpoint as “a uniquely addressable por—
`tion of a USB device that is 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 I’ll explain, a control end—
`point is a special case that is bidirectional.
`
`The unique address required for each endpoint consists of an endpoint
`number and 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
`
`
`
`
`
`
`
`
`
`
`
`USB Complete
`
`|PR2018—00461
`
`FISI EX 2006—9
`LG V FISI
`
`
`
`
`
`
`
`
`
`
`FISI Ex 2006-9
`LG v FISI
`IPR2018-00461
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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
`CTS lines in the RS—252 interface. In software handshaking, the same lines
`that carry the data also carry handshaking codes. An example is the XON
`and XOFF codes transmitted on the data lines in RS—232 links.
`
`USB uses software handshaking. A code indicates the success or failure of all
`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 handshaking signals 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 bus error. In all cases, the receiver
`of the handshake, or lack of one, uses the information to help it decide what
`to do next. Table 3-5 shows the status indicators and where they transmit in
`
`each transaction type.
`
`ACK
`
`
`
`
`
`
`
`
`
`wwwawvm«WMMMW
`
`
`
`
`
`
`NAK (negative acknowledge) means the device is busy or has no data to
`return. If the host sends data at a time when the device is too busy to accept
`
`
`fivemgtwwmwwwm‘w
`it, the device sends a NAK in 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 host retries later.
`
`
`
`
`
`
`
`Chapter 3 Handshaking
`
`
`
`
`
`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
`
`.
`
`USB Complete
`
`FISI EX 2006—10
`LG V FISI
`|PR2018—00461
`
`FISI Ex 2006-10
`LG v FISI
`IPR2018-00461
`
`

`

`Inside USB Transfers
`
`e signal depend
`
`
`
`Table 36: The location, source, and contents of the handshak
`‘ on the type of transaction.
`
`motion type—[Bata packet
`Handshake
`Data packet
`Handshake
`source
`contents
`or PING query
`packet source
`packet
`contents
`Sew?
`ACK
`device
`data
`host
`r’“
`—r
`
` IBTTT host
`Tl
`data
`device
`ACK,
`NAK,
`STALL,
`NYET (high
`speed only),
`ERR (from hub in
`complete split)
` data,
`ACK
`NAK,
`STALL,
`ERR (from hub in
`complete split)
`l'
`
`flACK,
`NAK,
`STALL
`
`
`
`
`
`ing, lnfm-
`
`sing, cledi~
`3 RTS and
`same lines
`the XON
`
`lure of all
`
`rol trans-
`
`ire of the
`
`.gh some
`
`STALL,
`
`expected
`receiver
`
`,de What
`nsmit in
`
`
`
`(high speed only)
`
`
`
` H0116
`
`
`
`
`
`Hosts never send NAK. lsochronous endpoints don’t support NAK because
`they have no handshake packet for returning the NAK. If a device or the
`host misses isochronous data, it’s gone.
`
`STALL
`
`The STALL handshake can have any of three meanings: unsupported con—
`trol request, control request failed, or endpoint failed.
`When a device receives a control-transfer request that the endpoint doesn’t
`support, the device returns a STALL t0 the host. The device also sends a
`STALL ifit supports the request but for some reason can’t take the requested
`action. For example, if the host sends a Set_C0nfigurati0n 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 of stall a protocol stall.
`
`USB Complete
`
`FISI EX 2006—11
`LG V FISI
`|PR2018—00461
`
`FISI Ex 2006-11
`LG v FISI
`IPR2018-00461
`
`

`

`Enumeration: How the Host Learns aboUt Devices
`
`arantee a fate
`
`Enumeration:
`
`How the Host Learns
`
`about Devices
`
`\
`
`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 order to design a USB
`peripheral, but understanding a certain amount is essential in creating the
`
`USB Complete
`
`
`
`
`Before applications can communicate with a device, the host needs to learn
`about the device and assign a device driver. Enumeration is 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.
`
`
`
`
`
`
`
`FISI Ex 2006—12
`LG v FISI
`|PR2018—00461
`
`FISI Ex 2006-12
`LG v FISI
`IPR2018-00461
`
`

`

`ICSPOHdS ‘L'O enumeration requests.
`
`The Process
`
`
`
`host. On system boot—up,
`are attached, including additional hubs and devices attached to the first tier
`of devices. After boot—up, the host continues to poll periodically to learn of
`any newly attached or removed devices.
`‘
`
`
`
`
`Figure 5-1:
`USB devic
`and others
`
`
`
`In a
`
`USB Complete
`
`
`
`
`
`
`
`
`
` cod
`
`
`
`
`
`chip
`Device Manager display in the Co
`
`ample.
`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
`
`removes the device from the display
`
`
`the l
`and
`
`firm
`
`FISI EX 2006—13
`LG V FISI
`|PR2018—00461
`
`FISI Ex 2006-13
`LG v FISI
`IPR2018-00461
`
`

`

`
`
`: Ports (COM :3: LPTJ
`1!?! SCSI controllers
`Sound“ video and game controllers
`System devices
`
`”
`
`
`
`6%» Intel BE3?1AB,’EB F'Cl u: use Univers
`f- @9 9.005500
`fifi use Root Hub
`
`a! Host Controller
`
`
`
`
`
`
`
`
`
`
`
`Flatmates V‘
`
`i:
`
`: Refresh
`
`J
`
`_
`
`thmuve-_
`
`;
`
`"__F°rr,n
`
`code for enumerating,
`will look for a special text file calle
`use for the device.
`
`Enumeration Steps
`During the enumeration process, a device moves through four of the six
`evice states defined by the specification: Powered, Default, Address, and
`
`USB Complete
`
`95
`
`FISI EX 2006—14
`LG V FISI
`|PR2018—00461
`
`FISI Ex 2006-14
`LG v FISI
`IPR2018-00461
`
`

`

`
`
`
`
`
`
`
`Configured. (The other states are Attached and Suspend.) In each state) the
`device has defined capabilities and behavior.
`
`
`
`
`2. The hub detects the device.
`The hub monitors the voltages on the signal
`lines of each of its ports. The
`hub has a 15—kilohrn pull—down resistor on
`each of the ports two signal
`lines (D+ and D-), While a device has a
`
`1. 5—kilohm pull
`
`
`
`
`
` 3. The host learns of the new device. Each hub uses its interrupt pipe to
`
`
`
`
`
`requests described here are standard
`Get_P0rt__Status and the other
`
`
`hub—class requests that all hubs understand. The information returned tells
`the host when a device is newly attached.
`
`dicates only whether the hub or a
`
`
`
`
`
`
`
`
`USB Complete
`
`FISI EX 2006—15
`LG V FISI
`|PR2018—00461
`
`
`
`FISI Ex 2006-15
`LG v FISI
`IPR2018-00461
`
`

`

`Enumeration: How the Host Learns about Devices
`
`GetflPorLStatus 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 hub resets 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 USB data lines 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 sends the reset only to the new device. Other hubs and devices on the
`bus don’t see it.
`
`6. The host learns if a full-speed device supports high speed. Detecting
`whether a device supports high speed uses two special signal states. In the
`Chirp] state, the D+ line only is driven and in the Chirp K state, the D- line
`only is driven.
`
`
`
`Duringthe 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 Is. When the device detects the pattern KJKJKJ, it removes its
`full—speed pull up and performs all further communications at high speed. If
`the hub doesn’t respond to the device’s Chirp K, the device knows it must
`continue to communicate at full 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
`device is still in the reset state. If necessary, the host repeats the request until
`the device has exited the reset state.
`
`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
`respond to control transfers over the default pipe at Endpoint 0. The device
`can now communicate with the host, using the default address of 00h. The
`device can draw up to 100 milliamperes from the bus.
`
`USB Complete
`
`
`
`FISI EX 2006—16
`LG V FISI
`|PR2018—00461
`
`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 devic€
`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 packet size
`supported by Endpoint 0. A Windows host requests 64 bytes, but after
`receiving just one packet (whether or not it 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. But resetting is a precaution that ensures that the device will be in a
`known state when the reset ends.
`
`
`
`
`
`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.
`
`10. The host
`
`learns about
`
`the device’s abilities. The host sends a
`
`Get_Descriptor request to the new address to read the device descriptor, this
`time reading the whole thing. The descriptor is a data structure containing
`the maximum packet size for Endpoint 0, the number of configurations the
`device supports, and other basic information about the device. The host uses
`this information in the communications that follow.
`
`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 descriptor’s subordinate descriptors. But a
`Windows host begins by requesting just the configuration descriptor’s nine
`
`USB Complete
`
`FISI EX 2006—17
`LG V FISI
`|PR2018—00461
`
`FISI Ex 2006-17
`LG v FISI
`IPR2018-00461
`
`

`

`Enumeration: How the Host Learns about Devices
`
`maximum
`
`to device
`
`:vice at a
`
`to device
`
`Lcket size
`
`but after
`
`he status
`
`)ws host
`
`t doesn’t
`
`t’s aban—
`
`tt Setup
`1 be in a
`
`unique
`eads the
`
`levice is
`
`use the
`
`t or the
`
`ssigned
`
`ends a
`
`or, this
`
`taining
`ms the
`)st uses
`
`bytes. Included in these bytes is the total 1
`tor and its subordinate descriptors.
`Windows then requests the configuration descriptor again, this time using
`Fh bytes. This causes the device to send the
`d by the interface descriptor(s) for each con—
`figuration, followed by endpoint descriptor(s) for each interface. If the
`descriptors total more than FFh bytes, Windows obtains the full set of
`descriptors on a third request. Each descriptor begins with its length and
`type, to enable the host to parse (pick out the individual elements in) the
`data that follows. The Descriptors section in this Chapter has more on what
`each descriptor contains.
`
`
`
`
`ength of the configuration descrip—
`
`
`
`FISI EX 2006—18
`LG V FISI
`|PR2018—00461
`
`FISI Ex 2006-18
`LG v FISI
`IPR2018-00461
`
`

`

`
`
`Chapter 5
`
`
`
`
`
`
`
`
`request and sets its configuration to match. The device is now in the Config—
`ured state and the device’s interface(s) are enabled.
`
`The host now assigns drivers for the interfaces in composite devices. As with
`other devices, the host uses the information retrieved from the device to find
`a matching driver.
`
`The device is now ready for use.
`
`The other two device states, Attached and Suspended, may exist at any time.
`Attached state. If the hub isn’t providing power (VBUS)
`to the port, the
`device is in the Attached state. This may occur if the hub has detected an
`over‘current condition, or if the host requests the hub to remove power
`from the port. With no power on VBUS, the host and device can’t communi—
`cate, so from their perspective, the situation is the same as when the device
`isn’t attached at all.
`
`Suspend State. The Suspend state means the device has seen no activity,
`including Start—of—Frame markers, on the bus for at least 3 milliseconds. In
`the Suspend state, the device must consume minimal bus power. Both con—
`figured and unconfigured devices must support this state. Chapter 19 has
`more details.
`
`Enumerating a Hub
`
`Hubs are also USB devices, and the host enumerates a newly attached hub
`in exactly the same way as it enumerates a device. If the hub has devices
`attached, the host also enumerates each of these after the hub informs the
`host of their presence.
`
`Device Removal
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`When a user removes a device from the bus, the hub disables the device’s
`port. The host learns that the removal occurred after polling the hub, learn—
`ing that an event has occurred, and sending a Get_Port_Status request to
`find out what the event was. Windows then removes the device from the
`Device Manager’s display and the device’s address becomes available to
`another newly attached device.
`‘
`100
`USB Complete
`
`
`
`
`
`
`
`
`
`
`
`
`return
`
`endpoi ,:
`bytes.
`.
`tor. De,
`descript
`and the
`behavtolg
`USB Complei
`
`FISI EX 2006—19
`LG V FISI
`|PR2018—00461
`
`FISI Ex 2006-19
`LG v FISI
`IPR2018-00461
`
`

`

`Chapter 20
`
`Low- and Full-speed Bus States
`
`Low and full speed support the same bus states, though some are defined
`differently depending on the speed.
`
`Differential 1 and Differential 0
`
`Single-Ended Zero
`
`The Single—Ended—Zero state occurs when both D+ and D- are logic low.
`The bus uses the SingleEnded—Zero state when entering the End—of—Packet,
`Disconnect, and Reset states.
`
`Single-Ended One
`
`The complement of the Single-Ended Zero is the Single-Ended One. This
`occurs when bOth D+ and D— are logic high. This is an invalid bus state and
`should, never occur.
`
`Data J and K States
`
`In addition to the Differential 1 and 0 states, which are defined by voltages
`on the lines, USB also defines two Data bus states, I and K. These are
`defined by whether the bus state is Differential 1 or 0 and whether the cable
`segment is low or full speed:
`
`
`Bus State
`
`
`Data State
`
`
`
`men transferring data, the two states on the bus are Differential 1 and Dif~
`ferential 0. A Differential 1 exists when D+ is a logic high and D- is a logic
`low. A Differential 0 exists when D+ is a logic low and D— is a logic high.
`Chapter 21 has details about the voltages that define logic low and high,
`The Differential 1s and Os don’t translate directly into 15 and Os in the bytes
`being transmitted, but instead indicate either a change in logic level, no
`change in logic level, or a bit stuff, as explained later in this chapter.
`
`
`
`
`
`
`
`
`Low Speed
`DifferentialO J
`
`Full Speed
`
`Differentiall
`
`K
`
`USB Complete
`
`FISI EX 2006—20
`LG V FISI
`|PR2018—00461
`
`FISI Ex 2006-20
`LG v FISI
`IPR2018-00461
`
`