Windows 10 Usbview
Joann Heavilin
The Universal Serial Bus Viewer (USBView) or usbview.exe is a Windows app that you can use to browse all USB controllers and connected USB devices on your computer. USBView works on all versions of Windows.
USBView is a sample application that enumerates basic information about USB host controllers, USB hubs, and attached USB devices. It also queries information about devices from the registry and through USB requests to the devices.
The right pane displays the USB data structures that pertain to the selected USB device. These structures include Device, Configuration, Interface, and Endpoint Descriptors, and the current device configuration.
As USBView is an older application, it may not display newer USB information. Other tools like Device Manager should be used as necessary. For more information on the IOCTLs that USBView uses to query information, see USBView.
I am trying to get a custom board with the stm32H745xi microcontroller to work as an USB MSC device. The board is designed by an eletronics expert and according to him the board should work. This is also confirmed when the device is put in boot mode and the usb bootloader is shown as a device in the windows device manager.
The problem that i am facing right now is that when the M4 has done the inital setup of the using the code generated by STCubeMX (latest version) and the USB cable is plugged into the computer that Windows 10 gives an descriptor enumuration error for the device. The device is configured an OTG_FS_device and the interupt for the OTG_FS_IRQHandler in enabled.
On inspection using the windows USBview, i found that the descriptor that is recieved by windows is empty. So i started debugging the code that is run on the M4 core and found that the intterupt for the OTG_FS_IRQHandler is not fired even tho it has been enabled.
After some futer diving into the code i found that the USBD_Start function calls the LL_OpenEP function twice, but botht imes sthe return value is USBD_FAIL this means that the pipes are never opend.
For example, IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX, fails to generate any traffic on the USB bus, but returns garbage data in the structure. I've analyzed the traffic using an external USB analyzer.
What you are experiencing is weird. Actually in several application we have developed we use the same IOCTL you mentioned with no issues at all. What version of the TI's xHCI driver are you using? Are you using the latest available? Make sure to use the latest driver available at ti.com.
Also, which usbview example are you using? Usbview has suffer lots of changes specially to handle USB3.0 devices, maybe you are using an older example and that is why it is crashing. I have used USBView with the TUSB7340 and TI's driver and everything works well.
Hi Alexis, I have tried several versions, including specifically 1.12.25.0 and 1.16.3.0. It's difficult for me to tell which version of USBView I'm using - one, marked 2.0.1 doesn't work, but I found a newer 6.1.7 that works correctly.
The particular application is a tool that performs raw communication with USB printers. While the Microsoft USB Print subsystem is used to handle the printing operation (without use of windows printer drivers), some advanced queries are done as part of the diagnostic data.
When a printer is connected to the port on the TI controller, these queries succeed but populate memory with invalid data. Here are some examples. On the TI controller, these calls do not generate traffic, but succeed.
The enumeration code is the only thing I've omitted here, because it is quite long. I am happy to post it if it would be helpful. It basically enumerates the USB Printers with SetupDiEnumDeviceInterfaces, then calls SetupDiGetDeviceRegistryPropertyA with SPDRP_ADDRESS to get the hub address, then calls CM_Get_Parent, CM_Get_Device_ID, SetupDiOpenDeviceInfoA and SetupDiEnumDeviceInterfaces to create a structure that can be used with SetupDiGetDeviceInterfaceDetail to get the path to the stack that is handling the hub that the printer is connected to, against which the queries are issued. I can also provide complete code\compiled examples if that would be useful.
Hello, I am using a Nexys A7-100T and an Arty a7-35T board with a Windows 10 computer. Both boards worked well. However since yesterday, Vivado does not recognize the boards anymore. Auto Connect only connects to localhost.
Installing Vivado again (with cable drivers) didn't help. I've also tried the hints in -do-you-do-when-your-board-is-no-longer-detected-by-vivado/ and it seems that the Windows device manager recognizes the boards.
The other thing you might check on the first machine (though if you had reinstalled Vivado, I would think this might have resolved it) would be to see if there is an instance of hw_server still running in the Windows Task Manager and "End Task" that process, since restarting the GUI does not necessarily end that instance for you.
Tried "Open new Hardware Target" and connect to local host. No Target is listed there. Stopping hw_server didn't help either. I've reinstalled Vivado several times. It also didn't help. I've also deinstalled the drivers USB Serial Converter A and B. I did a CPU reset on the board. No effect.
The board is connected to the computer (The power LED is on) and when I connect the board to the computer the drivers USB Serial Converter A and B are being installed by the computer and it is recognized as diligent USB device.
thank you for your answer. To avoid misunderstandings: I am not using both boards at the same time. It's just that I teach two different classes at two different schools and each school uses a different board.
Anyway, Vivado works now with my Nexys board. I think the trick was to run the ADEPT utility before starting Vivado as you recommended. Once Adept recognizes the Board, Vivado recognizes the board even without Adept being started before. I can't use my Arty board now for some other reason, but I will test Vivado with the Arty board as soon as I've got a replacement. If I don't post anything during the next days, it also works with the Arty board.
my problem is back. Both boards are neither recognized by Vivado nor by Adept. Screenshots1.docxThe LEDs on the boards are on and I use a powered hub. The Arty board is new and my nexys board worked yesterday.
When I connect one of the boards there is a reaction in the device manager and in USB View it appears as "USB Composite Device" with iProduct = " Digilent USB Device". Interestingly, the device name vanishes after some seconds and "Port#0006.Hub_#0001" appears. The line remains highlighted in green. (See the attached screenshots)
There's no reason why you can't have two or more boards connected to your computer at the same time. I frequency do projects involving 2 or more FPGA devices that need to be configured during a session. The Adept Utility for configuration of multiple boards is much more robust than Vivado Hardware Manager. There will be a problem if, say VIvado Hardware Manager is connected to the same target as the Adept Utility for Windows is.
As for detachment issues, my Win10 PC has an audible sound for USB attachment/detachment events. Do affected users hear this? I'm not convinced that this is the root issue. I doubt that there are USB debuggers involved. That doesn't mean that there isn't a process running in the background that isn't causing problems. If you PC is connected to a company or University network I'd confer with the IT department.
I'll likely have more to add to the list as this keeps interrupting the things that I'm trying to do. Anyway, this doesn't sound like the usual connection issues. I suppose that it could be faulty parts ( these things happen, especially when inventory issues are bad.
The boards work now. I am deactivated com 3 and 4 for the nexys board or com 8 and 9 for the arty board. (see screenshots). Could it be that drivers are being loaded twice or that there are drivers of a previously installed version are being loaded?
I've never seen an interaction between COM devices and Xilinx JTAG devices in many years of doing FPGA development. That doesn't mean that there isn't something different about your Win Pro and my Win10 Pro, or that there isn't something different about your boards.
There was a dark period, a while ago, when FTDI pushed out drivers that were looking for counterfeit chips. Amazingly, they thought that the solution was to permanently brick hardware that was deemed to be counterfeit. I'd be horrified if they revisited that idea, even if only involved detachment. A driver enumeration issue seems more likely.
If you can see your board in usbview, use Win10 Hardware Manager to see what the driver version is. You haven't mentioned if you allow Win10 to automatically update third party hardware drivers. Personally, I do NOT for a variety of reasons.
The version of the FTDI drivers is 2.14.1.2 of 14.9.2021 they are in the device manager under USB serial converter A and B. Interestingly, the USB ports which I had to deactivate (com3, 4, 8 and 9) use the same FTDI driver while COM 6 and COM 7 use Microsoft drivers. (I've attached the screenshot again).
The Windows-settings are made by our IT-department. I don't know them and I can't change them. I've looked at the update history and they were no recent updates. However, I've updated some drivers manually, but this was some weeks ago and Vivado recognized the boards afterwards
I am trying to connect a new Arduino NANO ESP32 to my windows 7 PC.
Installed the board ok but when I plug in the USB cable windows installs some driver but cannot find TinyUSB CDC so I don't get a COM port so I can program the device.
Searched the web but cannot find the driver.
Any help?
Here it is Dec 2, 2023 and I am having the same issue. I have a Windows 11 pc that connects just fine to the NANO ESP32, but my Windows 7 pc does not. I am getting Nano ESP32 DFU and TinyUSB CDC (Interface 1) as my two usb devices in Device Manager, but no com ports show up. I have tried installing CH340 drivers, but the nano is not enumerated as a comport. With Windows 11 it worked as soon as I installed the from the board manager. I cannot find any way to make this work in Windows 7. Maybe the drivers are not compatible, but Arduino has not issued any statement about this so far. As mentioned by the OP, searching the web does no good. I do wish that Arduino would give us something to go on here.
d3342ee215