FAQ – USB Drivers and Devices

 

Why do I need a USB Vendor ID and USB Product ID?

Every shipping USB product is uniquely identified by a tuple of two 16-bit integer numbers: vendor ID (VID) and product ID (PID). Each number ranges from zero to 65536 (0x0000 to 0xFFFF). A USB device reports these numbers through its device descriptor in the fields idVendor and idProduct.

Operating systems (Windows, macOS, Linux) use the VID/PID tuple to locate the matching device driver, and to store device-specific configuration information (e.g. last volume set). Software applications such as configuration tools, firmware upgrade utilities, etc. typically rely on the VID/PID tuple to identify the device they have been designed for.

If two different products share the same VID/PID tuple then an operating system will potentially load the wrong device driver, and another product's applications and utilities will possibly try to communicate with the device, perform a firmware update etc. This leads to bad user experience and, in a worst-case scenario, can damage the device.

Hence it is mandatory to ensure that a unique VID/PID tuple is assigned to every distinct USB device type (model) that is shipping. Details on how VID and PID assignment is done in practice are given in the following sections.

Vendor ID (VID)

The Vendor ID is globally unique and typically identifies the manufacturer or distributor of the device. To ensure uniqueness globally, VIDs are managed and assigned by the USB Implementers Forum organization (http://www.usb.org). To receive a VID, you have to contact the USB Implementers Forum, see http://www.usb.org/developers/vendor/.

Any shipping product must use the official VID assigned by the USB Implementers Forum to the product's manufacturer.

In some cases it is possible to use the VID of a silicon vendor. However, this requires registration with the silicon manufacturer or distributor to receive a unique PID. Never re-use the VID/PID of an evaluation board or reference design!

Thesycon allows licensees to use the VID registered for Thesycon. This requires registration with Thesycon because Thesycon manages the PID range and needs to assign a unique PID.

Product ID (PID)

The owner of a VID manages the corresponding PID range. PIDs can be assigned arbitrarily but need to be chosen in such a way that every shipping USB product uses a unique VID/PID tuple. Make sure you choose a unique PID for each new device model and carefully keep records on PID assignments.

Why do I have to customize a device driver provided by Thesycon?

Thesycon provides generic device drivers which cannot be used directly. Before the driver can be used with a specific USB device and shipped as part of a product, it needs to be customized. The customization procedure includes:

Note that the customization procedure does not modify the driver binary executable files (.sys, .dll) itself. The executable files are created and shipped by Thesycon and will not be modified afterwards.

Customization is a mandatory step. Any shipping driver package must be a fully customized driver package. Otherwise, there is a risk that name clashes, ambiguities or other conflicts occur when the driver is used in the field. This is because Thesycon’s drivers are shipped with many different products and there is a chance that an end user installs two (or more) of such products on the same Windows system. If every product uses a fully customized driver then multiple products can be installed and used in parallel without causing conflicts.

Why does Windows 7 not accept my signed driver?

In Windows 7 there are some issues with SHA-256 code signing certificates as described in the following subsections.

Windows 7 requires hotfix to accept SHA-256 code signature

Operating systems: Windows 7 32/64 bit

Problem description: By default, Windows 7 does not accept SHA-256 code signatures, it accepts SHA-1 signatures only. However, SHA-1 based certificates are deprecated and not available any longer. All recent code singing certificates use the SHA-256 algorithm.

Microsoft has released a hotfix that adds support for SHA-256 certificates on Windows 7. The hotfix KB3033929 can be found here: https://support.microsoft.com/en-us/kb/3033929

Note that KB3033929 is available through Windows update. So the easiest solution is to make sure this update is installed.

Additional information:This problem does not exist on Windows 8 and later. If the Thesycon driver installer (v1.12 and later) is used then setup.exe detects this problem during driver installation and shows an error message which references the KB3033929 patch.

Untrusted Publisher pop-up dialog appears on Windows 7

Operating systems: Windows 7 32/64 bit

Problem description: Normally, Thesycon’s driver installer suppresses the "Untrusted publisher" dialog box. However, if the driver that is installed is signed with a SHA-256 code signing certificate then Windows 7 may still show this dialog box. Although you selected the "Always trust" option, the dialog box may reappear during a subsequent driver installation.

This is an issue in Windows 7. For more information and a hotfix, check out KB2921916: https://support.microsoft.com/en-us/kb/2921916

Additional information: KB2921916 is not available through Windows update.

Can Thesycon’s USB network driver be used as a replacement for Microsoft's RNDIS driver?

RNDIS (Remote NDIS) is a proprietary protocol based on Microsoft's internal network driver interface used in the Windows kernel. Thesycon’s network driver does not support RNDIS. The driver supports the network emulation protocols defined by the USB Implementers Forum as part of the USB Communications Device Class (CDC) specification. Specifically, the driver implements CDC/ECM (Ethernet Control Model), CDC/NCM (Network Control Model), and CDC/EEM (Ethernet Emulation Model).

 

If you experience problems with the Windows in-box RNDIS driver, Thesycon recommends to switch to one of the CDC protocols. If the device implementation is Linux based, this should be easy because Linux includes CDC/ECM and CDC/NCM modules as part of the Gadget USB device stack. If no specific requirements on data throughput exist, Thesycon recommends using CDC/ECM because it is the simplest protocol. In specific scenarios (e.g. exchange of small packets at a high packet rate) better data throughput can be achieved with CDC/NCM.

 

Note that Windows does not include an in-box class driver for CDC/ECM or CDC/NCM. Request a free evaluation copy of the network driver if you want to try your device in CDC/ECM or CDC/NCM mode.

 

Other operating systems such as Linux and macOS include CDC/ECM and CDC/NCM class drivers.

 

 

© 2018 THESYCON

Device Driver - Software development - Consulting home