USB -Serial Controller D Driver driver Comments: 4.93 out of 5 based on 156 ratings.4 user comments. Uninterested Jeremiahix 07:20:21 can't complete anything with the help of the windows manager! Such a full-blown waste of your time this windows manager.
Microsoft-provided in-box driver (Usbser.sys) for your Communications and CDC Control device.
In Windows 10, the driver has been rewritten by using the Kernel-Mode Driver Framework that improves the overall stability of the driver.
In addition, UWP applications can now use the APIs provided by the new Windows.Devices.SerialCommunication namespace that allow apps to talk to these devices.
Load the Microsoft-provided in-box driver (Usbser.sys) for your Communications and CDC Control device.
If you trying to install a USB device class driver included in Windows, you do not need to download the driver. They are installed automatically. If they are not installed automatically, contact the device manufacturer. For the list of USB device class driver included in Windows, see USB device class drivers included in Windows.
In Windows 10, a new INF, Usbser.inf, has been added to %Systemroot%Inf that loads Usbser.sys as the function device object (FDO) in the device stack. If your device belongs to the Communications and CDC Control device class, Usbser.sys is loaded automatically.You do not need to write your own INF to reference the driver. The driver is loaded based on a compatible ID match similar to other USB device class drivers included in Windows.
Microsoft encourages you to use in-box drivers whenever possible. On mobile editions of Windows, such as Windows 10 Mobile, only drivers that are part of the operating system are loaded. Unlike desktop editions, it is not possible to load a driver through an external driver package. With the new in-box INF, Usbser.sys is automatically loaded if a USB-to-serial device is detected on the mobile device.
In Windows 8.1 and earlier versions of the operating system, Usbser.sys is not automatically loaded when a USB-to-serial device is attached to a computer. To load the driver, you need to write an INF that references the modem INF (mdmcpq.inf) by using the Include directive. The directive is required for instantiating the service, copying inbox binaries, and registering a device interface GUID that applications require to find the device and talk to it. That INF specifies 'Usbser' as a lower filter driver in a device stack.
The INF also needs to specify the device setup class as Modem to use mdmcpq.inf. Under the [Version] section of the INF, specify the Modem and the device class GUID. for details, see System-Supplied Device Setup Classes.
For more information, see this KB article.
Starting in Windows 10, Usbser.sys supports USB Selective Suspend. It allows the attached USB-to-serial device to enter a low power state when not in use, while the system remains in the S0 state. When communication with the device resumes, the device can leave the Suspend state and resume Working state. The feature is disabled by default and can be enabled and configured by setting the IdleUsbSelectiveSuspendPolicy entry under this registry key:
To configure power management features of Usbser.sys, you can set IdleUsbSelectiveSuspendPolicy to:
'0x00000001': Enters selective suspend when idle, that is, when there are no active data transfers to or from the device.
'0x00000000': Enters selective suspend only when there are no open handles to the device.
That entry can be added in one of two ways:
Write an INF that references the install INF and add the registry entry in the HW.AddReg section.
Describe the registry entry in an extended properties OS feature descriptor. Add a custom property section that sets the bPropertyName field to a Unicode string, 'IdleUsbSelectiveSuspendPolicy' and wPropertyNameLength to 62 bytes. Set the bPropertyData field to '0x00000001' or '0x00000000'. The property values are stored as little-endian 32-bit integers.
For more information, see Microsoft OS Descriptors.
If you install Usbser.sys for the USB CDC device, here are the application programming model options:
Starting in Windows 10, a Windows app can send requests to Usbser.sys by using the Windows.Devices.SerialCommunication namespace. It defines Windows Runtime classes that can use to communicate with a USB CDC device through a serial port or some abstraction of a serial port. The classes provide functionality to discover such serial device, read and write data, and control serial-specific properties for flow control, such as setting baud rate, signal states.
In Windows 8.1 and earlier versions, you can write a Windows desktop application that opens a virtual COM port and communicates with the device. For more information, see:
Win32 programming model:
.NET framework programming model:
The Microsoft USB Test Tool (MUTT) is collection of devices for testing interoperability of your USB hardware with the Microsoft USB driver stack. This section provides a brief overview of the different types of MUTT devices, the tests you can run by using the device, and suggests topologies for controller, hub, device, and BIOS/UEFI testing.
To communicate with MUTT devices, you need the MUTT software package. This package contains several test tools and drivers that let hardware test engineers test interoperability of their USB controller or hub with the Microsoft USB driver stack. The test tools validate USB host controller software, hardware (including firmware) and any USB hub that is installed between the host controller and the device.
USB Type-C ConnExMCCI
Based on the design of the CY3681 EZ-USB FX2 Development Kit (Cypress FX2).
Compatible with FX2 capabilities, such as high speed and full speed transfers to bulk, isochronous, control, interrupt endpoints.
Simulates traffic from USB 2.0 devices.
The MUTT Pack is a combination of a USB 2.0 hub and an FX2 device that controls the hub and acts as a downstream device.
Based on the design on the Cypress Hub and Cypress FX2.
Hub capabilities. This can operate as a multi-TT or single-TT high speed hub; simulates overcurrent.
Exposes a downstream port that can be turned on or off.
Simulates USB 2.0 hub behavior.
Can operate in self-powered or bus-powered modes.
The MUTT Pack has two USB connectors. The standard B connector is used to plug the MUTT Pack in to the host system. The standard A connector is downstream of the embedded hub on the MUTT Pack, and can be used for additional device testing (discussed later in this document).
The MUTT Pack uses a small jumper (see Figure 3) to switch between self-powered and bus-powered modes. In bus-powered mode, the USB bus of the host system powers the MUTT Pack. In self-powered mode, the MUTT Pack is powered with an external 5V power adapter.
Use the following flow chart to determine how to power the MUTT Pack:
Do not use the MUTT Pack without the power jumper.
This image shows how to use the jumper for powering the MUTT Pack by the USB bus of the host system:
This image shows how to use the jumper for powering the MUTT pack with an external power adapter:
Note Disconnect any existing power adapters and the cable to the host system when you are changing the jumper on the MUTT Pack.
Based on the design of FX3 EZ-USB FX3.
Implements SuperSpeed features such as the bulk streams feature.
Simulates USB 3.0 device traffic.
Note: this device does not support operation at Low Speed.
The SuperMUTT Pack is two devices in one. It is a USB 3.0 hub with a Cypress FX2 device downstream. The device controls the hub and also acts as a downstream device. The SuperMUTT Pack simulates USB 3.0 hub behaviors.
Note The downstream device is a 2.0 device, not a USB 3.0 device.
The DR MUTT acts like a SuperMutt when testing host mode of the device under test, but it can also switch to host mode to test the function mode of the device under test.
The USB Type-C Connection Exerciser (USB Type-C ConnEx) is a custom shield that has a four-to-one switch to automate USB Type-C interoperability scenarios. The shield has been designed to work with Arduino as the microcontroller. For more information, see Test USB Type-C systems with USB Type-C ConnEx.