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...
Hello John, Hello Tsuneo,
at first I want to thank you both for your reply too and give answers to your questions:
John Linq wrote:
1. Did you modify the KEIL CDC example to fit your need? You need to make sure that your modification is bug free and proper.
Yes, we modified the CDC example provieded by KEIL. I have access to our firmware source code, so we could have a look at it. Some background information: Unfortunately my supervisor created nearly the whole firmware by himself. That's why I have some problem to give you detailed information about the changes in CDC example at the moment. Another problem is, that my supervisor is not able to communicate in english. Bad conditions to find a problem in firmware, I know... It's my turn to find a solution now! Questions: Wich modifications in CDC example should I ask my supervisor for/ should I look for? What parts of the CDC example are related to the initialization / installation process of the usb connection? I am able to understand the firmware, because i write controller programs too.
2. Read the below link first: http://www.keil.com/forum/docs/thread14325.asp Tsuneo Chinzei's replies should be very helpful.
I read the link again (read it yesterday before starting the thread here too), but I can't read out clearly, where to search our problem. Our problem is, that in some cases the XP installation assistent fails and the vcom driver is not installed after the installation failure. I'll try to find a PC here on wich the installation fails and then describe exactly what happened.
Tsuneo Chinzei wrote:
Is your LPC2368 supplied just from USB (bus-powered), or it has local power supply (self-powered)?
Our LPC2368 is supplied by a local power supply. Interesting to read, that the CDC example is for bus-powered devices. Wich parts of CDC example should be modified for bug free usage with a local power supply? I could post our source partially, if you tell me wich parts are of interest.
Looking forward to find the problem.
I just remembered another fact wich maybe is important to solve the problem: Often the Microsoft WindowsXP installation assistent failed to install the virtual serial connection on laptops. Don't know if this matters... I even tried to install the virtual serial connection on 3 different XP-PCs, where the connection never has been installed in the past. No problem occured - the installation assistent finished successful. (should I be happy?) Unfortunately I actually have no laptop available, on wich the installation failed in the past. :(
> Our LPC2368 is supplied by a local power supply.
For self-powered device, the device has to detect "physical" connection to a host USB port at the VBUS pin (5V supply) of the device USB connector. It is required to suppress spurious USB interrupts on the firmware. Also, you may add code to power down the USB engine and PLL, for low-power consumption of battery-powered devices.
For LPC2368, VBUS pin (P1.30) is assigned for this purpose. On the schematic of KEIL MCB2300 board, http://www.keil.com/mcb2300/mcb2300-schematics.pdf
On the right side of the second sheet of the schematic, you'll see USB B-type connector. Pin 1 (VBUS) of the connector is tied to P1.30 over these components, R73 (220k) - weak pull-down to GND R71 (4k7) - protection You may add a small bypass capacitor (0.1uF ceramic), if your board doesn't have any capacitor on VBUS line.
Another hardware issue is D+ pull-up control by the LPC2368. On the same schematic of KEIL board, just under the USB connector, you'll see this circuitry,
Pin 3 (D+) of the USB connector - R3 (1k5) - Q1 (PMBTA92 PNP Transistor) collector R7 (10k) - Q1 Base - R6 (2k2) - P2.9 (USB_CONNECT) of LPC2368
Does your board have these circuitry ?
Tsuneo
I checked out our schematics with a workmate who is responsible for hardware layouts with the result, that we have these circuits on our board. What we don't have, is a bypass capacitor on VBUS line, but there's no urgent need to have it, right?
After checking the hardware, now we must check the firmware?
> I checked out our schematics with a workmate who is responsible for hardware layouts with the result, that we have these circuits on our board.
Fine.
Before moving to firmware, check the chip revision. The initial device revision of LPC2368 has silicon bugs on the above USB related pins. This bug had been fixed since the second (A) revision.
Errata sheet LPC2368 ics.nxp.com/.../errata.lpc2368.pdf
As the current revision is "D", the forth one, I suppose your boards would not mount this old revision. But to make it sure, check the revision.
Tsuneo Chinzei wrote
[...] check the revision.
I checked one of our first devices: It has revision identifier B - it's the third revision and shouldn't have any functional usb problems.
As Tsuneo points out, you should review ALL the revision notes on all the chips from Step 'A' to Step 'D' devices for information that might be revelant to your problem. Personally, I beleive that you have power problems on your target board. Laptop computers are very bad about marginal USB power. Bradford
Maybe you are starting with the KEIL example on this folder, installed by MDK-ARM C:\Keil\ARM\Boards\Keil\MCB2300\USBCDC
This example supposes bus-powered device. For bus-powered device, USB engine (SIE) and USB interrupt are initialized just once on the device power-up, like this excerpt from the example. Also, USB_Connect(), which enables D+ pull-up, is called just once. The connection is maintained until the device power off. The firmware doesn't care of plug-off of USB cable, because it powers down the chip.
vcomdemo.c // initialization for bus powered device int main (void) { ... ... // initialization of other peripheral and variables ... USB_Init(); /* USB Initialization */ USB_Connect(__TRUE); /* USB Connect */ while (!USB_Configuration) ; /* wait until USB is configured */ while (1) { /* Loop forever */ VCOM_Serial2Usb(); /* read serial port and initiate USB event */ VCOM_CheckSerialState(); VCOM_Usb2Serial(); } }
On your board, the LPC23368 VBUS pin (P1.30) is connected to the VBUS pin of the USB port. Also, VBUS monitor function is enabled on PINSEL3 (the example sets up this function). In this setting, the USB engine drops USB connection automatically by disabling D+ pull-up through USB_CONNECT pin (P2.9), if VBUS pin doesn't see 5V. When 5V appears to the pin, however, the engine doesn't enable the pull-up automatically. The firmware should enable the pull-up for connection by calling USB_Connect(__TRUE); again.
That is, your firmware successfully connects just when the device powers up after the USB cable is plugged in to the PC. When the order is reversed, it doesn't connect any more, unless power cycle of the device occurs. Confirm it on your side. For self-powered device, the firmware has to watch the physical connection at VBUS pin. When it detects USB plug connection, it initializes/enables USB engine and USB interrupt. On disconnection, it disables engine and interrupt.
There are several options a) VBUS watch: interrupt or polling b) Power down SIE and PLL for low-power, or not It's midnight here. I'll continue next morning. Good night.
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.
Al Bradford
[...]you should review ALL the revision notes on all the chips from Step 'A' to Step 'D' devices[...]
I don't understand - why should I have a look at revision notes on revisions we do not use? Do you make a difference between revison notes and errata sheet? For revision 'B' (third revision - the first revision we use) the following problems are listed in the link given by Tsuneo (the actual errata sheet for LPC2368 from 01 April 2010): Ethernet.4, Core.1, CAN.1, Deep power-down.1, VBAT.1, VBAT.2 and Note.1 . None of these points seems relevant to me. Do you think of a special note that could be relevant?
[...]I beleive that you have power problems [...]. Laptop computers are very bad about marginal USB power.
If there is a power problem, I will have to find it - thank you for your assessment.
RoS
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.
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.