Re: USB won't recognize sophisticated devices.

Gary Sams wrote:
"Paul" <nospam@xxxxxxxxxx> wrote in message news:fqeqsr$pmc$1@xxxxxxxxxxx

Use UVCView and see whether USB device enumerations are visible, to detect
a device when plugged in. This archived page has a download in the
upper right hand corner. (Don't let the "video" part of the title
fool you - it works for other USB devices as well, and my spare USB
mouse can be seen just fine.) This works best for devices plugged into
connectors directly on the computer.

UVCView – Diagnostic Tool for USB Video Class Hardware
http://web.archive.org/web/20070516010130/http://www.microsoft.com/whdc/device/stream/vidcap/UVCViewdwn.mspx

If you see your laser mouse in UVCView, it means the USB chip inside
the mouse, is talking to the computer. But it doesn't guarantee that
the rest of the mouse (laser/optical_array) works.

Paul

Thanks - I have tried USBView.

It shows a Standard OpenHCD USB Host Controller (I'll call this 1) and a Standard Enhanced PCI to USB Host Controller (2), each with 10 ports.

Plugging the mouse into different ports gives different results.
A rear port - it appears under 1. It is recognized as Logitech USB MX510 Optical Mouse. There is a yellow exclamation mark and the mouse does not light up. Device information says at the top - ERROR no string descriptor for index 2, and further down: ERROR- No open pipes. Further down under 'device descriptor' there are 2 further ERRORs - no string descriptor for index 1 iProduct, and index 2 iSerial Number.

A different rear port - it appears under 1. It is correctly recognized. There is no yellow error. It lights up but doesn't work. Under detail the following messages could be problems.
Current Config Value 0x01 (arrow) Device Bus Speed: Low
wMaxPacket size 0x0007 = Invalid bus speed for USB Video Class
CAUTION: This may be an invalid bInterfaceProtocol iInterface: 0x00
(note that plugging in a three button optical cordless mouse produces the same messages, but it works).

Front ports mainly produce the same result as the first described above. On one occasion, which I can't now reproduce, it appeared under Controller 2, but showed no lights and the same yellow errors.
Sometimes it shows a yellow error under controller 1 and is not recognized. No lights, and the main description says Failed Enumeration: Unknown Device.

Does any of this help?

Gary

I couldn't find a picture of the UVCView window, but a very similar program
USBView here, has the same displayed information.

http://www.die.de/blog/content/binary/usbview.png

Basically, how it works, is USB ports can support two standards. USB 1.1 and
USB 2.0. There are two kinds of logic blocks inside the Southbridge, and they
are connected via a multiplexer, to the physical USB port.

A USB 1.1 logic block, typically controls two USB ports. You may have noticed
a habit of putting USB ports in "stacks of two", and the stack of two may be
tied to the same USB 1.1 controller.

The USB 2.0 controller, tends to be shared over more ports.

In that USBView window, you're seeing the ports listed twice. During negotiation,
a plugged in device may end up operating at 2.0 speeds, or at 1.1 speeds. It
will either be "bound" to its USB 1.1 controller, or to the more widely shared
USB 2.0 controller. But it shouldn't show up on both at the same time. So
12 places may show in USBView/UVCView, but only 6 could be used at any one
time.

For a mouse, what I would expect to see, is the mouse show up on the "pair
of two" blocks, and not on the USB2 6, 8, or 10 shared block.

Note that, on some of the latest Intel chipsets, they have finally introduced
a second USB2 controller block, breaking the pattern seen on the screen. This
was done, to offer more USB2 bandwidth to the ports. But it doesn't change the
multiplexing thing, or the "either/or" nature of which block a plugged device
is bound to.

In the USBView picture above, the "Root Hub" at the top of the display, has
not been clicked to expose the two entries it contains. Otherwise, you'd be
looking at "three pairs of two" and the "six port" near the bottom. That is
typical of a range of Intel Southbridges for example. (The 82801 number is
what is pointing me at Intel, as that is an Intel number.)

I think this value, is supposed to be used for the control endpoint.

bMaxPacketSize0 Number Maximum packet size for endpoint zero
(only 8, 16, 32, or 64 are valid)

wMaxPacketSize is two bytes, and appears to support arbitrary lengths
(for data transfers).

Maybe the mouse is declaring itself to be a USB2 device, but that seems a
bit strange. Or maybe the computer and mouse are not communicating
error free.

http://www.beyondlogic.org/usbnutshell/usb5.htm

"The bcdUSB field reports the highest version of USB the device supports"
"USB 2.0 is reported as 0x0200, USB 1.1 as 0x0110 and USB 1.0 as 0x0100."

If a device cannot be fully enumerated (less well than the example in the
picture above), then it is pretty hard for Windows to either apply a default
driver or associate the device with a separately provided driver.
There are classes of devices, and some of them have built-in
drivers in Windows. For a pointing device, I would have
expected to at least be able to move the cursor, even without
installing a driver. I thought (but could be wrong), that third party
drivers for pointing devices, allowed handling extended numbers
of buttons, or binding them to commands and the like. At
least, my cheesy little test mouse I use here, for testing
UVCView, doesn't need any driver to behave like a mouse,
and is immediately recognized and works.

"HID Compliant Mouse" - my cheesy two button mouse, a freeby at a tech show

*******
---===>Device Information<===---
English product name: "HID-compliant Mouse (USB)"

ConnectionStatus:
Current Config Value: 0x01 -> Device Bus Speed: Low
Device Address: 0x02
Open Pipes: 1

===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x81 -> Direction: IN - EndpointID: 1
bmAttributes: 0x03 -> Interrupt Transfer Type
wMaxPacketSize: 0x0003 = Invalid bus speed for USB Video Class
bInterval: 0x10

===>Device Descriptor<===
bLength: 0x12
bDescriptorType: 0x01
bcdUSB: 0x0100
bDeviceClass: 0x00 -> This is an Interface Class Defined Device
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x08 = (8) Bytes
idVendor: 0x03EE = Mitsumi
idProduct: 0x6407
bcdDevice: 0x0110
iManufacturer: 0x01
English (United States) "Mitsumi"
iProduct: 0x02
English (United States) "HID-compliant Mouse (USB)"
iSerialNumber: 0x00
bNumConfigurations: 0x01

===>Configuration Descriptor<===
bLength: 0x09
bDescriptorType: 0x02
wTotalLength: 0x0022 -> Validated
bNumInterfaces: 0x01
bConfigurationValue: 0x01
iConfiguration: 0x00
bmAttributes: 0xA0 -> Bus Powered
MaxPower: 0x32 = 100 mA

===>Interface Descriptor<===
bLength: 0x09
bDescriptorType: 0x04
bInterfaceNumber: 0x00
bAlternateSetting: 0x00
bNumEndpoints: 0x01
bInterfaceClass: 0x03 -> HID Interface Class
bInterfaceSubClass: 0x01
bInterfaceProtocol: 0x02
CAUTION: This may be an invalid bInterfaceProtocol
iInterface: 0x00

===>HID Descriptor<===
bLength: 0x09
bDescriptorType: 0x21
bcdHID: 0x0100
bCountryCode: 0x00
bNumDescriptors: 0x01
bDescriptorType: 0x22
wDescriptorLength: 0x0032

===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x81 -> Direction: IN - EndpointID: 1
bmAttributes: 0x03 -> Interrupt Transfer Type
wMaxPacketSize: 0x0003 = Invalid bus speed for USB Video Class
bInterval: 0x10
*******

You can get the 650 page USB2 standard here (top of the page, link to ZIP).
The "usb_20.pdf" document inside, almost 6MB, is the spec. It will
help a bit interpreting the fields.

http://www.usb.org/developers/docs/

In my mouse example above, the 0x03EE and 0x6407 information, would be
how a third-party driver would get loaded, in response to that USB
device being plugged in. So if you installed some mouse software,
the mouse software would load in response to matching on the idVendor
and idProduct. If those values were corrupted in transmission, then
there is no reason for the third-party driver to be consulted.

The "Caution" messages are probably a feature of UVCView, because the
program was intended for debugging USB Video Class devices (webcams?).
So things that don't look like video devices, or support typical
video device characteristics, may be the reason for some of the Caution
messages. Perhaps a copy of USBView would not have those messages.

Paul
.

Loading