includes 553 2.0
`
`COMPLET
`
`SECOEB Earner:
`
`US-
`
`
`
`$1 With firmware tips & host code
`in Visual Basic and Visual C++
`
`FISI Ex 2006—p 1
`Huawei v FISI
`
`|PR2018—OO487
`
`
`
`FISI Ex 2006-p 1
`Huawei v FISI
`IPR2018-00487
`
`

`

`USB Complete
`
`Everything Yea Need
`to Develep Custom USB Peripherals
`
`Second Editien
`
`Jan Axelson
`
`Lakeview Research
`
`Madison, WI 53704
`
`FISI Ex 2006-p 2
`Huawei v FISI
`
`|PR2018—OO487
`
`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
`
`141.31le, 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 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—96508l9~5~8
`
`Printed and bound in the United States of America
`
`FISl'iEx 2006-10 3
`Hua‘tWei v FISI
`|PR2018—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 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 ,Speczygcazrion, is available on the USE Implementw
`ers Forums website (wwwmhorg). 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.
`
`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 appliw
`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 coma
`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
`
`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 programw
`ming involved. However,
`to complete the enumeration, Windows must
`
`40
`
`USB Complete
`
`FISI EX ZDOG-p 4
`‘ Huawei v F.|S|
`IP’R2018-00487
`
`FISI Ex 2006-p 4
`Huawei v FISI
`IPR2018-00487
`
`

`

`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 USE 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.
`
`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 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.
`
`USB Complete
`
`41
`
`FISI Ex 2006—p 5
`Huawei v FISI
`
`|PR2018—00487
`
`FISI Ex 2006-p 5
`Huawei v FISI
`IPR2018-00487
`
`

`

`Enumeration: How the Host Learns about Devices
`
`5
`
`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 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 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
`
`|PR2018—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
`
`One of the duties of a hub is to detect
`the attachment and removal of
`devices. Each hub has an interrupt IN pipe for reporting these events to the
`host. On system hoot~up, the host polls its root hub to learn if any devices
`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.
`
`the host sends a series of requests to the
`On learning of a new device,
`device’s hub, causing the hub to 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 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 be invisible 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 INF file and device
`driver.
`
`When enumeration is complete, Windows adds the new device to the
`Device Manager display in the Control Panel. Figure 5—], 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
`removes the device from the display.
`
`94
`
`USB Complete
`
`'p
`
`-
`
`i
`
`'
`
`--
`
`-'
`
`. w
`'
`
`~
`
`-
`
`-
`
`'
`
`‘
`
`*'._
`
`FISI,Ex2006-p’7_
`Huawei v FIfSI
`|PR2018—00487‘
`
`FISI Ex 2006-p 7
`Huawei v FISI
`IPR2018-00487
`
`

`

`Enumeration: How the Host Learns about Devices
`
`
`
`~51 title In
`lvlunilm 5
`
`'
`
`
`
`
`2+3 Parts .33, A 2 LPT}
`£3! SEES-l tzvjntrcllers
`Sound. 'w‘lClBU and game controllers
`”System devices
`% Tape ain't-2e controller's
`Tape dl as
`
`Q Universal Serial Bus controllers
`lfib General purpose USE Huh
`7 5% lniel 82371AB/EE‘ F‘Cl to USE Universal Host Controller
`' dig soc—50m
`-
`if? use Rani Hui:
`Riéjresh ; J , [Ra-rid '
`
`
`
`
`
`Figure 5-1: The Device Manager in Windows’ Control Panel lists all detected
`USB devices. Some devices are listed under Universal Serial Bus controllers,
`and others are listed by type, such as keyboard or modern.
`
`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. On the host side, under Windows there’s no need to write
`code For enumerating, because Windows handles it automatically. Windows
`will look for a special text file called an INF file 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
`
`USB Complete
`
`95
`
`FISI Ex 2006-p 8
`Huawei v FISI
`|PR2018—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
`{11116.
`
`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 Powered state.
`
`2. The hub detects the device. The hub monitors the voltages on the signal
`lines of each of its ports. The hub has a IS’kilohm pull—down resistor on
`each of the port’s two signal
`lines 03+ and ll), While a device has a
`1.5—kilohm pull~up resistor on either D+ for a full—speed device or D— for a
`lowrspeed device. High~speed devices attach at full speed. When a device
`plugs into a port, the device’s pullwup brings that line high, enabling the hub
`to detect that a device is attached. Chapter 18 has more on how hubs detect
`devices.
`
`On detecting a device, the hub continues to provide power but doesn’t yet
`transmit USB traffic to the device, because the device isn’t ready to receive it.
`
`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 (and if so, which port) has experienced an event. When the host learns
`of an event, it sends the hub a Get_PortflStatus request to find out more.
`Get_Porthtatus and the other
`requests described here are standard
`hub~class requests that all hubs understand. The information returned tells
`the host when a device is newly attached.
`
`4. The hub detects Whether a device is low or full speed. Just before the
`hub resets the device, the hub determines whether the device is low or hill
`speed by examining the voltages on the two signal lines. The hub detecrs 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 zoos-p 9
`Huawei v FISI:
`|PR2018—00487
`
`FISI Ex 2006-p 9
`Huawei v FISI
`IPR2018-00487
`
`

`

`Enumeration: How the Host Learns about Devices
`
`GetfiPort“Status request. USB 1.); 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 highwspeed—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_P0rt_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 13+ line only is driven and in the Chirp K state, 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, J5. When the device detects the pattern KJKJK], 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
`devices USB registers are in their reset states and the device is ready to
`respond to control transfers over the default pipe at Endpoint O. The device
`can now communicate with the host, using the default address of 00b. The
`device can draw up to 100 milliamperes from the bus.
`
`USB Complete
`
`97
`
`FISI Ex 2006-p 10
`Huawei v FISI
`|PR201'8—00487
`
`FISI Ex 2006-p 10
`Huawei v FISI
`IPR2018-00487
`
`

`

`Chapter 5
`
`8. The host sends a Get_Descriptor request to iearn 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 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 abanfl
`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.
`
`9c 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
`
`GetmDescriptor 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 oi: 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 descriptors nine
`
`98
`
`USB Complete
`
`‘»
`
`FISI’EX2006-p11
`Huawei v' FISII
`IPR2018-00487
`
`FISI Ex 2006-p 11
`Huawei v FISI
`IPR2018-00487
`
`

`

`Enumeration: How the Host Learns about Devices
`
`bytes. Included in these bytes is the total length of the configuration descrip—
`tor 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
`configuration descriptor followed 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 hosr 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, Windows tries to match the
`information stored in the system’s INF files with the Vendor and Product
`lDS and (optional) Release Number retrieved 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
`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 use based on whatever
`information it has about how the device will be used, or it may ask the user
`what to do, or it may just select the first configuration. The device reads the
`
`USB Complete
`
`99
`
`FISI Ex 2006-p 12
`Huawei v FISl_
`|PR2018—00487
`
`FISI Ex 2006-p 12
`Huawei v FISI
`IPR2018-00487
`
`

`

`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 communiw
`care, 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 leasr 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_Po:rt_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
`
`pFISI Ex2006-p'1i3',
`Huawei v FISI
`|PR2018—00487
`
`FISI Ex 2006-p 13
`Huawei v FISI
`IPR2018-00487
`
`