We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello everyone,
we're using a NXP LPC2368 in a project, that includes connection to a PC via USB (virtual serial connection). When connecting the LPC2368 to a WindowsXP-PC for the first time, a hardware configuration assistent starts. Following this assistent, the user must specify the path to the file 'mcb2300-vcom.inf' that is originally provided with the uVision IDE. This file contains information for installing the correct usb driver for the virtual serial connection. WindowsXP uses a generic driver file 'usbser.sys' to make the USB connection to the LPC2368 work. As we know now, the usbser.sys should have a newer version number, for example 5.1.2600.xxxx. A stable working version of the file is provided by ServicePack3 for WindowsXP.
Here's the problem: On MANY WindowsXP-PCs the hardware configuration manager fails and its not possible to establish the virtual serieal connection. But all the PCs have ServicePack3 installed and consequently an actual version of the usbser.sys generic driver file. We suppose that there's a problem with various usb host controllers used on mainboards, but we can't dictate our customers to use a special hardware in their PCs.
Is it possible that some usb host controllers on mainboards cannot work with LPC2368 in vCOM-Mode? Has anyone ideas to definitely locate and maybe solve the problem? We can't test hundreds of different hardware configurations in PCs...
I'm looking forward to your answers...
It seems the OP has never seen how the USB device fails. This is not good.
1. It always works fine, when the WinXP is running, you connect the USB device to WinXP, and then power up the USB device.
2. It always fails, when the WinXP is running, and the USB device is powered up, then you connect the USB device to WinXP.
3. It always fails, when the USB device is powered up and connected to the X86 PC, then you power up the X86 PC.
John Linq
It seems the OP has never seen how the USB device fails. This is not good. 1. It always works fine, when the WinXP is running, you connect the USB device to WinXP, and then power up the USB device. 2. It always fails, when the WinXP is running, and the USB device is powered up, then you connect the USB device to WinXP. 3. It always fails, when the USB device is powered up and connected to the X86 PC, then you power up the X86 PC.
I don't know what you want to say with this comment. The normal operation is as follows: The device and the PC have to be powered up at first. If the device or PC are not powered up, they should not be plugged together. After powering up, the physical connection between device and PC can be established. Then, if the connection never was established before, on Microsoft WindowsXP the hardware installation assistent should start. In real tests, after executing the described steps, the assistent sometimes fails. In failure cases on PC the following conditions can be found: usbser.sys is located in ../system32 folder, device and PC are powered up, physical connection is established. The failure mostly occurs on laptops.
Do you want to know if any of the cases you mentioned are true?
Case 1 is not intended and not provided.
Case 2 is false - mainly this case works. Sometimes (mostly on laptops), the installation assistent fails after first connection. If the assistent has finished successful, the device connection never has failed in past.
Case 3 is not intended and not provided.
I hope I understood the properly meaning of your post.
RoS
Hi Robert,
Sorry for the very short and unclear post.
=> Do you want to know if any of the cases you mentioned are true? <=
Yes, I would like to know more about the faulty scenario.
I think that, you performed some tests by yourself, but did you really reproduce such a problem?
Because you said that, "the failure mostly occurs on laptops", and "Unfortunately I actually have no laptop available".
Is there a reason why you put extra limitations on USB?
"If the device or PC are not powered up, they should not be plugged together."
A normal user of USB equipment does not want someone to tell them if they have to turn on switch A before switch B because they intend A and B to communicate using USB.
Here's the problem: [...] the hardware configuration manager fails and its not possible to establish the virtual serieal connection.
In real tests, after executing the described steps, the assistent sometimes fails.
So, the problem is that, the hardware configuration manager reports that, "Found NO new hardware!";
or the hardware configuration manager just crashes?
> The normal operation is as follows: The device and the PC have to be powered up at first. If the device or PC are not powered up, they should not be plugged together. After powering up, the physical connection between device and PC can be established.
For this operation, you have to choose bus-powered, instead of self-powered. If the peripherals require more than 100mA (or 500mA), make just the MCU bus-powered. And then, MCU enables a regulator which feeds from local supply to the peripherals of heavy load. When the MCU powers down, the regulator cuts off by pull-down attached to the enable pin.
> So, the problem is that, the hardware configuration manager reports that, "Found NO new hardware!"; or the hardware configuration manager just crashes?
When the device behaves unexpectedly, Windows also responds unpredictably. If you want to see solid evidence, monitor the USB line with a hardware bus analyzer.
Anyway, if you don't like to modify your board so much, sort out the firmware for self-powered. Do you want to hear more about self-powered fimware configuration? If not, I'll post it elsewhere.
Tsuneo