OO) eal
`
`SECOND EDITION
`
`Includes USB 2.0USB
`
`IPR2018-00487
`
`eeUMEee mace
`in Visual Basic and Visual C++
`
`FISI Ex 2006-p 1
`Huawei v FISI
`
`
`
`FISI Ex 2006-p 1
`Huawei v FISI
`IPR2018-00487
`
`

`

`USB Complete
`
`Everything You Need
`to Develop Custom USBPeripherals
`
`SecondEdition
`
`Jan Axelson
`
`Lakeview Research
`
`Madison, WI 53704
`
`FISI Ex 2006-p 2
`Huawei v FISI
`IPR2018-00487
`
`FISI Ex 2006-p 2
`Huawei v FISI
`IPR2018-00487
`
`

`

`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
`
`1413 12 11 10987654321
`
`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 appearsin 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 ofthis 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 thereader.
`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 authorbe 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-96508 19-5-8
`
`Printed and boundin the United States of America
`
`.. FISHEx 2006-p 3
`Huaweiv FISI
`IPR2018-00487
`
`FISI Ex 2006-p 3
`Huawei v FISI
`IPR2018-00487
`
`

`

`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 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.usb.org). However, by design,
`the specification
`omits informationand tips 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 included it.
`
`Transfer Basics
`
`You can divide USB communications into two categories, depending on
`whetherthey're used in configuring and setting 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
`whenthe 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 communications are the sending of
`keypress data to the hostto tell an application to display a character.
`
`Configuration Communications
`
`During enumeration, the device’s firmware responds toaseries 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
`
`40
`
`USB Complete
`
`FISI Ex 2006-p 4
`' Huaweiv FISI
`IPR2018-00487
`
`FISI Ex 2006-p 4
`Huawei v FISI
`IPR2018-00487
`
`

`

`Inside USB Transfers
`
`have twofiles 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 enumeration processis invisible to users.
`Depending on the device and how it will be used, the device driver may be
`one that’s included with Windowsor one provided by the product vendor.
`The INFfile 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 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 canbe 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, bull, or isochronous. Each has a format and protocol suited for partic-
`ular uses.
`
`Managing Data on the Bus
`
`USB’s two signal lines 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, 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.
`
`USB Complete
`
`41
`
`FISI Ex 2006-p 5
`Huawei v FISI
`IPR2018-00487
`
`FISI Ex 2006-p 5
`Huawei v FISI
`IPR2018-00487
`
`

`

`Enumeration: How the Host Learns about Devices
`
`o
`
`Enumeration:
`How the Host Learns
`about Devices
`
`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 andloading 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 order to design a USB
`peripheral, but understanding a certain amount Is essential in creating the
`
`USB Complete
`
`93
`
`FISI Ex 2006-p 6
`Huawei v FISI
`IPR2018-00487
`
`FISI Ex 2006-p 6
`Huawei v FISI
`IPR2018-00487
`
`

`

`Chapter 5
`
`descriptors that will reside in the device and writing the firmware that
`responds to enumeration requests.
`
`The Process
`
`the attachment and removal of
`One of the duties of a hub is to detect
`devices. Each hub hasan interrupt IN pipe for reporting these events to the
`host. On system boot-up, the host polls its root hub to learn if any devices
`are attached, including additional hubs and devices attached to thefirst tier
`of devices. After boot-up, the host continues to poll periodically to learn of
`any newly attached or removed devices.
`Onlearning of a new device,
`the host sends a series of requests to the
`device's hub, causing the hub to establish a communications path between
`the host and the device. The host then atcempts to enumerate the device by
`sending control transfers containing standard USB requests to Endpoint 0.
`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
`actions.
`
`From the user’s perspective, enumeration should beinvisible and automatic,
`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
`first use, the user needs to provide a disk containing the INFfile and device
`driver.
`
`When enumeration is complete, Windows adds the new device to the
`Device Managerdisplay in the Control Panel. Figure 5-1 shows an example.
`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.
`
`94
`
`USB Complete
`
`Po ESL Bx 2008-97
`ns
`-
`Huawei v FISI
`IPR2018-00487
`
`FISI Ex 2006-p 7
`Huawei v FISI
`IPR2018-00487
`
`

`

`Enumeration: How the Host Learns about Devices
`
`
`
`
`
`
`hacer
`
`
`# hdonitars
`
`
`
`
`
` 2 Mouse
`Be Network adanters
`YP Ports (COM& LPT)
`os
`~
`
`ffs SCSI contrallers
`
`Sound, video and game controllers
`
`
` al System devices
`et Tape drive controllers
`Tape drives
`
`
`
`oe (Ue ieee cages
`
`: ee General purgose USB Hub
`
`® sing Injal 82371AB/EB PCl to USE Universal Host Controller
`
`
`» Ge RDO-AOOO
`
`
`~ Gee USE Raat Hub
`
`
`
` Retest | Beno
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Figure 5-1: The Device Manager in Windows’ Control Panellists all detected
`USB devices. Some devicesare listed under Universal Serial Bus controllers,
`and others are listed by type, such as keyboard or modem.
`
`In a typical peripheral, the device's program code contains the information
`the host will request, and a combination of hardware 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. Onthe host side, under Windowsthere’s no need to write
`code for enumerating, because Windowshandles it automatically. Windows
`will look for a special text file called an INF file chat 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
`
`USB Complete
`
`95
`
`a
`
`FISI Ex 2006-p 8
`Huawei v FISI
`IPR2018-00487
`
`FISI Ex 2006-p 8
`Huawei v FISI
`IPR2018-00487
`
`

`

`Chapter 5
`
`Configured. (The other states are Attached and Suspend.) In each state, the
`device has defined capabilities and behavior.
`The steps below are a typical sequence of events that occurs during enumer-
`ation under Windows. The device firmware shouldn't assume that the enu-
`meration requests and events will occur in a particular order, however. The
`device should be ready to detect and respond to any control request at any
`
`time.
`
`1. The user plugs a device into a USB port. Or the system powers up with
`a device already plugged into a port. The port may be on the root hub at the
`host or attached to a hub that connects downstream of the host, The hub
`provides power to the port, and the device 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-upresistor on either D+ for a full-speed device or D- for a
`low-speed device. High-speed devices attach at full speed. When a device
`plugs into a port, the device’s pull-up brings that line high, enabling the hub
`to detect that a device is attached. Chapter 18 has more on how hubsdetect
`devices.
`
`On detecting a device, the hub continues to provide power but doesnt yet
`transmit USB traffic to the device, because the deviceisn’t ready to receiveit.
`3. The host learns of the new device. Each hub uses its interrupt pipe to
`report events at the hub. The report indicates only whether the hub or a
`port (andif so, which port) has experienced an event. Whenthe host learns
`of an event, it sends the hub a GetPortStatus request to find out more.
`Get_Port_Status and the other
`requests described here are standard
`hub-class requests that all hubs understand. The information returned tells
`the host whena device is newly attached.
`4, The hub detects whether a device is low orfull speed. Just before the
`hub resets the device, the hub determines whether the device is low or full
`speed by examiningthe voltages on the twosignal lines. The hub detects the
`speed of a device by determining which line has the higher voltage when
`idle. The hub sends the information to the host in response to the next
`
`96
`
`USB Complete
`
`FISI Ex 2006-p 9
`Huaweiv FISI
`IPR2018-00487
`
`FISI Ex 2006-p 9
`Huawei v FISI
`IPR2018-00487
`
`

`

`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 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.) ‘Ihe
`hub sends the reset only to the new device. Other hubs and devices on the
`bus don’tseeit.
`
`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 J 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 andJs. When the device detects the pattern KJKJKJ, it removesits
`full-speed pull up and performsall further communicationsat 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 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
`respondto 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
`
`97
`
`FIS] Ex 2006-p 10
`Huaweiv FISI|
`IPR2018-00487
`
`FISI Ex 2006-p 10
`Huawei v FISI
`IPR2018-00487
`
`

`

`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 ofthe device descriptor contains the maximum packet size
`supported by Endpoint 0. A Windows host requests 64 bytes, but after
`receiving just one packet (whether ornot 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 chat the device will be in a
`known state whenthe 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 chis point on use the
`new address. The address is valid until the device is detached or reset or the
`system powers down. Onthe 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 descriptor is a data structure containing
`the maximumpacketsize for Endpoint 0, the numberof 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 byall of that descriptor’s subordinate descriptors. But a
`Windows host begins by requesting just the configuration descriptor’s nine
`
`98
`
`USB Complete
`
`*'
`
`FISFEx 2006-p 11
`Huawei vFISI
`IPR2018-00487
`
`FISI Ex 2006-p 11
`Huawei v FISI
`IPR2018-00487
`
`

`

`Enumeration: How the Host Learns about Devices
`
`bytes. Included in these bytesis the total length of the configuration descrip-
`cor and its subordinate descriptors.
`this time using
`Windows then requests the configuration descriptor again,
`the retrieved total length, up to FFh bytes. This causes the device to send the
`configurationdescriptorfollowed 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.
`
`11. The host assigns and loads a device driver (except for composite
`devices). After the host learns as much as it can about the device from its
`descriptors, it looks for the best match in a device driver to manage commu-
`nications with the device. In selecting a driver, Windowstries to match the
`information stored in the system’s INF files with the Vendor and Product
`IDs and (optional) Release Numberretrieved from the device. If there is no
`match, Windows looks for a match with any class, subclass, and protocol
`values retrieved from the device. After the operating system assigns and
`loads the driver, the driver often requests the device to resend descriptors or
`sendotherclass-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 nextstep).
`12. The host’s device driver selects a configuration. Aftcr 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. If a device supports mul-
`tiple configurations, the driver can decide which to use based on whatever
`information it has about how the device will be used, or it may ask the user
`whatto do,or it mayjust select the first configuration. The device reads the
`
`USB Complete
`
`99
`
`FIS] Ex 2006-p 12
`Huawei v FISI |
`IPR2018-00487
`
`FISI Ex 2006-p 12
`Huawei v FISI
`IPR2018-00487
`
`

`

`Chapter 5
`
`request andsets its configuration to match. The device is now in the Config-
`ured state and the device’s interface(s) are enabled.
`
`The host now assignsdrivers for the interfaces in composite devices. As with
`other devices, the host uses the information retrieved from the device to find
`a matchingdriver.
`
`The device is now readyfor use.
`
`The other two device states, Attached and Suspended, mayexist at any time.
`
`Attached state. If the hub isn’t providing power (VBUS) to the port, the
`device is in the Attachedstate. 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 cant communi-
`cate, so from their perspective, the situation is the same as when the device
`isn't attachedatall.
`
`Suspend State. The Suspend state means the device has seen no activity,
`including Start-of-Frame markers, on the busfor at least 3 milliseconds. In
`the Suspendstate, 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
`
`Hubsare 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 hostlearns 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
`
`FISI Ex 2006-p13.
`Huawei v FISI
`IPR2018-00487
`
`FISI Ex 2006-p 13
`Huawei v FISI
`IPR2018-00487
`
`