Hello All,
This forum was suggested as a good place to post this issue.
We have used the Microchip PIC18F87J50 part to implement a USB to serial interface to Windows on our embedded system, but have found that the device will sometimes not connect upon insert, that is the COM to USB driver will return an error within Windows as the COM device is connecting, and the USB connector has to be pulled back out and reinserted into the PC or the device at the other end, where it eventually connects to the COM port without error. What we’re seeing keeps pointing to possible errors or shortcomings in the Windows XP USB/serial driver, so a possible fix to this lies in developing our own driver to handle the USB traffic on Windows, to trap and respond properly to this condition. It does this as well on Windows 7.
I have downloaded and installed the latest WDK and see both serial drivers and USB drivers in the samples, but not something that connects one to the other. I have a number of questions:
What’s the right way to connect the serial and USB samples to make something that would support this?
What Windows components are used to make this work as it does now without a custom driver? A pointer to a good reference, either textbook or web site, would be helpful.
How can I determine whether the fault lies in the parts of Windows that support this or in the device timing, or a combination of the two? Has anyone out there seen this with other USB to serial devices?
BTW I’ve written drivers before, but this was back in 1996 and it was a WAV driver for 95/98, so a lot of this is new to me.
This forum was suggested as a good place to post this issue.
That was good advice.
We have used the Microchip PIC18F87J50 part to implement a USB to serial interface to Windows on our embedded system, but have found that the device will sometimes not connect upon insert, that is the COM to USB driver will return an error within Windows as the COM device is connecting, and the USB connector has to be pulled back out and reinserted into the PC or the device at the other end, where it eventually connects to the COM port without error. What we’re seeing keeps pointing to possible errors or shortcomings in the Windows XP USB/serial driver, so a possible fix to this lies in developing our own driver to handle the USB traffic on Windows, to trap and respond properly to this condition.
Can you tell us what leads you to think the flaw is in usbser.sys? I’m
not saying you’re wrong – others have complained about usbser.sys
before, although not for this specific reason. I would just like to
know what you have tried so far. Have you hooked up a USB analyzer
(either software or hardware) so you can watch the packets and see how
far it gets before it dies? What error, exactly, do you see?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I’m not sure if an USB analyzer has been used. Do you have a software based one you would recommend?
I’ve had good luck with the HHD Software monitor (hhdsoftware.com),
although it’s not free.
However, a hardware analyzer is almost always a more useful tool, and
because you are using a slower speed device, a hardware analyzer would
be quite affordable. The Beagle analyzer, for instance, is only $400.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
If it fails any of the relevant tests you’ll need to fix the hardware before
proceeding to software…
Mike
>>>----- Original Message -----
From: xxxxx@yahoo.com
To: Windows System Software Devs Interest List
Sent: Tuesday, November 30, 2010 10:07 PM
Subject: [ntdev] USB connection failure
Hello All,
This forum was suggested as a good place to post this issue.
We have used the Microchip PIC18F87J50 part to implement a USB to serial
interface to Windows on our embedded system, but have found that the device
will sometimes not connect upon insert, that is the COM to USB driver will
return an error within Windows as the COM device is connecting, and the USB
connector has to be pulled back out and reinserted into the PC or the device
at the other end, where it eventually connects to the COM port without
error. What we’re seeing keeps pointing to possible errors or shortcomings
in the Windows XP USB/serial driver, so a possible fix to this lies in
developing our own driver to handle the USB traffic on Windows, to trap and
respond properly to this condition. It does this as well on Windows 7.
I have downloaded and installed the latest WDK and see both serial drivers
and USB drivers in the samples, but not something that connects one to the
other. I have a number of questions:
What’s the right way to connect the serial and USB samples to make
something that would support this?
What Windows components are used to make this work as it does now without
a custom driver? A pointer to a good reference, either textbook or web site,
would be helpful.
How can I determine whether the fault lies in the parts of Windows that
support this or in the device timing, or a combination of the two? Has
anyone out there seen this with other USB to serial devices?
BTW I’ve written drivers before, but this was back in 1996 and it was a WAV
driver for 95/98, so a lot of this is new to me.
Hi again, I tried the command verifier, but for some reason it kept looking for device 29 and 26, function 7. A freeware app called usbdeview says that the RS-232 emulator is at hub 3, port 1. I may be unclear on some USB concepts here, should I be able to select the device to verify?
HHD lets you evaluate their software for 14 days, so that was useful, thanks for the recommendation. When the device connects successfully it will send packets, get a PnP Device Disconnected or sometimes a PnP Device Surprise Removal when the cable is removed. Most times the packets resume with a PnP Device Connected when the cable is reinserted. In the cases where the comm error occurs, the last line in the log is PnP Device Disconnected, preceded by URB_FUNCTION_ABORT_PIPE, and no more packets. Oddly enough USBDEview thinks that the device is connected in this state. Could this be usbser finding itself in a hung state somehow?
In the cases where the comm error occurs, the last line
in the log is PnP Device Disconnected, preceded by
URB_FUNCTION_ABORT_PIPE, and no more packets.
Oddly enough USBDEview thinks that the device is
connected in this state. Could this be usbser finding
itself in a hung state somehow?
No, this sounds to me like your device is generating bus errors and the host is punting it. I’d get or borrow an analyzer and capture the appropriate trace.
More info, it looks like the embedded code is running okay, there’s a couple of indicator outputs to parallel port pins that look the same whether there’s an error or not, of course it could have missed some stage of the enumeration process. Even weirder is that when running the USBTrace analyzer, when recording the error seems to happen more often.
