USB virtual com issue

[lpcware]

Content originally posted in LPCWare by pra18 on Fri Oct 17 05:56:28 MST 2014
Hi all,

When I do a single stepping of the CDC VCOM example  for LPCOpen 2_12 for ngx 4330 ,I see a USB device not recognised message in my PC and also there is an Unknown driver showing up in the  PC's Device manager's  USB controllers option  and the VID/PID both are shown as 0.

On the other hand if I remove all breakpointsand run the code, then a LPC USB VCOM COM4 is shown up in ports and LPT option in the Device manager.
also the VID PID shows up correctly.

Can anyone help and explain why this occurs ?
does it occur because there is a delay introduced when stepping ?

This appears to be the same on my custom board when I try to adapt and integrate this VCOM example into my custom firmware. I see this problem even when the firmware is running continously and there is an unknown device shoing up in the PC and unrecognised device.

Again here, from the time the firmware starts up and the time the USB is initialised , there are many things done for device firmware , and this adds to a delay ( as above case)

But when I remove the USB cable and connect it back this Unknown driver disappears and appears in the Device manager.

I have also attached my USB initialisation code so anyone can help if i am initilaising my USB1 correctly or not and I am missing some critical step in my USB1 initialisation
that might be causing the problem.

Thanks in advance,

Original Attachment has been moved to: USBInit.txt.zip

[lpcware]

Content originally posted in LPCWare by pra18 on Wed Oct 22 01:51:29 MST 2014
Hi,

I finally found that this Unknown Device can also come up if the USB clock configuration and initialisation is not correct and this was the case on my side.

I have corrected the clock initialisation sequence and now it seems to recognise the device and device comes up as a Virtual COM port on Device manager in the PC.

so my advice to anyone who face this kind of problem is that  apart from other things that can cause this problem , doubly make sure that you have intialised and configured the USB clock and PLL properly.

seems that this unknown device problem is of a multitude scope - right from  USB clocking and config not proper and upto any of the problems like things on the PC side, wrong .inf flle and so on ..

Thanks and Regards,

[lpcware]

Content originally posted in LPCWare by pra18 on Fri Oct 17 12:15:26 MST 2014
Hi,

Firstly thanks for trying to explain what might be happening in the firmware.

I am doing exactly the same sequence as the example and as you told I am invoking this connect API by the call USBD_API->hw->Connect(g_hUsb, 1) just after enabling the interrupts.

When I run the code without breakpoints , still I observe the unknown device coming  in device manager . I have observed that control is going into the ISR and everytime I disconnect the USB cable and reconnect back when firmare is running, upon disconnecting USB cable and reconnecting back , the control goes into the USB ISR and the Unknown device is getting installed into Device manager and gets uninstalled if I remove the cable respectively.

does it mean that there is too much  delay that is  interfereing from the point of firmware startup and the time USB is initialised and  the connect API  is invoked .

Any workaround for this thing and ovecome this problem?

The VCOM port somehow should show up in the ports and not as an unknown device.

I was first figuring  out it could be due to  a incorrect .INF file on Host side , I made sure it is not that thing and later I doubted whether USB initialisation is not proper.

Thanks in advance,

[lpcware]

Content originally posted in LPCWare by NXP_Paul on Fri Oct 17 08:09:59 MST 2014
Hello
The issue is probably caused by single-stepping.  When the USB host sends a control transfer, it expects a handshake.  If it doesn't receive the handshake, it will retry.  The host will typically abandon the transfer after three retries, and the enumeration will fail.

If you have a lot of initialization to do, then you can delay the USB enumeration process until you have completed the microcontroller's  initialization.  This can be accomplished by waiting for the initialization to complete before the 1.5kOhm pull-up resistor is enabled.  Enabling the 1.5k resistors tells the host that a USB device has been plugged into the USB port.  If the USB device is plugged in, but the resistor is not enabled, the host will not detect the device.  This pull-up is enabled when software sets the RS bit (Bit 0) in the USBCMD register.
In the LPCOpen code, the connection of the 1.5kOhm resistor is accomplished with the
USBD_API->hw->Connect(g_hUsb, 1) function.

Paul

[lpcware]

Content originally posted in LPCWare by capiman on Fri Oct 17 07:25:03 MST 2014
Yes, the PC has certain timeouts, when single stepping, the MCU is too slow or not answering on PC's requests.
Even when doing debug prints on an UART, it is sometimes too slow.
Solution could be to create an array, put debug strings into this array (which is fast, must be non-blocking)
and print out char by char when MCU just has nothing else to do. The reaction time for USB is then
not influenced or at least so less, that USB is still running.