V
VanguardLH
Guest
I have a USB device that doesn't initialize (become available) on
Windows startup but will init when I unplug and replug the device (and
into the same USB port). So it will work but with the hassle that I
have to unplug & replug it after a Windows restart.
Since the unplug and replug of the device triggers its init and
detection, I'm wondering if there is a utility that will do the same so
I can activate the USB device via software? This would need a command
line interface so I could have it run as a scheduled event and only for
that USB port (i.e., I or the utility would have to find the enumeration
for it under HKLM so that vendor ID device in that USB port got
initialized and no others).
I do have Microsoft's UVCview app to show the USB ports. There's one
that shows "FailedEnumeration: Unknown Device" after restarting Windows,
so I suspect that's the one for the device that doesn't init when
Windows starts. The status returned by the utility for that failed USB
enumeration is:
---===>Device Information<===---
ConnectionStatus: FailedEnumeration
Current Config Value: 0x00 -> Device Bus Speed: Low
Device Address: 0x00
Open Pipes: 0
*!*ERROR: No open pipes!
===>Device Descriptor<===
*!*ERROR: bLength of 0 incorrect, should be 18
bLength: 0x00
bDescriptorType: 0x00
bcdUSB: 0x0000
bDeviceClass: 0x00
*!*ERROR: Device enumeration failure
I also have their USBview utility which shows "DeviceFailedEnumeration"
status with the information:
Device Descriptor:
bcdUSB: 0x0000
bDeviceClass: 0x00
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x00 (0)
idVendor: 0x0000
idProduct: 0x0000
bcdDevice: 0x0000
iManufacturer: 0x00
iProduct: 0x00
iSerialNumber: 0x00
bNumConfigurations: 0x00
ConnectionStatus: DeviceFailedEnumeration
Current Config Value: 0x00
Device Bus Speed: Low
Device Address: 0x00
Open Pipes: 0
It doesn't matter to which USB port this device is moved. It almost
always fails to init when Windows loads. The device emulates two CD
drives, one with autorun.inf to auto-run an install or setup program if
the device is plugged in and the other is just a data drive (it's an ATA
adapter from TigerJet for VOIP).
These viewer apps show USB enumeration and device status. What I'd like
is a "kick in the pants" utility that will retry via software command to
init the device on that USB port. Obviously there is a hardware init
that occurs when I [unplug and] plug in the USB device. I'm wondering
if I can do that init via software.
There are only 4 pins in a USB port: VCC (5VDC), Data-, Data+, and GND
(ground). It is a differential bus hence the plus/minus designators for
the data inputs (I think this is for noise cancellation). So when the
device is plugged in, it seems it must send some commands to force its
detections and identify itself. Those comamnds would be sent on the
external interface between the controller chip and the port. I don't
know if similar commands can be sent to the internal interface of the
controller.
From what I see at the USB commands doc at
http://www.usb.org/developers/devclass_docs/usbmass-ufi10.pdf, you must
be able to send commands on the internal or host side of the controller.
Alas, that doc exceeds my ability to figure out a solution. I might be
able to cobble up a C program to issue the command but wouldn't know in
what order to issue those commands or how to handle their return codes.
Maybe all you need to send is the Send Diagnostic command which forces a
reset. Maybe I'm supposed to following with a Stop command (expected to
fail) followed by a Start command.
It is not an issue of overcurrent on the USB controller. The pair of
ports from a USB controller can have together a max of 500ma for draw.
Only 1 device is attached to one of the paired USB ports. The other
remains empty. The shared 500mA load is available in total to the one
device. Of course, if the device is faulty, it could be trying to draw
more than 500mA.
I tried using Device Manager to uninstall (delete) the "Unknown Device"
under a USB root hub and then do a hardware rescan. The device was
detected but again failed enumeration. So it might be an electrical
problem with the device that remains plugged in and powered on during
Windows startup that prevents it from being detected and that somehow
yanking it out and back in does something electrical that gets it
enumerated correctly. In that case, a software prod to send, say, a
reset or init command trying might won't work, but I'd like to try. It
may be that a software utility can't do anymore to prod the USB
controller to redetect the device than what I did in Device Manager.
There's a couple scenarios that I haven't tested yet. I have not yet
tested disabling power management (to NOT allow power-saving mode) on
the USB root hubs; however, the problem that I have is when I start
Windows so it hasn't gone into a power-saving mode yet (but is coming
out of one, sort of). Every test, so far, has been with a warm start to
see if the USB device shows up after Windows starts up. I will test
later to see if a cold start works okay (i.e.; if the USB device needs
to get powered off so when it powers on with the host then it'll be
ready for detection by Windows).
Windows startup but will init when I unplug and replug the device (and
into the same USB port). So it will work but with the hassle that I
have to unplug & replug it after a Windows restart.
Since the unplug and replug of the device triggers its init and
detection, I'm wondering if there is a utility that will do the same so
I can activate the USB device via software? This would need a command
line interface so I could have it run as a scheduled event and only for
that USB port (i.e., I or the utility would have to find the enumeration
for it under HKLM so that vendor ID device in that USB port got
initialized and no others).
I do have Microsoft's UVCview app to show the USB ports. There's one
that shows "FailedEnumeration: Unknown Device" after restarting Windows,
so I suspect that's the one for the device that doesn't init when
Windows starts. The status returned by the utility for that failed USB
enumeration is:
---===>Device Information<===---
ConnectionStatus: FailedEnumeration
Current Config Value: 0x00 -> Device Bus Speed: Low
Device Address: 0x00
Open Pipes: 0
*!*ERROR: No open pipes!
===>Device Descriptor<===
*!*ERROR: bLength of 0 incorrect, should be 18
bLength: 0x00
bDescriptorType: 0x00
bcdUSB: 0x0000
bDeviceClass: 0x00
*!*ERROR: Device enumeration failure
I also have their USBview utility which shows "DeviceFailedEnumeration"
status with the information:
Device Descriptor:
bcdUSB: 0x0000
bDeviceClass: 0x00
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x00 (0)
idVendor: 0x0000
idProduct: 0x0000
bcdDevice: 0x0000
iManufacturer: 0x00
iProduct: 0x00
iSerialNumber: 0x00
bNumConfigurations: 0x00
ConnectionStatus: DeviceFailedEnumeration
Current Config Value: 0x00
Device Bus Speed: Low
Device Address: 0x00
Open Pipes: 0
It doesn't matter to which USB port this device is moved. It almost
always fails to init when Windows loads. The device emulates two CD
drives, one with autorun.inf to auto-run an install or setup program if
the device is plugged in and the other is just a data drive (it's an ATA
adapter from TigerJet for VOIP).
These viewer apps show USB enumeration and device status. What I'd like
is a "kick in the pants" utility that will retry via software command to
init the device on that USB port. Obviously there is a hardware init
that occurs when I [unplug and] plug in the USB device. I'm wondering
if I can do that init via software.
There are only 4 pins in a USB port: VCC (5VDC), Data-, Data+, and GND
(ground). It is a differential bus hence the plus/minus designators for
the data inputs (I think this is for noise cancellation). So when the
device is plugged in, it seems it must send some commands to force its
detections and identify itself. Those comamnds would be sent on the
external interface between the controller chip and the port. I don't
know if similar commands can be sent to the internal interface of the
controller.
From what I see at the USB commands doc at
http://www.usb.org/developers/devclass_docs/usbmass-ufi10.pdf, you must
be able to send commands on the internal or host side of the controller.
Alas, that doc exceeds my ability to figure out a solution. I might be
able to cobble up a C program to issue the command but wouldn't know in
what order to issue those commands or how to handle their return codes.
Maybe all you need to send is the Send Diagnostic command which forces a
reset. Maybe I'm supposed to following with a Stop command (expected to
fail) followed by a Start command.
It is not an issue of overcurrent on the USB controller. The pair of
ports from a USB controller can have together a max of 500ma for draw.
Only 1 device is attached to one of the paired USB ports. The other
remains empty. The shared 500mA load is available in total to the one
device. Of course, if the device is faulty, it could be trying to draw
more than 500mA.
I tried using Device Manager to uninstall (delete) the "Unknown Device"
under a USB root hub and then do a hardware rescan. The device was
detected but again failed enumeration. So it might be an electrical
problem with the device that remains plugged in and powered on during
Windows startup that prevents it from being detected and that somehow
yanking it out and back in does something electrical that gets it
enumerated correctly. In that case, a software prod to send, say, a
reset or init command trying might won't work, but I'd like to try. It
may be that a software utility can't do anymore to prod the USB
controller to redetect the device than what I did in Device Manager.
There's a couple scenarios that I haven't tested yet. I have not yet
tested disabling power management (to NOT allow power-saving mode) on
the USB root hubs; however, the problem that I have is when I start
Windows so it hasn't gone into a power-saving mode yet (but is coming
out of one, sort of). Every test, so far, has been with a warm start to
see if the USB device shows up after Windows starts up. I will test
later to see if a cold start works okay (i.e.; if the USB device needs
to get powered off so when it powers on with the host then it'll be
ready for detection by Windows).