USB常见问题-接口/总线/驱动-飞外网

飞外网>接口/总线/驱动>USB常见问题

Microsoft Windows operaTIng systems (Windows 98 and later) include naTIve support for devices and systems that comply with the Universal Serial Bus (USB) specificaTIon. This article provides answers to frequently asked questions from driver developers who need intermediate level details about the USB stack and features supported in USB.

This particular FAQ is for developers who are knowledgeable about USB and writing USB drivers that work with Windows operating systems.

Unless otherwise specified, the information in this paper pertains to Windows 2000 and later operating systems.

Additional documentation for USB device and driver support is available in the current version of the Windows Driver Development Kit (DDK), through the MSDN developer program library, and on USB Architecture and Driver Support.

A USB 2.0 hub can have one transaction translator (TT) for all downstream-facing ports on the hub (single TT), or it can have one TT for each downstream-facing port on the hub (multiple TT).

The value of the bDeviceProtocol field of the USB device descriptor and the bInterfaceProtocol field in the USB interface descriptor indicate whether a hub is single-TT or multi-TT:

Multi-TT. bDeviceProtocol == 0x02

The driver Usbhub.sys uses this setting to enable multi-TT mode or single-TT mode. On Windows XP and later operating systems, Usbhub.sys always enables multi-TT mode on a multi-TT hub.

For additional details about TT layout, see Sections 11.14.1.3 and 11.23.1 of the USB 2.0 specification, which is available from the USB website at http://www.usb.org/developers/docs .

A USB device has two choices for storing serial numbers in the iSerialNumber field (in the USB device descriptor):

iSerialNumber != 0x00 : The USB device has a serial number and it is stored at the string index indicated in iSerialNumber.

If the device has a serial number, Microsoft requires that the serial number uniquely identify each instance of the same device. For example, if two device descriptors have identical values for the idVendor, idProduct, and bcdDevice fields, the iSerialNumber field will distinguish one from the other.

Windows Plug and Play requires that serial numbers across multiple buses follow specified rules. Every byte in a USB serial number is checked for correctness. If a single invalid byte is found, the serial number is discarded and the device is treated as if it had no serial number.

Invalid bytes in serial numbers are indicated below:

Byte value 0x2C is invalid.

For additional details on the iSerialNumber field, see Section 9.6.1 of the USB 2.0 specification, which is available from the USB website at http://www.usb.org/developers/docs .

A USB device indicates the presence of a serial number by setting the iSerialNumber field of the USB device descriptor to a nonzero value. To retrieve the serial number, Windows issues a string request with the language identifier (LANGID) set to 0x0409 (U.S. English). The LANGID 0x0409 is always used by Windows operating systems, irrespective of the language of the installed version of Windows.

On a localized build of Windows, the string request sent to the device contains the language identifier (LANGID) of the user’s context. If the device does not support that LANGID, the operating system will reissue the string request in U.S. English (LANGID = 0x0409).

The function IsDeviceHighSpeed() returns the actual operational mode of the device in its current tree topology. If a USB Hi-Speed-capable device is connected to a USB 1.1 hub or a full speed host controller, then the function will indicate that the device is working at full speed.

On Microsoft Windows 2000, the maximum size of a USB transfer is determined by the device driver that is loaded for the USB device. The maximum size of USB transfers is determined in one of the following ways:

When the device driver selects the configuration of the device by calling the URB_FUNCTION_SELECT_CONFIGURATION function.
 

When the device driver selects an alternative interface for the device by calling the URB_FUNCTION_SELECT_INTERFACE function.

In most cases, a USB transfer on Windows 2000 has no hard-coded size limit except the limit that is defined by the client driver.

On the Microsoft Windows XP and Microsoft Windows Server 2003 operating systems, the maximum size of a USB transfer is defined either by the miniport driver of the USB host controller or by the USB port driver (Usbport.sys). The maximum size of a USB transfer is not defined by the client driver of the device.

If you use more than the maximum size of a USB transfer, the transfer request may fail, or a stop error may appear on a blue screen.

On Windows XP and Windows Server 2003, when the maximum size of a transfer for a bulk endpoint is less than or equal to 4 KB, the port driver splits the transaction into multiple transfers. Theoretically, this behavior makes the maximum size of a USB transfer unlimited for these endpoints.

For additional information, please refer to Microsoft Knowledge Base article 832430.

A USB device with more than one interface on the first configuration is treated as a composite device. Windows XP (prior to Service Pack 2) mandates that interface numbers follow these rules:

Interface numbers must be consecutive and increasing.

Windows XP Service Pack 2 (SP2) relaxed the requirement that interface numbers be consecutive by making changes to the driver Usbccgp.sys. Beginning with SP2, interface numbers need only be increasing.

For additional information about interface numbers, see Microsoft Knowledge Base article 814560.

Windows has provided support for USB composite devices since Windows 98. The driver Usbhub.sys supports composite devices on the following operating systems:

Additional alternate setting numbers must be consecutive and increasing.

For additional information on alternate settings, see Section 9.6.5 of the USB 2.0 specification, which is available from the USB Web site at http://www.usb.org/developers/docs .

Windows has provided support for USB composite devices since Windows 98. The driver Usbhub.sys supports composite devices on the following operating systems:

Windows 2000

A newer driver for composite devices, Usbccgp.sys, was released with Windows Millennium Edition (Me). Although it may still be possible to load Usbhub.sys as the parent driver for the composite device, we do not recommend it.

Windows Server 2003

If you are developing drivers, you should ensure that the correct driver is loaded on the operating system for your composite device. You can do so by using the Include and Needs directives in your information file (.inf).

Include = USB.INF

Needs = Composite.Dev

An information file that incorrectly refers to Usbhub.sys as the composite device driver may, in the future, fail hardware compatibility testing.

For additional information, see the USB composite driver documentation in the Windows XP DDK or Windows Server 2003 DDK.

Enable kernel debug settings per module, as shown in Table 1 and Table 2.

Table 1. Kernel debug settings, Windows 2000

For additional information about USB core stack debugging, see Microsoft Knowledge Base article 314743.

Windows XP SP1 and later operating systems provide a new bugcheck specific to USB. On a severe error, bugcheck 0xFE is generated by the USB stack to aid in quickly identifying the root cause.

Bugcheck 0xFE has four parameters. The first parameter indicates the type of error and determines how you should interpret the remaining three parameters, as shown in Table 3.

Table 3. Parameters for bugcheck 0xFE

An internal error occurred in the USB stack. The Microsoft USB team must obtain the exact repro hardware to investigate the issue.

Parameter 3 is a pointer to the "newest IRP," the IRP that is currently being submitted by the client.
 

Parameter 4 is a pointer to the URB that is attached to both IRPs.

The miniport driver has generated a bugcheck. This error is usually caused by a catastrophic hardware (host controller) failure.

The client driver submitted an IRP that is already pending in the bus driver. This is a common hardware error. This error can also be detected by Driver Verifier when the Cancel routine is set by Usbport.sys for the transfer.

Parameter 2 is the address of the IRP that is being submitted.

Parameter 3 is the address of the URB that is attached to the IRP.

Parameter 4 not used. Its value is always zero.

For additional information about USB core stack debugging, see the latest Windows DDK and the kernel debugger documentation.

Windows XP supports a number of features in the Enhanced Host Controller Interface (EHCI) specification, but there are a few features that are not implemented. These features may be supported in future releases:

64-bit host controller addressing support. EHCI controller can still work in 32-bit mode on an x64 or Intel Itanium platform.
 

Kernel Debugging over USB 2.0.
 

EHCI BIOS handoff.

BIOS vendors should support the EHCI BIOS handoff section in the EHCI Specification for all EHCI-aware BIOS
 

Preliminary support for EHCI BIOS handoff will be available in Windows XP SP2. The Windows core team for USB would like to work with OEM partners and BIOS vendors to develop this functionality.

Here are the major restrictions imposed on hardware devices and drivers by Usbccgp.sys:

There is currently no support for Selective Suspend in Usbccgp. This feature may be supported in future versions of Windows.
 

The interface association descriptor (IAD) in Usbccgp is supported only in Windows XP SP2 and Windows Server 2003 SP1 and later.
 

Nonconsecutive interface numbers are supported only in Windows XP SP2 and Windows Server 2003 SP1 and later.

Yes. The recent USB 2.0 IAD Engineering Change Notification (ECN) introduced a new standard method in the USB device framework for describing a grouping of interfaces and their alternate settings within a function. IAD can now be used to identify two or more consecutive interfaces and alternate settings within one function.

Windows Vista

For additional information on IAD, see Support for USB Interface Association Descriptor in Windows.

No. This functionality is not supported in the USB stack.

No. This functionality is not supported in the USB stack.

What is the Microsoft OS Descriptor?

The Microsoft OS descriptor is a set of data structures that IHVs can use to include extra information in device firmware, information that Microsoft OS descriptor-enabled applications and operating systems can extract. The data is extracted by vendor-specific USB requests to the device as indicated in the OS Descriptor specification. The information retrieved will provide the operating system and/or applications with additional information about the device and its special features.

One or more Microsoft OS feature descriptors

The Microsoft OS string descriptor is a special string that is embedded at a fixed string index. The string descriptor informs the operating system of the presence of one or more Microsoft OS feature descriptors, along with details on how to extract these descriptors.

The Microsoft OS feature descriptors use a fixed format defined by Microsoft.

For additional information about the Microsoft OS descriptors, please visit USB Architecture and Driver Support.

What operating systems support Microsoft OS descriptors?

Windows Vista

Why does Windows XP issue a string descriptor request to index 0xEE?

If a device contains information about itself in a Microsoft OS descriptor, the device must have a Microsoft OS string descriptor located at string index 0xEE. The string descriptor will contain an embedded signature field that differentiates it from other strings, as well as an embedded version number so the descriptor can be distinguished from later updates.

Windows operating systems that support the Microsoft OS descriptor (like Windows XP SP1) issue a string descriptor request to index 0xEE to determine whether the device contains a Microsoft OS descriptor and if so, how to extract and interpret the information contained in the Microsoft OS feature descriptors.

To retrieve the information stored in the string descriptor, a standard GET_DESCRIPTOR request must be issued to the device. The format of the request is shown in Table 4.

Table 4. Standard GET_DESCRIPTOR String Request

If a device does not have a valid string descriptor at index 0xEE, the device will respond with a request error or a stall. For devices that do not respond with a stall, Windows XP will issue a single-ended zero reset to the device to recover the device from an unknown state.

To maintain backwards compatibility, this string request is issued only once to a device that does not contain a Microsoft OS string descriptor.

After the request is sent once to a device, the osvc value of the registry key HLKM\SYSTEM\CurrentControlSet\Control\UsbFlags\VVVVPPPPRRRR is set as shown in Table 5, where:

RRRR is bcdDevice or the revision ID from the device descriptor (in hex format)

Table 5. Possible settings for osvc value

Device did not provide a valid response to the Microsoft OS string descriptor request.

Device provided a valid response to the Microsoft OS string descriptor request, where xx is the bVendorCode contained in the response.

Microsoft Windows operating systems (Windows 98 and later) include native support for devices and systems that comply with the Universal Serial Bus (USB) specification. This article provides answers to frequently asked questions from driver developers about the USB stack and features supported in USB.

This FAQ is for developers who are new to developing USB devices and drivers that work with Windows operating systems.

Unless otherwise specified, the information in this paper pertains to Windows 2000 and later operating systems.

Additional documentation for USB device and driver support is available in the current version of the Windows Driver Development Kit (DDK), through the MSDN developer program library, and on USB - Architecture and Driver Support.

Most desktop and laptop computers sold after 2002 are USB 2.0 enabled. USB 2.0 enabled means that the computer has one or more USB-enhanced host controllers. To determine if your computer running the Windows XP or Windows Server 2003 operating system has a USB-enhanced host controller, follow these steps:

1. Start Device Manager. To do so, click Start, and then click Run. In the Open box, type devmgmt.msc, and then click OK.

Figure 1. Starting Device Manager

2. In the Device Manager window, expand the Universal Serial Bus controllers node. Look for a host controller with the word "Enhanced" in the title. If you find one, your system has USB 2.0 capable ports and has the necessary host controller drivers.

Figure 2: Enhanced host controller with drivers loaded

3. If you do not find an enhanced host controller in step 2, expand the Other Devices section. Look for Universal Serial Bus (USB) Controller. If you find this item, your system has USB 2.0 capable ports, but you need to install drivers for this host controller. If you do not find this item, your system does not have any USB 2.0 ports.

Figure 3: Enhanced host controller without drivers loaded

Windows Server 2003

Windows 2000 and Windows XP were released before USB 2.0 hardware was available, so the drivers were released for those operating systems in the service packs. To install drivers, follow these steps:

1. Follow the procedure described in the answer to the previous question to verify that your computer has USB 2.0 ports that required you to install a driver for the enhanced host controller.

2. In the Device Manager window, expand the Other Devices section as explained under the previous question, and then double-click Universal Serial Bus (USB) Controller.

3. On the General tab of the Properties dialog box, click Reinstall Driver.

Figure 4. Properties window for EHCI with no drivers

4. In the Add New Hardware Wizard, select Install the software automatically (Recommended), and then click Next. Continue with the wizard, accepting all default options, until you reach the last page of the wizard, and then click Finish. You may have to restart your computer to finish the installation.

For additional information about the availability of USB 2.0 in Windows XP SP1, see Microsoft Knowledge Base article 329632.

Note
Visit Windows Update regularly to ensure that you have the latest updates installed on your machine.

Windows XP SP1 and later service packs contain support for USB 1.1 and USB 2.0. SP1a is available at http://www.microsoft.com/windowsxp/pro/downloads/servicepacks/sp1/default.asp

Power management. Fixes issues around Selective Suspend and system power management, especially resume from S3 and S4.
 

CPU utilization. Improves algorithms to reduce CPU utilization during large isochronous and bulk USB transfers.
 

Isochronous support. Improved support for Hi-Speed isochronous cameras and periodic isochronous devices.

You do not need to install Windows XP SP1a if you have installed Windows XP SP2 or Windows Server 2003 SP1. If the service pack was installed by the computer manufacturer, it will not appear in Windows Update.

For additional information on the Windows XP SP1 update for USB 1.1 and 2.0, see Microsoft Knowledge Base article 822603.

Hi-Speed, up to 480 Mbps

Although low speed and full speed existed in the USB 1.1 specification, the USB 2.0 specification added Hi-Speed while maintaining support for low speed and full speed.

There are three specifications for USB host controllers. Most host controllers found in PCs are compliant with one of these specifications; however, each specification is meant to support only a subset of USB 2.0 device speeds, as summarized in Table 1.

Table 1: Host Controllers and Device Speeds Supported

Motherboards that support USB 2.0 must have at least one USB enhanced host controller and usually one or more UHCI or OHCI controllers to support full speed and low speed devices.

IHVs must test their devices on all host controller standards and hubs to ensure compatibility.

Windows XP and Windows Server 2003 create a pop-up notice when a Hi-Speed USB 2.0 device is plugged into a USB port that does not support Hi-Speed. To get the fastest performance from the device, the user must click the notice and follow the instructions on the screen.

Start Device Manager. To do so, click Start, and then click Run. In the Open box, type devmgmt.msc, and then click OK.
 

In the Device Manager window, expand the Universal Serial Bus controllers node. Look for a host controller with the word "Universal" or "Open" in the title. If you find one, double-click it.
 

On the Advanced tab of the Properties dialog box, check the Don't tell me about USB errors checkbox.

Note
Following this procedure will disable all USB notices, not just "HI-SPEED USB Device plugged into non-HI-SPEED port."

The best way to prevent this notice from appearing is by installing a USB 2.0 hub that is Hi-Speed certified or by purchasing a USB 2.0 EHCI peripheral component interconnect (PCI) add-in card. You can then attach your Hi-Speed USB 2.0 device to these Hi-Speed enabled ports. Most systems sold since 2003 already have USB 2.0 Hi-Speed enabled ports.

For additional information about USB 2.0 support in Windows XP SP1, see Microsoft Knowledge Base article 329632.

The bcdUSB field in the standard device descriptor must accurately report the USB specification release number that the device and its descriptors are compliant with.

0x0200 (USB 2.0)

Failure to correctly report these values can cause a device to fail tests in the USB test tools available on http://www.microsoft.com/whdc/whql/device/usb.mspx.

Note
All USB hubs must be compliant with USB 1.1 or later. They should not report 0x0100 in the bcdUSB field.

Yes. The Microsoft Natural Keyboard Pro, which has a three-port, bus-powered hub, is an example of a compound multifunction USB device that has a composite device attached to port 1. Two additional ports are exposed to the end user.

The device attached to port 1 is a low-speed composite device. The device has two interfaces, both of which conform to the USB standard device class definition for human interface devices (HID). The composite device provides two HID interfaces instead of multiplexing all collections over a single HID interface using top-level collections. This design was chosen for compatibility with older BIOSs.

In Windows 2000 and later operating systems, a new physical device object (PDO) is created when a device (for example, a USB or PCMCIA device) is moved from one port to another. A new PDO is not created if the hardware reports a unique USB serial number.

To reuse the same PDO and to ensure that the device experience is unchanged whether the device is reinserted into the same port or a new port, hardware vendors must store a serial number on their device. According to the requirements of the "Designed for Windows" logo program, the serial number must be unique for all devices that share the same device installation identifier.

The USB-IF has worked with Microsoft and other USB-IF member companies to develop a list of recommendations for independent hardware vendors to include on their packaging. More information is available on the USB website at http://www.usb.org/developers/packaging/ .

Right-click the USB driver file you want to know about, and then click Properties.
 

The version number of the file is shown on the Version tab.

The following is a list of core USB drivers on Windows XP:

Usbccgp.sys

For additional information on each driver, see the Windows DDK.

See the USB-IF FAQ page at http://www.usb.org/developers/usbfaq/ .

Which USB DWG Classes are supported by Microsoft?

Windows supports a number of USB classes that are defined by the USB Device Working Group (DWG). For the current list of USB class specifications and class codes, visit the USB DWG Web site at http://www.usb.org/developers/devclass_docs 

Table 2 highlights the USB DWG classes supported in Windows and also identifies the initial version of Windows in which support for the class was introduced.

Table 2: USB DWG Class support in Windows

Windows Server 2003
Windows XP
Windows 2000
Windows Me
Windows 98 SE
Windows 98

Windows Server 2003
Windows XP
Windows 2000
Windows Me
Windows 98 SE
Windows 98

Windows Server 2003
Windows XP
Windows 2000
Windows Me
Windows 98 SE
Windows 98

Windows Server 2003
Windows XP
Windows 2000
Windows Me
Windows 98 SE
Windows 98

Windows Server 2003
Windows XP
Windows 2000
Windows Me
Windows 98 SE

*Special instructions are necessary to load this driver because it may have been released later than the operating system.

Not all features described in a DWG class specification may be supported by Windows class drivers. For additional details on implemented features within a class specification, see the documentation for the Windows DDK.

What device setup class should I use for a custom USB device?

Microsoft provides system-defined setup classes for most device types. System-defined setup class GUIDs are defined in Devguid.h. For additional information, see the DDK. If you are developing a device type for which Microsoft has not provided an existing class GUID, then you can define a new device setup class.

The USB team requires IHVs to use the setup class associated with the type of USB device, not with the bus type. The setup class "USB" (ClassGuid = {36fc9e60-c465-11cf-8056-444553540000}) is reserved only for USB host controllers and USB hubs. It must not be used for other device categories. Using this class incorrectly may cause the device driver to fail hardware compatibility testing.

For a list of Windows class GUIDs, see "System-Supplied Device Setup Classes" in the Windows DDK or online at http://msdn2.microsoft.com/en-us/library/ms791134.aspx.

Why won't my CPU enter C3 if I attach some USB devices?

When a USB device is attached to a PC, the USB host controller polls the frame scheduler in memory. This is a direct memory access (DMA) bus master operation. Any bus master traffic, interrupt, or one of several other system activities are "break events" that will move a CPU out of C3 because, by definition, the CPU's cache cannot be snooped while in C3.

Hardware removal. In some cases it may be possible for the hardware to be electronically disconnected from the universal serial bus. For example, when storage media is removed from the USB reader, the USB reader can emulate an electronic disconnect and reconnect when the media is reinserted. In this case, the universal serial bus will not prevent C3 transitions, because there are no USB devices on the host controller.
 

Selective Suspend. The only alternative available in Windows XP and later operating systems is to support USB Selective Suspend. This feature allows a driver to suspend the USB device it controls when the device becomes idle, even while the system itself remains in a fully operational power state (S0).

Selective Suspend is particularly powerful if all USB function drivers support it. If even one driver does not support it, the CPU will be kept out of C3.

For additional information on Selective Suspend, see the Driver Development Kit.

Which USB class drivers support Selective Suspend in Windows XP and Windows Server 2003?

Usbhub.sys. This driver can selectively suspend a root or external hub when no devices are attached to it or when all devices attached to that hub can be selectively suspended.
 

Hidusb.sys. This driver can selectively suspend a HID device. It is your responsibility to trigger remote wake signaling on all device state changes. To enable Selective Suspend in the HID stack, the registry value SelectiveSuspendEnabled must be enabled for the specific VID+PID of the device. For examples, see Input.inf.
 

Bthusb.sys. This driver can selectively suspend devices on computers running Windows XP SP2 and later. The driver requires the Bluetooth radio to set the self-powered and remote wake bits in the configuration descriptor. The driver selectively suspends the Bluetooth radio when there are no active Bluetooth connections.
 

Usbser.sys. This driver can selectively suspend when there are no active modem connections.

If enough OEMs ask for it, Microsoft may consider supporting Selective Suspend for additional class drivers. Work is also being investigated on future hardware architectures (CPUs, chipsets, and the operating system) to mitigate the problems.

Why can't Windows XP be awakened from S3 by using a USB HID (keyboard/mouse) when it can be awakened from S1?

There are a number of reasons that a PC cannot be awakened by a USB device from S3. Some of them are listed below:

Incorrect BIOS. Verify that you have the latest BIOS installed on the computer. To get the latest BIOS revision for your computer, visit the website of the OEM or ODM.
 

BIOS not enabled to wake. Some BIOSs make it possible to disable wake from S3 and S4. Verify that the BIOS is enabled to wake from S3.
 

USBBIOSx registry not set. A clean install of Windows XP will not have the USBBIOSx registry key. If the OEM or ODM has validated that the BIOS is capable of waking from S3, you need to set this registry key to 0x00 and restart the computer.

For additional information, see the USB troubleshooter in the Windows XP Help and Support Center.