By Koichi Hirao [MSFT]

We are pleased to announce the immediate availability of a standalone legacy 1394 OHCI (FireWire) package for Windows 8/8.1.

Starting with Windows 7, we’ve been providing native support for a 1394 driver stack that is based on the Windows Driver Framework (WDF).  And this driver stack supports the legacy 1394 (aka 1394a) and 1394b interfaces.

With the introduction of this new standalone WDF-based 1394 driver, we decided to remove native support for the legacy 1394 stack from Windows 8. 

We’ve been monitoring Answers Forum very closely. The feedback from our customers, shows that some 1394 peripherals are not working as effectively on 1394b systems, and this has led to the desire to publish the standalone legacy 1394 driver.

You sent us feedback and we listened.

 Package information:

• The driver is available for both x86/x64 platforms. 
• Please follow the manual installation steps in the KB 2970191
• The driver is only intended to work with legacy 1394 host controllers so you will experience lower transfer data rates, compared with 1394b.
• The driver is intended for customers who experience compatibility issues with 1394 peripherals on 1394b systems. If you are not experiencing any issues, you should continue to use inbox drivers provided in Windows 8.
• Customers who upgrade to a newer OS version in the future will be required to reinstall this standalone driver package.

Please help us by responding to this blog post, to let us know whether or not our suggestions worked for your setup.

Authored by Fred Bhesania [MSFT]

Hi everyone!

The USB team is excited to share new features for Windows 10 on our USB Blog site! It’s been a bit silent here while we have been busy working on Windows 10. However you should rest assured that this blog is not forgotten and we will start a series of pertinent posts this spring.

At WinHEC 2015, followed by Build 2015, Microsoft was proud to announce details around the hardware innovations enabled by Windows 10. We have been working on features that enhance the USB experience for enterprises and consumers alike. Some of the key benefits of Windows 10 are described below:

In this blog post, we summarize innovations that Windows 10 brings to the USB ecosystem.

USB Dual-Role support

USB defines an asymmetric protocol (Host – Function) and has traditionally allowed only one mode: PCs in Host mode and other devices like phones in Function mode. Windows 10 enables USB Dual Role. This new role enables a phone to either operate in Host mode (enabling scenarios like accessing a flash drive) or operate in Function mode (when connected to a PC). With universal API support for USB, app developers can access USB peripherals directly from their app for use as a point of service, data backup, or even controlling a device like an Arduino.

For details, see USB Dual Role Driver Stack Architecture.

USB Type-C support

Windows 10 introduces native support for USB Type-C. Defined in the USB 3.1 specification, the feature empowers devices to leverage (1) a reversible connector, (2) a symmetric cable, (3) faster charging, and (4) Alternate Modes running over the USB cable. This will make it easier for end users to connect devices using USB, use USB chargers to charge their laptops and desktop PCs, and also allow them to project video over the USB connector leveraging Alternate Modes like DisplayPort. We anticipate 2015 to be a pivotal year for USB Type-C and look forward to seeing systems from many partners that will have this capability. We are confident that USB Type-C will greatly simplify user experiences around USB connectivity and also open up new symmetric possibilities in the future.

USB 3.1 SuperSpeedPlus support

USB 3.1 was officially announced in the summer of 2014. Since then a number of hardware manufacturers have announced and demonstrated support for USB 3.1 functionality, with the specific focus on SuperSpeedPlus (10Gbps). The efficient data encoding and the 10Gbps data rate delivers more than twice the effective data throughput performance of existing SuperSpeed USB while maintaining backwards compatibility with existing USB 3.0 and even USB 2.0 devices. Windows 10 has enhanced the USB 2.0 and the USB 3.0 drivers to support USB 3.1 devices that operate at SuperSpeedPlus speeds.

Support for new class drivers and vendor-specific class drivers

Windows provides in-box class drivers for most USB device classes. Microsoft partners with various USB Device Working Groups (DWG) to develop industry standard specifications and then support them by supplying drivers with the operating system. Windows 10 has new drivers for these USB device classes.

· USB CDC (Serial) – Allows devices that are compliant with the USB communication devices Class (Class_02 & SubClass_02) to work with Windows 10 by using the Usbser.sys driver.

· Billboard – Allows USB Type-C device to report error notification information (through the USB Billboard Device Class), if they are using an Alternate Mode that is not supported on the device.

From this blog post, you can see that Windows 10 provides rich support for new industry standards around USB. For the complete list of USB device classes supported in Windows 10, see USB device class drivers included in Windows.

In addition to industry standards, there are some additional USB innovations that may be interested to developers.

· Supporting USB on new platforms that are the building blocks for IOT scenarios

· Enabling IHVs to create a driver that matches on a vendor-specific compatible IDs.

· Allowing developers to write their host controller drivers by using the new programming interfaces exposed by the USB Class Extension (UCX).

Advances in USB Test Tools

Windows 10 offers a unique set of tools for the ecosystem. Over the last 6 years, Windows has delivered a number of innovative hardware test tools ranging from the Microsoft USB Test Tool (MUTT) to the new Dual-Role version (DR MUTT).

Windows has historically provided tests through the Hardware Certification program. For Windows 10, the Hardware Lab Kit (HLK), offers tests to help diagnose issues early in the development process, ensure driver compatibility with Windows, and optionally certify devices or systems. We have added new tests in the HLK that validate Dual Role and Function mode on any Windows 10 SKU.

This post provided a brief overview of the new features. Keep an eye out for follow-up posts about additional details on some of those features.

We hope that you enjoy the USB enhancements included in Windows 10. Join the Windows Insider Program and get the Windows 10 Technical Preview!

Related posts and links:

· Blogging Windows: http://blogs.windows.com/bloggingwindows/

· Windows 10 Tech Preview: http://blogs.windows.com/bloggingwindows/2015/02/12/announcing-the-first-build-of-windows-10-technical-preview-for-phones-2/

· Windows 10 Insider program for Developers: http://insider.windows.com

· USB Device Working Groups: http://www.usb.org/developers/docs/devclass_docs/

Authored by Andrea Keating [MSFT]

Have you ever wanted to watch the video that was sitting on your flash drive when all you have is your phone? What about editing a Microsoft Word document from your phone with the comforts of a “real” keyboard and mouse? Are you a developer who wants to make USB accessories that work with both Windows Mobile and Desktop devices? Well, in Windows 10 now you can…

In Windows 10, Microsoft is introducing support for USB Dual Role. USB Dual Role refers to the ability of a system to behave as a USB Device or a USB Host. This is a really exciting feature as it adds the ability to use your USB devices with your Mobile phone for the first time ever in Windows!

Please note, this feature will only be available on new Windows 10 devices that support USB Dual Role. This is because of the hardware changes required for the USB port to support device enumeration. While there are devices in the market today that have USB Dual Role capable controllers, the platforms were not designed to support USB Dual Role. New hardware may advertise that they are Dual Role capable.

To support these new devices on the Windows 10 Mobile OS, we are including the following class drivers. These class drivers have been selected for inclusion in Windows 10 for Mobile due to (a) their popularity and (b) key Windows 10 scenarios we are enabling.

The Windows team will continue to monitor the top devices that are plugged into a Windows 10 Mobile system. With this data in hand, we will be in a position to know which additional drivers should be considered for inclusion in future release of Windows. Leveraging WinUSB and our WinRT APIs, a developer can create a custom device that works with a custom app on the Windows Mobile OS.

For more details:

· The Enabling New USB Connectivity Scenarios WinHEC presentation here: http://channel9.msdn.com/Events/WinHEC/2015/WHT200

· The Building New Apps for USB Accessories //BUILD presentation here: http://channel9.msdn.com/events/Build/2015/3-81

· Developer documentation is also available on MSDN here: https://msdn.microsoft.com/en-us/library/windows/hardware/dn957036(v=vs.85).aspx

The purpose of this blog post is to provide a resource with solutions to common problems encountered in the USB tests within the Windows 10 Hardware Lab Kit (HLK). This blog will be categorized into the following areas: “Recent/Upcoming Fixes”, “Known Issues” and “Common Questions.”

As you run these tests, please continue to provide feedback! This blog post will be updated as necessary with new guidance as it arises and old items will be phased out as test updates become widely available.

Common Questions

USB Internal Device Idle Test

Why is the USB Internal Device Idle Test failing? The system does not have internal devices or they are all suspended and the test still does not pass?

Please ensure that all external USB devices are unplugged from the system under test before scheduling the test. Failure to remove all external USB devices often results in a test failure indicating that a device or multiple devices failed to suspend. All internal devices should support suspend and go to suspend during a period of inactivity.

USB-IF Certification Validation Test (Device)

I ran the USB-IF compliance tests myself, do I need to submit the logs via the HLK?

This test records the status of USB-IF certification for the device under test. There are two ways to assert USB-IF certification. The first option is to get full certification from the USB-IF and submit the test ID (TID) supplied by the USB-IF. The second option is to download the USB-IF Compliance tools online (see test documentation for more details) and run them yourself on the device under test. If you have run and passed the required USB-IF tests yourself, then you will simply submit the following Test ID (TID) when scheduling the test in the HLK: SELF_TEST. Using this Test ID is an assertion that the device under test has completed and passed all required USB-IF testing.

Recent/Upcoming Fixes

USB Exposed Port Test

Had a bug handling non-contiguous xHCI root port numbers. Manifested as a crash in the TAEF framework. Fixed in 10120.

USB3 Termination Test

1) Had a bug handling non-contiguous xHCI root port numbers. Manifested as an error stating that there was an “invalid string” encountered. Fixed in 10120.

2) Unable to pass on systems without a user-connectable SuperSpeed capable USB port. The fix will be available in an upcoming release of the kit.

3) The USB3 Termination Test requires a SuperSpeed device to be attached downstream from a SuperSpeed xHCI port.  However a bug in the test precludes most SuperSpeed storage devices from being recognized.  For now, please use a SuperMUTT device, or other SuperSpeed device without a USB serial number, to run the test.  The fix will be available in an upcoming release of the kit.

USB Generic HID Test

This test requires a SuperMUTT. The version 43 firmware that shipped in an early release of the HLK caused this test to fail. Current version 44 of the firmware shipping in the latest EEAP release resolves the issue. Update to the latest HLK and from the system project, run the MUTT Firmware Update for Systems job with the SuperMUTT connected to the system, and the new firmware will be applied. Fixed in 10108.

To determine the firmware version on the SuperMUTT device, first attach the device to a Windows PC.  Open the Device Manager and locate the “SuperMUTT” under the “Universal Serial Bus devices” group.  Double click the SuperMUTT to open the Properties window and open the Details tab.  Select the “Hardware Ids” property.  You will see a hardware Id string like the following: USB\VID_045E&PID_078F&REV_0044.  The last number is the firmware version number, in this example it is version 44.  If your device ID shows REV_0043, you need to follow the procedure above to update to version 44.

Known Issues

USB (USBDEX) Verifier Test

Problem

A kit infrastructure issue is causing this test to fail to load the correct logging module in recent release of the kit which cases the “Disable Flags” setup task to fail.  Expanding the error simply shows it failing with exit code 1.

Solution

The work-around for running this test until the kit infrastructure issue is resolved is to manually register the appropriate logging module:

- On the client PC, open an administrator command prompt

- Navigate to the following folder: <SystemDrive>:\Program Files\Windows Kits\10\Hardware Lab Kit\Client\

- Run: “regsvr32 /s wttlogcm.dll”

- Re-schedule the test through the HLK Studio

USB Serial Number Test

Problem

There is a known limitation in this test such that if the device under test provides a serial number, both instances must be in D0 for the test to correctly read the serial number strings. The failure pattern is an error statement saying that the serial number string was not NULL terminated, which is incorrect, the test actually wasn’t able to retrieve it at all.

Solution

Ensure that the device is in D0 when the test runs. The test run only takes a few seconds so this can be as simple as re-attaching in the devices immediately before scheduling the test so it executes before the suspend timeout occurs, or using the device during the test (move/click input device, access network, read/write files, etc.)

USB Device Connection S3 + S4 + Connected Standby

And USB Hardware Verifier Test

Problem

These tests may fail on some systems with incomplete xHCI port mapping reported by the system. This is a problem with the HLK client PC firmware, not with the device under test. The failure pattern is an error statement saying that “IOCTL_USB_GET_PORT_CONNECTOR_PROPERTIES returned invalid port number.”

Solution

Fortunately on common platforms we have seen with this issue, the problematic port mapping is only for a few of the ports, and other ports are properly mapped and able to fully support device level testing. To find a usable port, run USBView, and be sure the device under test is connected to a port with a non-zero “Companion Port Number”. Unfortunately some tests are dependent on the Device Instance ID so you cannot simply change ports during the middle of a test project, if for example the device does not support a unique serial number. If you find that the host platform has this port mapping problem, you may need to re-create the project with the device under test connected to one of the good ports.

USB xHCI Transfer Speed Test

And USB3 Termination Test

Problem

These are system level tests that fail for the same reason as USB Device Connection and USB Hardware Verifier tests: incomplete xHCI port mappings reported by the system. Since these are system tests, this is indeed a problem with the system under test that needs to be corrected. However the USB Exposed Port Test is specifically checking the port mappings and it is still valuable to validate the transfer speed and SuperSpeed terminations on these platforms. The failure pattern will manifest as an error stating that an “invalid” device or port was detected.

Solution

Attach the SuperSpeed device, for example a SuperMUTT, to a port on the system that is properly mapped. You can confirm in USBView if there is such a port on the system by checking the SuperSpeed port nodes for one where the “Companion Port Number” is non-zero.

USB3 Termination Test

Problem

The test may fail with the following error indicating that no USB 2.0 companion ports were found in the ETW rundown:

Solution

Errata number 5597 has been provided to filter out this error.  Please apply the latest errata to your submission if you see this error in the test log for the USB3 Termination Test.

Authored by George Roussos [MSFT]

The Serial Communication protocol is everywhere; it is broadly available, easy to learn, and low cost.   It is used across many different transports: typically over USB, in cases over Bluetooth and even over TCP/IP.   Many people are familiar with COM ports and programs that read data from and/or write data to them.  Today we find Serial Communications in both 30 year old hardware like natural gas meters and new products like many 3D Printers or those in the prototyping stage based upon Arduino boards.  

We listened to customer feedback on Serial while planning Windows 10 and acted upon two high level points:

1. Improve Serial over USB driver support from Windows.
2. Provide a Windows Runtime API for communication with Serial devices.

This blog entry focuses on enhancements for USB connected Serial devices in Windows 10, and how customers can provide additional feedback on them which we can efficiently act upon.

1.   Improved Serial over USB driver support in Windows 10

Earlier versions of Windows contained a driver for USB connected serial devices: usbser.sys. However the driver did not include a compatible ID match in an INF. The driver had to be included using modem INFs which was not standard.

In Windows 10, we added inbox support for USB CDC Abstract Control Model (ACM) compliant hardware. Usbser.sys is now installed as a compatible ID match for USB CDC compliant hardware, without requiring a 3^rd party driver or inclusion via modem INFs.

Now devices that report these compatible IDs: 

• USB\Class_02&SubClass_02&Prot_01
• USB\Class_02&SubClass_02

… including popular prototyping boards like Arduinos – just work with our built-in driver.  

Also usbser.sys has been completely re-written in WDF, improving its overall reliability as well incorporating new features for power management i.e. USB Selective Suspend.  See USB Serial driver on MSDN for details.

2.   A Windows Runtime API for communication with Serial devices

Windows 10 includes the Windows.Devices.SerialCommunication universal API designed for these three scenarios:

1. USB Peripherals like Arduinos – including as a USB Accessory on new Phones and Tablets
2. Peripherally connected USB to RS-232 Adapters
3. UARTs inside embedded  systems like MinnowBoard Max or Raspberry Pi v2 running Windows IoT SKU

This API does not include support for accessing UARTs/COM ports inside Phones/Tablets/PCs; Windows 10 focused on above 3 scenarios.

//Build/ 2015 USB Accessories including SerialCommunications session introduces this API and walks thru the design and usage of it.

Windows 10 SDK includes two Universal SDK samples illustrating this API:

1. CustomSerialDeviceAccess SDK Sample
2. New SerialArduino SDK Sample from above //build talk is now available including C# and Arduino sketch source code.

How to Provide Feedback

We listen and act upon customer feedback; all of above are all results of prior feedback.   If you have encountered a problem with functionality described in this blog entry, or want additional functionality, please see below.

Our team listens to two feedback channels to provide feedback:  Forums and the Feedback App (see Feedback App post for additional information) are available to everyone.   Please follow below guidance on where to provide your feedback and what to include to help us efficiently act upon your feedback.

Forums

Please create a new post on the Windows Insider Program forum under the ‘Devices and Drivers’ Topic.

Feedback App

Please file a bug under:
Category:  Hardware, Devices, and Drivers
Sub-Category:  USB devices and connectivity

What information to include

To help us efficiently act upon any bugs for feedback you have, please include relevant information below.

Problems with built-in USBSer.sys
USBSerial driver for USB CDC compliant devices

• Feedback or Bugs:  Please include ‘USBSer’ in bug title
• Bugs, please add: 
• Crisp steps to reproduce the issue
• Hardware IDs and Compatible IDs for target device  (below)
• If problem involves data transfer, please include Traces as described under Tracing below.

Problems with Windows.Devices.SerialCommunication Universal API

• Feedback or Bugs: Please include ‘Windows.Devices.SerialCommunication’ in bug title
• Bugs, please add:
• a sample code fragment that illustrates the problem
• All App manifest device capabilities declarations,  like

 <DeviceCapability Name=”serialcommunication”>

<Device Id=”any”>

<Function Type=”name:serialPort” />

</Device>

</DeviceCapability>

 <DeviceCapability Name=”serialcommunication”>

<Device Id=”any”>

<Function Type=”name:serialPort” />

</Device>

</DeviceCapability>

How to capture Hardware IDs

1. Attach your Arduino, open Device Manager, select the board, select Properties, then Details tab
2. Select Hardware IDs from Property dropdown
3. Select the values, right click and “copy” them – and paste into the bug.
4. Select Compatible IDs from Property dropdown
5. Select the values, right click and “copy” them – and paste into the bug.

Example: Arduino Uno R3

Hardware IDs
USB\VID_2341&PID_0043&REV_0001
USB\VID_2341&PID_0043

Compatible IDs
USB\Class_02&SubClass_02&Prot_01
USB\Class_02&SubClass_02
USB\Class_02

Tracing

Please enter the copy and paste below commands into an Administrative command window, reproduce the problem, and attach the resultant trace files into a bug:

Before Repro

logman create trace -n Serial_WPP -o %SystemRoot%\Tracing\Serial_WPP.etl -nb 128 640 -bs 128

logman update trace -n Serial_WPP -p {7F82DC23-235A-4CCA-868C-59531F258662} 0x7FFFFFFF 0xFF

logman update trace -n Serial_WPP -p {8FBF685A-DCE5-44C2-B126-5E90176993A7} 0x7FFFFFFF 0xFF

logman update trace -n Serial_WPP -p {0ae46f43-b144-4056-9195-470054009d6c} 0x7FFFFFFF 0xFF

logman start -n Serial_WPP

<Reproduce the problem at this point (do not copy and paste this)>

AfterRepro

logman stop -n Serial_WPP

logman delete -n Serial_WPP

md %systemroot%\Tracing\Logs

move /Y %SystemRoot%\Tracing\Serial_WPP_000001.etl %SystemRoot%\Tracing\Logs\Serial_WPP.etl 

Authored by Mike Ma [MSFT]

Feedback from users is one of the many ways the USB team identifies and prioritizes issues and fixes. However, not all feedback is actionable; many times, we need detailed logs to understand what is causing and issue and sometimes which component the issue is even in. For example, you might have a USB keyboard that is not working, to fix the issue our team first needs to determine if the issue is the USB Controller, the device, the HID layer, or even in an intermediate hub. Gathering all the logs to investigate an issue can a bit painful, so we have worked to make it easy to use the capabilities of the Windows Feedback application to provide the most actionable feedback as possible.

This blog post details the resources available to end-users in providing the most actionable feedback to the USB team under Windows 10. A key requirement to filing actionable USB feedback is to use the “Repro mode” feature in the Windows Feedback application. Repro mode allows us to configure a rich set of custom log collection to help root root-cause USB issues. At the time of this writing, USB host logs will be captured on either Desktop or Mobile. If you use Repro Mode, we will get logs containing ETW traces of USB2, USB3, UsbUcx, and hub events, which are not filtered. USB function logs will not be captured. Otherwise, if you do not use Repro Mode, we will not get these logs. Be aware that logs may be as small as 10mb or as large as 100mb depending on how much USB traffic and how much time you spend in Repro Mode. When you send feedback using Repro Mode, please make sure you actually reproduce the issue.

Please continue to provide feedback on our blogs! This blog will be updated as necessary with new guidance and information. If you choose to capture your own USB logs outside of Windows Feedback Repro Mode, look through our other blog entries on how to do this, for example this blog.

Windows Feedback on Desktop

1. Launch the Windows Feedback app from the Start menu. The Feedback tile should look like this.

2. After launching the Feedback app, select Hardware, Devices, and Drivers from the left-hand column in blue.

3. On the next page, select USB devices and connectivity (near the bottom of the left-hand column).

4. Click on Add new feedback. You should see a screen like this. Make sure you select “Problem” when filling out the UIF page.

5. Next, click on the Reproduce button. When you see this pop-up, you have 60 seconds to do what you were doing beforehand that causes the issue to occur. This allows logs to be captured when you are “reproducing” the issue. Leave this screen alone until you are done. Please disconnect all other USB devices from the system except for the device on which you reproduce the issue before selecting the reproduce button.

6. Click “Done” to dismiss the pop-up, then click Post feedback. You should see the attachment icon below the “Reproduce” button. If you need to abort, hit Cancel and go back. In other words, don’t click the “Post feedback” button if you do not want to submit your logs.

7. This feedback will be sent to the USB team with logs. Thank you!

Windows Feedback on Mobile

1. Launch the Windows Feedback app from the Start screen. The Feedback tile should look like this.

2. After launching the Feedback app, select the plus icon on the bottom to add new feedback.

3. On the next page, make sure you select “Problem” for the kind of feedback. Then, select Hardware, Device, and Drivers from the first dropdown and USB devices and connectivity from the second dropdown. This will expose the Reproduce button.

4. Next, click on the Reproduce button. When you see this pop-up, you have 60 seconds to do what you were doing beforehand. This allows logs to be captured when you are “reproducing” the issue. Leave this screen alone until you are done.

5. Click “Done” to dismiss the pop-up, then hit the Send icon near the bottom. You should see the little attachment icon below the “Reproduce” button. If you need to abort, hit Cancel and hit the back button. In other words, don’t hit “Send” if you do not want to submit your logs.

6. This feedback will be provided to the USB team with logs. Thank you!

Authored by Michelle Bergeron [MSFT]

Windows 10 introduced support for the USB Type-C connector. With many USB Type-C systems and devices hitting the market, the USB team is frequently asked: “If I’m building a USB peripheral device or system with a Type-C connector, do I need to write a custom driver for it to work on Windows?”

The answer depends on the type of product you are building.

USB Type-C peripherals without alternate modes

USB Type-C supports alternate modes, which allow different protocols other than USB to be carried out over the Type-C connector.

If you’re building a Type-C peripheral device that does not use alternate modes, you do not need to write a new USB client driver as long as you can use one of the inbox USB device class drivers from Microsoft. From Windows’ standpoint, your device looks no different from a legacy USB device without a USB Type-C connector.

Microsoft provides inbox drivers for several classes of USB devices. If your product is one of these device classes, you will not need to write a USB client driver because Windows’ existing USB device class driver will be able to automatically work with your Type-C peripheral. Review the list of USB device class drivers included in Windows to check if you can take advantage of one of these drivers for your product.

You will need to write a custom driver only if you are unable to use one of Windows’ built-in device class drivers. If you have determined that you must write a new client driver for your USB device, start at Developing Windows client drivers for USB devices.

USB Type-C peripherals with alternate modes

If you are bringing up a peripheral which can operate in an alternate mode, you do not need to take any extra steps in your USB driver to make it work with a Windows system that supports the alternate mode.

However, the peripheral’s alternate mode will only work if the system to which it is attached has the hardware capabilities for the specific alternate mode. Since hardware capabilities vary widely between systems, do not take any dependencies on a system supporting your alternate mode.

When your alternate mode device is connected to a system which does not support the alternate mode, you should provide a backup experience over USB.  For example, if you are building a Type-C flash drive that uses Thunderbolt alternate mode, you will need to use the USB mass storage device class for the case that Thunderbolt is not present on the connected PC.

Also, you must correctly implement the Billboard specification in your device so it can notify the system if an alternate mode was not successfully entered. The Billboard Device Class specification is available from the USB-IF.

USB Type-C systems

If you are building a system that features a USB Type-C connector, there will likely be driver or firmware work required to bring up your system in Windows. Please refer to the MSDN documentation on this subject. Start at Windows support for USB Type-C connectors to learn more about USB Type-C connectors on Windows and to determine the steps that you will need to take to bring up your USB Type-C system and develop a driver for it.

Further reading

• USB Specifications
• Building USB devices for Windows
• Testing USB hardware, drivers, and apps in Windows

Authored by Michelle Bergeron [MSFT] and Makarand Sonare [MSFT]

There are new tests in the Hardware Lab Kit (HLK) that target systems with USB Type-C. Some of the tests require extra configuration – here is a guide to help you set up your test environment for them.

USB Type-C UCSI Data and Power Role Swap tests

Applicable tests

• USB Type-C UCSI Data Role Swap
• USB Type-C UCSI Power Role Swap

Hardware Requirements

1. Two UCSI 1.0 compliant Windows desktop systems.
2. UcmUcsi.sys must be loaded as the UCSI controller driver.
3. USB Type-C cable.

Note: If your Type-C system does not use UCSI, the test will detect this and allow your system to pass.

Test Setup

1. Designate one system as the System Under Test (SUT) and the other as the “Partner” system.
2. Install HLK client on the SUT.
3. Connect the UCSI Type-C connector on the SUT to the UCSI Type-C connector on the Partner via the Type-C cable.
4. Enable the UCSI test interface on the SUT by following steps 1-7 in the “How to Test UCSI” section of USB Type-C Connector System Software Interface (UCSI) driver.

Test Parameters

USB Type-C UCM Data and Power Role Swap tests

Applicable tests

• USB Type-C UCM Data Role Swap
• USB Type-C UCM Power Role Swap

Hardware Requirements

1. Two Windows systems, each with a USB Type-C connector.
2. The Type-C connector on the SUT must have a UcmCx client driver. For information about developing a UcmCx client driver, visit USB Type-C connector driver programming reference.
3. USB Type-C cable.

Note: If your Type-C system implements UCSI, this test is still applicable because UcmUcsi.sys is a UcmCx client driver.

Test Setup

1. Designate one system as the System Under Test (SUT) and the other as the “Partner” system.
2. Install HLK client on the SUT.
3. Connect the Type-C connector on the SUT to the Type-C connector on the Partner via the Type-C cable.

Test Parameters

UCSI Compliance tests

Applicable tests

This category of tests refers to all tests in the HLK with a name that begins with “UCSI”. UCSI Compliance Tests are meant to test the UCSI-capable Type C system’s compliance to UCSI Specification V1.0. These tests are marked as “manual” in the HLK. The test binaries are included in the HLK; however, you will need to run them yourself using the instructions below.

Broad Categories of UCSI Compliance Tests

• UCSI Command Interface tests.
  • Tests all of the UCSI commands that are claimed to be supported by the SUT.
• USB Operation Mode tests.
  • Tests all of the USB Operation Modes that are claimed to be supported by the SUT on the given Connector.
• USB Operation Role tests.
  • Tests all of the USB Operation Roles and role swaps that are claimed to be supported by the SUT on the given Connector.
• Power Direction Mode tests.
  • Tests all of the Power Direction Modes that are claimed to be supported by the SUT on the given Connector.
• Power Direction Role tests.
  • Tests all of the Power Direction Roles that are claimed to be supported by the SUT on the given Connector. Performs role swaps.
• UCSI Notification tests.
  • Tests all of the UCSI notifications that are claimed to be supported by the System Under Test on the given Connector.

Hardware Requirements

1. Two UCSI 1.0 compliant Windows desktop systems.
2. Connection Exerciser hardware (optional)
3. USB Type-C PD capable cable.
4. USB 2.0 and USB 3.0 device
5. Debug accessory (if supported)
6. Analog audio accessory (if supported)

How to Identify Connector 1

All of the UCSI compliance tests assume Partner system or Devices are connected on Connector 1. To identify Connector 1, perform the following steps:

1. On the SUT, open an elevated command prompt.
2. From the elevated command prompt on the SUT, run the following test to identify Connector 1:

   Te.exe UcsiComplianceTest.dll /name:TestUcsi::UcsiCommandInterfaceTests::TestIdentifyConnectorOne

3. Repeat Step 2 on the Partner system to identify Connector 1.

Test Setup

1. Designate one system as the System Under Test (SUT) and the other as the “Partner” system.
2. Install HLK client on the SUT.
3. Connect the Type-B port on the Connection Exerciser Arduino to the SUT on any port other than Connector 1
4. Connect Connector 1 of the SUT to J1 connector on the Connection Exerciser directly.
5. Connect Connector 1 of the Partner to J2 or J3 connector on Connection Exerciser via Type-C cable.
6. Install TAEF on both systems
   1. For information about installing TAEF, refer to the TAEF Getting Started page.
7. Install the TestUcsi.sys driver on both systems.
   1. In Device Manager, find the device “UCSI USB Connector Manager”. This device will have the driver UcmUcsi.sys installed.
   2. Right click the device and select “Update Driver Software”
      1. Enter the path to TestUcsi.inf
         1. TestUcsi.inf and TestUcsi.sys are located in \TestUcsi\<ARCHITECTURE>\
      2. Follow the prompts to complete the driver installation. This will replace UcmUcsi.sys with TestUcsi.sys.

Test Parameters

Test Execution with Connection Exerciser

1. Connect the SUT and Partner system via a Connection Exerciser and Type-C Cable on Connector 1.
2. Refer to the Test Setup section for more information.
3. On the SUT, run UcsiCommandInterfaceTests.

   te.exe UcsiComplianceTest.dll /name:TestUcsi::UcsiCommandInterfaceTests::*

4. On the SUT, run UcsiTests.

   te.exe UcsiComplianceTest.dll /name:TestUcsi::UcsiTest::* /p: IsRunningOnSystemUnderTest=true /p:waittimeinminutes=1 /p:partnerMachine=<MACHINE_NAME>

Test Execution without Connection Exerciser

1. Connect the SUT and Partner system via a Connection Exerciser and Type-C Cable on Connector 1.
2. On the SUT, run UcsiCommandInterfaceTests.

   te.exe UcsiComplianceTest.dll /name:TestUcsi::UcsiCommandInterfaceTests::*

3. On the SUT, run UcsiTestsManual.

   te.exe UcsiComplianceTest.dll /name:TestUcsi::UcsiTest::* /p: IsRunningOnSystemUnderTest=true /p:waittimeinminutes=1 /p:partnerMachine=<MACHINE_NAME>

4. Each test requires executing some TAEF tests on the Partner system as per the instructions given on the command prompt.

Example: When running UcsiTestsManual::TestDFPModeToUFP on the System Under Test:

CMD> te.exe UcsiComplianceTest.dll /name:TestUcsi::UcsiTestsManual::TestDFPModeToUFP /p:IsRunningOnSystemUnderTest=true /p:waittimeinminutes=1 /p:partnermachine=<MACHINE_NAME>
 Test Authoring and Execution Framework v5.6 for x64
 Resetting the PPM
 Enabling All Notifications
 
 StartGroup: TestUcsi::UcsiTestsManual::TestDFPModeToUFP
 Setting USB Operation Mode to Dfp on Connector 1
1. On Partner Machine 
Run: CMD Prompt>Te.exe UcsicomplianceTest.dll /p:IsRunningOnSystemUnderTest=false /p:waitTimeInMinutes=<timeInMinutes> /name:TestUcsi::UcsiTestsManual::TestUFPModeOnPartner
 2. Connect the Partner
 3. Waiting for 1 minutes
 
           Waiting for:                   ConnectChange

The above test sets Connector 1’s USB Operation Mode to DFP on the SUT. It then requires you to run the following command on the Partner system:

Te.exe UcsicomplianceTest.dll /p:IsRunningOnSystemUnderTest=false /p:waitTimeInMinutes=<timeInMinutes> /name:TestUcsi::UcsiTestsManual::TestUFPModeOnPartner

Tracing Instructions

Test failures for the UCSI compliance tests can be investigated by collecting logs as per the below instructions.

1. Start WPP tracing before executing tests. Add the following commands to a .cmd file and run from an elevated command prompt:

   logman start -ets testucsi -ct perf -p {C9ED7F4E-286B-4054-B74F-7DE43EFBCA2A} 0xffffffff 0xff -o c:\testucsi\testucsi.etl
   logman start -ets testucsicontroller -ct perf -p {EBFD4AED-ED11-4F0C-8F37-9C93084D1530} 0xffffffff 0xff -o c:\testucsi\TestUcsiController.etl
   logman start -ets ucsitest -ct perf -p {F8BADD54-3B0F-4B79-8389-D0ABB7AE242B} 0xffffffff 0xff -o c:\testucsi\ucsitest.etl

2. Stop WPP tracing after running the tests. Add the following commands to a .cmd file and run from an elevated command prompt once the test completes.

    logman stop testucsi -ets
    logman stop ucsitest -ets
    logman stop testucsicontroller -ets

3. You will be able to view the resulting logs in UcsiTest.etl, TestUcsi.etl, and TestUcsiController.etl.

Test Cleanup

The UCSI Data and Power role swap tests require ucmucsi.sys rather than TestUcsi.sys. If you plan to run the UCSI Data Role Swap or UCSI Power Role Swap tests in the HLK after this test, be sure to clean up your test environment after running the UCSI compliance tests. You can do this by replacing TestUcsi.sys with the original UcmUcsi.sys or by reinstalling Windows on both systems.

Authored by Michelle Bergeron [MSFT]

UsbCApiCmd is a simple tool that you can use for basic validation of your Type-C implementation on Windows.

Who can use UsbCApiCmd?

UsbCApiCmd is applicable only to USB Type-C Connectors which use Microsoft’s USB Type-C Stack, the USB Connector Manager. UcmCx.sys needs to be loaded and running on the system. The tool is not applicable to systems which use other methods to manage the USB Type-C ports.

How to get UsbCApiCmd

UsbCApiCmd is included in the MUTT Software Package.

How to use UsbCApiCmd

Open a command prompt or PowerShell window on the system with the USB Type-C connector(s) you wish to validate. Run UsbCApiCmd.exe.

For as long as the program is running, the console will print out information about the USB Type-C connectors on the system that are registered with the USB Connector Manager (UcmCx). It will also print out information about detected Attach/Detach events on a connector. You can use it to validate that the Type-C software is seeing the events that you expect it to.

To stop execution, you may press Ctrl+C.

The below example is from a system using UCSI to manage its connectors with Windows. It has not detected any attach or detach events since the program started running.

Authored by Philip Froese [MSFT]

Newly added in the RS3 preview builds of the HLK, the USB Type-C HLK tests for UCM and UCSI will automatically capture debug traces from the relevant driver(s) during the test.

Note: if you are used to manually capturing the driver traces, that method should no longer be used during HLK testing.  Only one trace session can be active simultaneously, so enabling a separate trace will preclude the HLK from capturing meaningful diagnostic data.  This applies only to the UCSI specific tests in the HLK.

Locating the Log File

• After running the USB Type-C HLK test(s) of interest, switch to the Results tab of the HLK Studio.

• Expand the test result of interest and locate the failing Run Test

• Right click on Run Test, and then select Additional Files from the context menu. You should see an .etl file in the list.  Select Show All to open the file location in Windows Explorer.  Copy the .etl file for the next step.

Parsing the Log File using TraceView

For more information and detailed instructions about using TraceView to view existing ETL logs, see Displaying a Trace Log with a PDB File.

• Start TraceView, you will find it in the WDK under the .\Tools\<Architecture>
• Select the Options menu and Configure Symbols. Enter the following into the Symbols Path field to direct TraceView to the Microsoft public symbol server, and click OK.

SRV*https://msdl.microsoft.com/download/symbols

• Select the File menu, and Open Existing Log File.
• Enter the log file path and name into the Log File Name box, or navigate to the log file with the button to the right.

• On the next menu, select the Auto option and click OK.

• It may take several seconds for the symbols to be retrieved and the trace parsed, but once that completes, you should see an output like the following. In this example, for clarity only the Name, System Time and Message columns are displayed.  You can change the columns by right clicking on any column header and selecting from the context menu.

Reading the Trace

The driver traces contain a lot of low-level details which will not all be relevant to your investigation and may be difficult to make sense of.  However, as the example below will attempt to show, with a few tips and tricks, knowledge of the UCSI specification, and some experience, they can be valuable debugging tools.

A few tips before we get to the example:

• When starting to investigate a failure, use the HLK test log to understand the high-level flow of the test, what action failed and the nature of the failure.
• Use the timestamps in the test log and in the driver trace to correlate what the test was doing with the events in the driver. This can help you isolate the area of interest to a few dozen lines of what may be a very large trace file.
• Familiarize yourself with the UCSI command codes (Table A-1) and command data payloads (Section 4) defined in the UCSI specification as this information will be necessary to decode portions of the driver traces.
• The UCSI Compliance Tests, which use the testucsi driver enable several extraneous providers for which there are no symbols. You can ignore events from Unknown Provider in those traces.  These events are mostly useful for debugging the test code itself and may be removed from the HLK in the future.
• In the Ucm and Ucsi Role Swap Test traces, you will see events from UcmCx and the PolicyManager which you can largely ignore. The UcmUcsi provider will contain the lowest level details and specific notifications and message payloads.

Example

In this example, the USB Type-C UCSI Power Role Swap Test has failed with the following sequence in the HLK test log:

This trace is telling us that the connector was initially a power provider.  The test then sent the Set Power Direction Role command, and re-checked the port status at which point the port was still a power provider.  Let’s look at the driver trace.

First, we’ll copy UcsiRoleSwapTrace.etl from the HLK results temporary location, and open it with TraceView.  The timestamp in the test log for the SetPdr command is 8:39:13:382, so we’ll start there in the driver trace and look forwards for the Set Power Direction Role command.  We find it recorded in the trace with a timestamp 12 ms later:

In this case, the UCSI test interface accessed by the HLK test records that this is a “SetPowerRole” command, but we can inspect the actual command in the third line to confirm that it is indeed command 0xB, which we see in Table A-1 of the UCSI specification is the SET_PDR command.  The second line in this snippet reports that “Power role change to 0x1 was requested.”  The value of 0x1 represents an internal enumeration value in the UcmCx driver which maps 0x1 to the Sink power role, and 0x2 to the Source power role.  (Please note, this does not match the Power Direction Role value specified in Table 4.24 of the UCSI specification). So, now we have confirmed that we see the correct SET_PDR command being successfully sent to the UCSI device to switch the connector to the consumer role.

Next, since this was an asynchronous command, let’s look for the completion.  We find it approximately 200ms later in the trace:

Here we see a notification with only bit 32 of the CCI set which per Table 3-2 of the specification is the Command Completed Indicator.  We see that printed in the next line, which also confirms that this was command 0xB (SET_PDR).  The final line of this snippet is confirmation that the UCSI driver believes that the SET_PDR to role 0x1 (consumer) is completed successfully.

Going back to the HLK log, we see that at 8:39:13.890, the test logs that the connector is still in the provider mode and fails.  This means that the test must have queried the connector status before this point, so we can go to this timestamp in the log and work backwards looking for a GET_CONNECTOR_STATUS (0x12) command.  Here’s what we find:

We have command 0x12 completing successfully with a data payload of 9 bytes based on the CCI.  See Table 3-2 of the UCSI spec to parse the specific fields in the CCI.  Reviewing section 4.5.18 of UCSI for the Get Connector Status data payload, we see that it is indeed 72 bits (or 9 bytes) long.  Now for the tricky part, what was the connector status?  Unfortunately, this is a place where the clarity of the log file is lacking and you will just have to follow these rules to interpret the connector status result:

• Third from the bottom is a blank log line. This indicates that none of the Connector Status Change bits were set.  If they were, this log line would contain the string names of each set Connector Status Change bits (see Table 4-46 in the specification).
• Second from the bottom, we have three named fields, Connect, PartnerFlags and RDO. These correspond to the Connect Status, Connector Partner Flags, and Request Data Object fields in Table 4-45 of the spec respectively.
• The last row of the above snippet is four single digit hexadecimal numbers. Unfortunately, these are not explicitly named in the log, but they correspond, in order, to the Power Operation Mode, Power Direction, Connector Partner Type, and Battery Charging Status fields of Table 4-45.
  • If the Provider Capabilities Limited Reason field is set, the reason will be printed as a string-name in this line as well. In our example, it is not set.

In this example, we see that the connector is reporting a connection, it is in PD power mode, it is operating as a provider, and the partner is a UFP and operating in an alternate mode in addition to USB.

This example is somewhat trivial: we went through a failure in the HLK log and simply checked that each step was completed in the driver as expected, and confirmed that the connector status did indeed report an unexpected power direction.  At this point we would need to work with the firmware engineers for this UCSI implementation to understand why the SET_PDR command completed successfully but the role did not change.

Authored by Matthew Hartman [MSFT] 

To support the wave of VR HMDs coming to market, Microsoft has developed the HMD Exerciser Kit. This kit is based on the MUTT ConnEx platform and is specifically tailored for HMD testing. 

The HMD Exerciser Kit provides 

• USB Plug/Unplug/Multiplexing 
• HDMI Plug/Unplug/Multiplexing 
• IR User Presence Detection Spoofing 
• Independent Display Brightness/Color Detection
• 2x Servo Control with Independent Servo Power 
• HMD Audio Level Monitoring 
• USB Voltage/Current Polling 

The setup is flexible and can be designed to meet your specific test requirements. Here’s an example of how we used the HMD Exerciser Kit in our lab. In this configuration, we have also have the two motion controllers and the HMD on turntables for movement/FOV testing. 

HMD Exerciser Kit Hardware 

The kit includes two main components. The HMD Exerciser (left) and the HMD Board (right). 

The HMD Exerciser is the main unit for all the connections to the HMD and PC. It handles all of the measurements, multiplexing, and PC communication. More details about the components that make up the HMD board are available in the Documentation. 

The HMD Board contains the hardware that interacts with the HMD’s displays and presence sensor. The two TCS34725 color sensors are placed to line up with each display. This allows independent brightness/color measurement. The IR photodiode and LED match the typical placement of IR user presence sensors. They are used in combination to spoof user presence or absence. The desired user presence state is controllable via software. 

The HMD Board fits in a 3D printed mount which is designed to clip securely into the HMD. This mount is designed for the Acer Windows Mixed Reality HMD. 

 The HMD Board attaches to the HMD Exerciser using the flat ribbon cable shown above. Each HMD Exerciser can test up to two HMDs with a single PC. 

Find more details in the docs here. 

HMD Exerciser Kit Software 

The HMD Exerciser Kit is controlled either through a command line executable or managed class. The command line utility is available in the MUTT tools, and the managed class is available in the BusIoTools Git repo. Look for more details in the Microsoft Docs. 

To get started with the command line tool, identify which ports your HMD is plugged in to on the HMD Exerciser and select those ports to connect the HMD. For this example, we’ll use USB and HDMI port 1. 

Next, tell the kit what port (1 or 2) your HMD Board is plugged in to. For this example, we’re using port 1. 

After this command, all the display/audio/presence commands will apply to the HMD on port 1. Now we can grab the HMD’s display brightness, display color and audio level. We can also set user presence spoofing if the HMD uses IR user presence detection. 

To disconnect the USB or HDMI ports, just set the port to ‘0’ in the command 

More Info and Purchasing 

Check out the HMD Exerciser Kit documentation on Microsoft Docs and buy the hardware from MCCI. 

Authored by Philip Froese [MSFT]

In the next release of the HLK, the UCSI tests have been updated to run against the new Type-C SuperMUTT device instead of a partner system. This means the test setup will be simpler, the tests will run more quickly, and test content will be more thorough than in Windows 10 April 2018 Update HLK and earlier. The new preview tests are only in pre-release HLK builds 17676 and higher.

New Test Setup

The new test setup is simple: it requires a single Windows PC with Type-C, designated the System Under Test (SUT), and the Type-C SuperMUTT connected to one of the Type-C connectors on the system. See the image below.

Type-C SuperMUTT

The Type-C SuperMUTT is the newest edition to the Microsoft USB Test Tool (MUTT) family of devices. It incorporates the functionality of the legacy SuperMUTT device as well as Type-C and PD functionality.

The software and firmware utilities are available in the MUTT Package download: https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/mutt-software-package

And the tool is available for purchase through MCCI: http://www.mcci.com/mcci-v5/devtools/type-c-supermutt.html

Firmware version 45 or later, available in MUTT Package v2.6 and later, is required to run the UCSI HLK tests in the next release of the HLK.  See the TypeCSuperMUTT.pdf documentation in the MUTT Package download for more information.

New Test Names

The UCSI compliance tests have been replaced with a new version of the tests to run against the Type-C SuperMUTT. The new version of the test has the tag “[Type-C MUTT]” added to the test name. You will see both the old and the new versions of the test in the next release of the HLK pre-release kit for some time as we want to leave the old version in for at least a few weeks to enable cross-version validation if needed.

What is Different?

Beyond a new name and a simpler test setup, what else is new in the tests? For the most part, the tests cover the same features in the same manner as the original tests did. However, there are some cases where the new tests will be more rigorous.

Take USB Operation Role tests for example. Many desktop UCSI systems do not support being set into the UFP role, though they may resolve to that role initially when connected to a pure DFP (such as a charger). This behavior makes it difficult to test every permutation of DFP/UFP/DRP connections that a platform may have to support if it is tested against a functionally equivalent peer device. However, with the Type-C SuperMUTT the test can deterministically place the Type-C SuperMUTT into a specific, known port direction or configuration before connecting it to the SUT and is thus able to provide more complete test coverage of USB Operation Role features.

Thus, there may be some test cases in next release of the HLK that are more thorough and thus uncover new platform quirks that Windows 10 April 2018 Update HLK and earlier test content did not.

You will also notice that some tests have been removed. Some tests were determined to be redundant when run against the Type-C SuperMUTT and so were removed. Others targeted UCSI commands that have been removed in UCSI v1.1, and which Windows never supported, so were removed as obsolete.

USB Type-C UCSI Data and Power Role Swap Tests

Applicable Tests

• USB Type-C UCSI Data Role Swap
• USB Type-C UCSI Power Role Swap

Hardware Requirements

1. One UCSI compliant Windows system.
2. One Type-C MUTT device.

Test Setup

1. Install HLK client on the System Under Test (SUT).
2. Connect the Type-C MUTT to any USB Type-C port on the SUT.
3. Locate the device node in Device Manager (devmgmt.msc) named "UCSI USB Connector Manager". The node is under the "Universal Serial Bus controllers" category.
4. Right-click on the device, and select "Properties" and open the "Details" tab.
5. Select "Device Instance Path" from the drop-down and note the property value.
6. Open Registry Editor (regedit.exe).
7. Navigate to the device instance path under this key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\<device-instance-path from step 6>\Device Parameters
8. Create a DWORD value named "TestInterfaceEnabled" and set the value to 0x1.
9. Restart the device by selecting the "Disable" option on the device node in Device Manager, and then selecting "Enable". Alternatively, you can simply restart the PC.

Test Parameters

Troubleshooting

• Some UCSI commands are marked "optional" in the UCSI specification. However, Microsoft requires some optional commands to be implemented in order for the UCSI driver to function. The tests may fail if you've forgotten to implement one of these commands in your BIOS. You can find that list of commands here.
• If the test is not detecting the Type-C MUTT:
  • Check your cable connection to the Type-C MUTT.
  • Check in Device Manager. Has the Type-C MUTT enumerated?
    • Look for the "SuperMUTT" device with hardware ID USB\VID_045E&PID_078F in the Device Manager.
  • Check in Device Manager. Does the "Device Status" of the UCSI device report any errors? If so:
    • Right-click on the UCSI device and disable it.
    • Start UCSI logging (see https://aka.ms/usbtrace )
    • Enable the UCSI device. Do whatever it takes to get the yellow bang to reproduce.
    • Stop logging.
    • View the resulting WPP logs and check for errors.

USB Type-C UCM Data and Power Role Swap Tests

Applicable Tests

• USB Type-C UCM Data Role Swap
• USB Type-C UCM Power Role Swap

Hardware Requirements

1. Onoe Windows system with a USB Type-C connector.
2. One Type-C MUTT device.

Test Setup

1. Install the HLK client on the System Under Test (SUT).
2. Connect the Type-C MUTT to any USB Type-C port on the SUT.
3. Ensure all other USB Type-C ports are disconnected.

Test Parameters

Troubleshooting

• "No USB Type-C Connectors found with partners attached".
  • Check your cable connection to the Type-C MUTT.
  • Check in Device Manager. Has the Type-C MUTT enumerated?
    • Look for the "SuperMUTT" device with hardware ID USB\VID_045E&PID_078F in the Device Manager.
    • If your system is using UCSI, you can take UCSI logs during attach to investigate why the attach has not been reported to the OS.

UCSI Compliance tests

Applicable tests

This category of tests refers to all tests in the HLK with a name that begins with "UCSI" and is post-fixed with “[Type-C MUTT]”. The early pre-release HLK builds will include the original UCSI Compliance Tests as well, these tests have the same names, but without the “[Type-C MUTT]” suffix. Unless you are specifically running the old test for comparison, you should ignore the old versions of the tests.

UCSI Compliance Tests are meant to test the UCSI-capable Type-C system’s compliance to UCSI Specification.

Broad Categories of UCSI Compliance Tests

• UCSI Command Interface tests.
  • Tests all of the UCSI commands that are claimed to be supported by the SUT.
• USB Operation Mode tests.
  • Tests all of the USB Operation Modes that are claimed to be supported by the SUT on the given Connector.
• USB Operation Role tests.
  • Tests all of the USB Operation Roles and role swaps that are claimed to be supported by the SUT on the given Connector.
• Power Direction Role Tests.
  • Tests all of the Power Direction Roles that are claimed to be supported by the SUT on the given Connector. Performs role swaps.
• UCSI Notification tests.
  • Tests all of the UCSI notifications that are claimed to be supported by the System under Test on the given Connector.

Hardware Requirements

1. One UCSI compliant Windows system.
2. One USB Type-C MUTT device.

How to identify Connector 1

In the next release of the HLK, the tests can be run against any available connector on the SUT, but you will need to specify the connector that the Type-C MUTT is connected to via the UcsiConnectorNumber parameter. If you do not know the connector numbers on a multi-port system, the UCSI Connector One Identification [Type-C MUTT] test can help you identify which is connector 1. If the SUT has 3 or more connectors, and you don’t know their mapping, you will simply need to experiment by connecting the Type-C MUTT to an unknown port, setting UcsiConnectorNumber to a new value, and running a test to see if the device is found on that connector; repeat with a new connector number until successful. This should just take a few attempts to establish the connector number layout for any new system.

Test Setup

1. Install the HLK client on the System Under Test (SUT).
2. Connect the Type-C MUTT to any USB Type-C port on the SUT.
3. Record the connector number to which the Type-C MUTT is attached. You will supply this number when scheduling the tests.
4. Install TestUcsi.sys driver on the SUT. On a URS system, it is important that the Type-C MUTT is connected before the test driver is installed, otherwise the USB host stack may not get loaded.
   • In Device Manager, find the device "UCSI USB Connector Manager". This device will have the driver UcmUcsi.sys installed.
   • Right-click the device and select "Update Driver Software"
     • Enter the path to TestUcsi.inf
       • TestUcsi.inf and TestUcsi.sys are located in \TestUcsi\<ARCHITECTURE>\
     • Follow the prompts to complete the driver installation. This will replace UcmUcsi.sys with TestUcsi.sys.

Test Parameters

Test Execution

The Type-C MUTT allows the HLK tests to emulate and automate all scenarios in next release of the HLK that previously may have required manual intervention. When scheduling the UCSI tests, only select the ones with the “[Type-C MUTT]” designation. You can select all of them at once, or only run a subset of them if you wish.

Test Cleanup

The UCSI Data and Power role swap tests require UcmUcsi.sys rather than TestUcsi.sys. If you plan to run the UCSI Data Role Swap or UCSI Power Role Swap tests in the HLK after this test, be sure to clean up your test environment after running the UCSI compliance tests. You can do this by replacing TestUcsi.sys with the original UcmUcsi.sys or by reinstalling Windows on both systems.

Troubleshooting

• Please review the HLK test log to determine why the test failed. In many cases, the test log will state common known causes of a given failure and how it may be resolved.
• Exame the driver logs per the guidance provided in the following blog post:
  • https://blogs.msdn.microsoft.com/usbcoreblog/2017/08/03/reading-driver-logs-in-usb-type-c-hlk-tests/
• If the test failure is unclear from both the test and driver logs or you believe it to be incorrect, and you are going to reach out to Microsoft for additional guidance, please prepare the following when reporting the issue to us. This will help us get to the bottom of your bug report as quickly as possible!
  • The HLKX package containing the failed test result. This will contain the failed test log as well as driver and Type-C MUTT firmware logs we may need to review.
  • An explanation of what diagnostic efforts you have already applied and why they were inconclusive:
    • Was the test log inconclusive or confusing? (We'd love to hear feedback in order to make them better!)
    • Do you believe the test result to be incorrect, and if so, why?
  • If you believe a test failure to be in error, do you have passing logs from the same test case in Windows 10 April 2018 Update HLK? If so, please provide them. Or do you have other evidence (e.g. driver traces, PD trace, etc.) that would demonstrate the PPM behaving properly in the scenario under test?

We’ve been working with several different feature teams within Microsoft to enable access to various hardware devices from inside Windows Containers running on Windows IoT. The link below provides more details about this effort and would be the right place to provide feedback on the progress made so far, and suggestions for additional functionality you may need.

Bringing Device Support to Windows Containers

The USB Core Team Blog is moving to the Tech Community platform.  All blog posts have been migrated and are accessible via https://aka.ms/usbcoreblog.

Any aka.ms links that you may have to individual posts have been migrated to point to the new location as well.  This version of the blog will no longer be updated and the contents will be deleted soon.