The I2C validation test checks the API interface compliance only. Function Documentation. USB Command Verifier (USB3CV Tools) for USB 3 controllers Before using the command verifier tools, make sure that you have an application running with the USB device class that you are going to test. For example, if you want to test the behavior of the USB MSC device class, create a µVision project containing this class. In CV and xHCI test, there only can be ”one” USB3.0 host controller on MB. If there is already another USB3.0 controller on MB, it should be disabled, and then you can perform the CV and xHCI test to the one on USB3.0 host card. Step 1: After installing the CV and xHCI test program, see the readme file in the “Documents File” folder.

  1. What is USB2CV Installer - x86 Release.exe? USB2CV Installer - x86 Release.exe is known as U and it is developed by U.We have seen about 1 different instances of USB2CV Installer - x86 Release.exe in different location.
  2. The USB3CV tool is supported on Windows 7 and above. USB 3 The High Speed Compliance Device is a PCI etc. Install the net2280.sys driver.Usb Gadget Driver - Free download as such as the net2280 on PCI (USB and so on most hardware it can interoperate easily with MS-Windows. One interesting.Usb Prism2 Driver.
This post was written by eli on June 15, 2019
Posted Under: electronics,FPGA,USB


While implementing Xillybus‘ USB 3.0 general purpose IP core for FPGAs, I found the USB Implementers Forum’s compliance tool handy, yet somewhat quirky, for verifying I got things right. It was USB3CV version, running on Windows 10 @32 bit. The 64 bit version works the same (I’ve tested it as well).

A GPLed open-source version for Linux is something one could have wished for (and would probably improve things considerably), but that’s probably too much to expect when Microsoft is all over the USB standard.


These are my notes as I went along.

Obtaining and installing

Download USB3CV from this page. Installation went smooth on Windows 10 @32 bits (and 64 bits as well).

Usb3cv Tool

As suggested by the utility’s author, disable UAC completely on the system by invoking regedit, setting the EnableLUA to 0 on the following path: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem. And restart Windows. This seems to be a matter of convenience, and not something to do on anything else but an internal computer intended for testing only, as it’s a security hole.

A usbif.json file can be obtained from USB-IF for use by USB3CV. This only allows looking up the Vendor ID, so there’s no problem working without it. There will be two red lines in the log, but the relevant tests passes without this file as well.

Installing on Windows 7 (32 bit) failed on installing the Microsoft Visual C++ 2017 Redistributable (vc_redist.x86.exe) prerequisite. Despite removing everything installed on that computer (under Programs and Features), the problem remained — it’s probably because SP1 isn’t installed on that machine.

Usb lpm tool

The hijack

When invoked, the USB3CV program replaces the original xHCI driver in Window’s I/O stack with one it uses for testing, and returns the original one when exiting. This means that all USB devices that are connected to the USB controller (possibly all USB devices on a motherboard) become effectively disconnected. That includes USB 2.0 and USB 1.1 devices. To work around this, either use good-old PS/2 keyboard and mouse, employ a remote session, or plug in an extra USB board (possibly as low as USB 1.1) and plug the USB mouse and keyboard there. Otherwise, well, no mouse and keyboard on a Windows system.

Also, be sure to close USB3CV before shutting down Windows, or it may not have enough time to bring the original driver back. See more notes on this issue below.


USB3CV is kind enough to prompt for which USB controller to take over, and it’s also fine if you accidentally knock out your own USB mouse and keyboard (a second dialog box requires confirming the takeover with a mouse click, or it times out and reverts it).

The immediate difference when plugging in a device when USB3CV is running (and has taken over the relevant controller) is that nothing happens — there is no enumeration nor descriptor fetching, as there would usually be. This happens only later on, when requesting tests, in which case the controller is scanned for devices. Several times, actually.

Another significant difference is that the test xHCI driver doesn’t have these small workaround features that a usual xHCI driver has for getting unstuck from protocol bug deadlocks, and it doesn’t attempt to smooth protocol errors. Which makes sense: A regular xHCI driver’s goal is to make the device work. The test driver is there to expose errors, so it should get stuck when things are done wrong. Hence it may expose bugs that were smoothed out when the device was connected in a regular manner to a computer. For example, a bug in the device’s LTSSM implementation may be smoothed out by a regular driver by issuing a warm reset and starting all over again, without any log message, but USB3CV’s driver will just fail.

So if weird stuff happens with USB3CV, check your own implementation, and don’t look for bugs in USB3CV. Reject the immediate “but it worked before” instinct to blame something else than your own design.

Hands on

Double-click the USB 3 Gen X CV icon. A dialog box with a list of USB controller(s) opens. Select the one that the device is attached to. All other USB devices on that controller, of all speeds, will be disconnected from the computer. Then the “Command Verifier” asks to verify this choice. If you just disabled your own mouse and keyboard you can’t click “Continue”, and that dialog box will time out, and the hijacked USB controller is released.

Then the main windows opens. Select “Chapter 9 Tests (USB 3 Gen X devices)”, Compliance Test (or Debug for individual tests), and click Run.

This is when USB3CV tries to find devices on the hijacked USB controller (it’s complete silence on wires until then). Sometimes this fails for no apparent reason — see below. A dialog box asking to select the device to work with appears, and is then followed by three dialog boxes asking for the number of retimers. If you don’t know what it’s about, you don’t have any, so select zero on all three.

When tests fail, the error messages may be misleading. For example, a problem with the device’s LTSSM made the GetDecriptor() test fail, spitting out the paragraphs in the spec that aren’t met, but on the wires there was no related SETUP packet sent (because the link wasn’t up, it turned out eventually). However the SET_SEL test went through OK nevertheless. So it may be really confusing. This is easily mistaken for a bug in USB3CV.

Even worse, it seems like a test failure can lead to all kind of unexpected and unrelated errors in following tests.

Usb3cv tool

The tool also complains when the device declares itself as USB 3.0 in the device descriptor rather than USB 3.2, considering it to be a test failure. What about USB 3.0 devices, not supporting anything related to SuperSpeedPlus? Why should they even mention USB 3.2?

When things get stuck

If weird things happen (in particular if the device isn’t found by USB3CV and/or otherwise) re-run USB3CV and exit it, so the original xHCI controller is brought back upon exit. That’s what USB3CV expects to see on invocation, and it doesn’t work properly otherwise. So just run the tool and exit immediately, and then run it again.

Usb Port Speed Test Utility

It’s better to start USB3CV with the device already plugged in. Moving it to another plug while USB3CV is running often helps.



Unfortunately, USB3CV crashes quite a lot (mostly in relation with test failures, in particular failing tests related to low power states). The “Command Verifier Tool has stopped working” dialog box may appear. A rather ironic workaround seems to work: Clicking “Abort” as the tests run (towards the end, actually), and then clicking “No”, a bit before the end of the tests, in the dialog box asking if you really want to abort (so the test isn’t aborted, after all). Sometimes the enumeration test is done, sometimes it isn’t (and fails with some ugly error), so maybe that’s related.

Sometimes USB3CV just gets stuck in a test, and attempting abort the test doesn’t help. Closing the USB3CV windows brings up “Wait for a stack switch” after which Windows crashes with a “Your PC ran into a problem and needs to restart. You can restart”. Which probably means that it’s OK to recycle power (no other possibility left). Windows suggest searching online for “WDF_VIOLATION” too.

Whether the power recycle took place or not, USB3CV didn’t have the opportunity to return the original xHCI driver as it usually does upon a normal exit. Therefore, be sure to invoke and exit USB3CV as mentioned above to get the system back to its original state.

USB 2.0 Specification Chapter 9

When testing a USB device or hub you should at least test USBCV. It will automatically test the device framework and descriptor. USBCV is free of charge and is a very easy to use application so there is nothing from stopping you running these tests. There is a USB20CV and a USB30CV available on the USB.ORG that is updated on a regular base. Read the installation guide carefully before you start testing.
Here some common failures:
Not using a hub with port power switching
When running the USBCV Chapter 9 test it's mandatory to use hubs that switch their Vbus.
It is however very hard to get hold of these hub there now a days most hubs keep Vbus on at all times.
When using these kind of hubs it will add an additional test to USBCV. It will test if a device can connect within 1 second after Vbus is on.
This test cannot be done when using a hub that has Vbus always on. It is a common failure for many devices that they are unable to connect within this 1 second so be sure it's tested.
The bcdUSB field must be 2.0 not 1.1
A common mistake is that people assume that USB 1.1 stand for full and low speed and USB 2.0 for high speed only. This is not true there the USB 2.0 specification includes low, full and high speed. So also low and full speed are USB 2.0 and therefore the bcdUSB field must be 2.0 also for those products not 1.1.

Run the USBCV Class tests
If a device is MSC, HID, OTG, UVC, HUB run also the appropriate tests within USBCV,

Usb Command Verifier Tool

USB 2.0 device should also pass USB30CV
On top of passing USB20CV a USB 2.0 device must also pass USB30CV.

Usb3cv Tool 使い方

Use the correct VID

Usb Xhsett Tool

Use the VID of your company and not the one of your USB silicon provider.