USB Host Controller Driver Registry Settings

Other versions of this page are also available for the following:

• Windows Embedded CE 6.0 R3

8/28/2008

This topic contains information on the following registry settings:

• HCD module
• USB host controller driver

Registry keys control how USB device drivers are loaded. When a USB device is attached, the USB driver module loads the appropriate USB device driver to control that device, based on the device's configuration and interface descriptor information. The USB driver module locates the correct driver by using a set of registry keys, which track both the drivers and the devices. The registry keys are stored as subkeys of the HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients key.

This loading method provides a flexible framework that allows drivers to be loaded in different contexts, depending on the range of devices that they are able to control. For example, you might decide to include a generic class driver that can control a broad range of USB devices. However, you might have a driver for a specific USB device within that class that is more efficient or works better than the generic class driver. In this case, your driver could control a subset of the devices that the generic class driver controls, while allowing other devices to continue to be controlled by the generic driver. The structure of the LoadClients key defines a framework in which programmers can specify driver precedence in great detail.

The following table shows examples of the contexts that can cause specific USB device drivers to load.

Context	Example
To match every device that is connected to the bus.	A driver that displays an icon in the system's taskbar is loaded to control each USB device that is connected to the system. The driver purposely fails the USBDeviceAttach call after obtaining the device information, and the USB driver module continues looking for a driver to control the device. Note: Only one driver of this type can be registered in the system.
To match a vendor-specific identifier.	A vendor-specific identifier matches USB devices that do not fall into any currently defined class or provides an enhanced driver for a particular USB device. Note: Microsoft does not recommend that you do this for general-purpose drivers that might be able to control devices from multiple developers.
To control devices of a specific device class.	You write a USB device driver to control all HID class devices. Note: The USB Implementers Forum has defined other device classes, including communications, audio, and mass storage.
To control each interface on a device.	A USB CD-ROM drive with an audio interface has separate drivers for each interface, which is common with CD-ROM drives that can play audio CD-ROMs. Note: This context is the best for loading USB device drivers because it allows compound devices that require multiple drivers to operate without additional reconfiguration.

The registry key for a USB device driver should either be part of your Platform.reg file or be created when a USB device driver is installed. At installation time, the key can be created either by a setup application or by the driver's USBInstallDriver function. USBInstallDriver should create the keys indirectly, by calling the LPREGISTER_CLIENT_SETTINGS function, rather than by invoking the registry APIs. Installation by USBInstallDriver occurs when an unrecognized USB device is connected to the bus and the USB driver module queries a user for the name of the device driver DLL. The USB driver module then loads the driver and calls its USBInstallDriver function.

Subkeys for each driver have the form Group1_ID\Group2_ID\Group3_ID\DriverName. Each of the group identifier subkeys can be named Default to indicate that the USB device driver should be loaded if the remaining group identifier subkey names match the USB device. Otherwise, the group identifier subkey names are formed from combinations of vendor, device class, and protocol information, separated by underscores. This information comes from the USB device descriptor. The following table shows the allowable combinations.

Group key	Allowable forms
Group1_ID	DeviceVendorID, DeviceVendorID_DeviceProductID, DeviceVendorID_DeviceProductID_DeviceReleaseNumber
Group2_ID	DeviceClassCode, DeviceClassCode_DeviceSubclassCode, DeviceClassCode_DeviceSubclassCode_DeviceProtocolCode
Group3_ID	InterfaceClassCode, InterfaceClassCode_InterfaceSubclassCode, InterfaceClassCode_InterfaceSubclassCode_InterfaceProtocolCode

HCD Module Registry Settings

If your hardware platform contains UHCI–compliant host controllers, you will have a migrating task similar to a hardware platform with OHCI-complaint host controllers. OEMs need to include the following registry values under the HKEY_LOCAL_MACHINE\Drivers\Builtin\UHCI registry key so that the UHC driver will be loaded when the system boots.

[HKEY_LOCAL_MACHINE\Drivers\Builtin\UHCI]
    "Prefix"="HCD"
    "Dll"="uhci.dll"
    "Index"=dword:1
    "Order"=dword:1
    "UseExistingSettings"=dword:0
    "Irq"=dword:<hardware platform dependent>
    "MemBase"=dword:<hardware platform dependent>
    "Priority"=dword:<hardware platform dependent>

The UseExistingSettings key controls whether the values for Irq, MemBase, and Priority come from the system's BIOS settings or whether they come from the registry. A value of 0 causes the BIOS setting to be used. Any other value causes the BIOS settings to be ignored in favor of the values specified in the Irq, MemBase, and Priority keys.

When the UHC driver is loaded at boot time, it attempts to detect the presence of a UHCI-compliant USB host controller. The sample UHC driver is only capable of detecting the Intel PIIX4 controller because of PCI bus values that are hard-coded into the UHC driver. However, the detection function is available as source code. You can change the function to detect other UHCI-compliant USB host controllers.

The following table lists the values that the sample UHC driver uses to identify the Intel PIIX4 controller.

PCI field	Value	Description
BaseClass	0x0C	Serial Bus Controller
SubClass	0x03h	USB subclass
VendorID	0x8086	Intel Vendor ID
DeviceID	0x7112	PIIX4 Device ID

The sample HCD included with Windows CE 3.0 only supports one UHCI chip on a system. The UseExistingSettings key has no effect on Windows CE 2.11 for the CEPC, for which the HCD module supplied by Microsoft has a pre-defined address hard coded into it for the host controller. In Windows CE 2.12 and later, the HCD module obtains the host controller interface settings dynamically according to the UseExistingSettings key as described above. The default value of the UseExistingSettings key can also be controlled on your development workstation through the environment variable CEPC_USB_USE_EXISTING. If you set this variable to a new value, you do not have to rebuild the HCD module. You only have to run the Makeimg utility to cause the new value to be incorporated into your operating system image.

Fundamentally, Windows Embedded CE cannot reconfigure PCI devices dynamically. Thefore, if UseExistingSettings is set to 0, the USB host controller interface settings must match those in the hardware platform's registry or the HCD module will not load. If the two do not match, you can check the hardware platform's resource settings, and then update your Platform.reg file with the correct addresses and IRQ information. Alternately, you can watch the debug output while your hardware platform boots, which should report an error that contains these resource settings.

The following code example shows debug output.

!OHCD: Configuration different from registry: IRQ %u, PortBase: 0x%X (reg: %u, 0x%X)

USB Host Controller Registry Settings

The following registry keys show USB host controller registry keys.

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\OHCI]
    "Prefix"="HCD"
    "Dll"="ohci.dll"
    "Index"=dword:1
    "Order"=dword:1
    "Irq"=dword:0F 
    "MemBase"=dword:FFBFE000
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\UHCI]
    "Prefix"="HCD"
    "Dll"="uhci.dll"
    "Index"=dword:1
    "Order"=dword:1
    "Irq"=dword:0A
    "MemBase"=dword:D801

See Also

Concepts

USB Host Client Drivers
USB Host Controller Driver Architecture