Hi, I am using the Keil sample code to implement the vitual COM communication on LPC2368.
The Communication works well when the hyperterminal is connected to the device.
When the device keeps transmitting ( device runs Ok) without connecting to hyperterminal, but after a while the device hangs waiting for ( while(CDC_DepInEmpty == 0);) to become true.
I am new to USB communication, Please guide me.
Sound like there are two problems behind the scene.
1) Notification from PC application to CDC device Windows CDC driver starts bulk IN transactions just after enumeration of the device, regardless of target PC application which hears from the COM port. Also, the PC driver still continues bulk IN transactions after the target PC application closes the COM port. If the CDC device would expect a listener PC application, the PC application should explicitly notify to the device about start/stop of listening.
DTR signaling is available for this purpose. On the PC application side, Hyperterminal asserts DTR to '1' when it opens a COM port, and it drops DTR to '0' at close of the COM port. You may need to asserts DTR explicitly on programming of your PC application (EscapeCommFunction(SETDTR) or SerialPort.DtrEnable). As CloseHandle() call to a COM port always drops DTR, you don't need to take care of it at close timing.
On the device side, DTR signaling is passed to device over Set_Control_Line_State request. Maybe, you are working on USBCDC example in this zip file?
Sample Code Bundle for LPC23xx/LPC24xx Peripherals using Keil's µVision V1.60 (Mar 10, 2009) ics.nxp.com/.../code.bundle.lpc23xx.lpc24xx.uvision.zip
This example decodes the request at CDC_SetControlLineState(), but its contents is empty. Fill it, for example,
cdciser.c /*---------------------------------------------------------------------------- CDC SetControlLineState Request Callback Called automatically on CDC SET_CONTROL_LINE_STATE Request Parameters: ControlSignalBitmap Return Value: TRUE - Success, FALSE - Error *---------------------------------------------------------------------------*/ volatile unsigned char CDC_open = 0; BOOL CDC_SetControlLineState (unsigned short wControlSignalBitmap) { /* ... add code to handle request */ #define CDC_DTR_MASK 0x01 if ( wControlSignalBitmap & CDC_DTR_MASK ) { // DTR is asserted CDC_open = 1; } else { // DTR drops CDC_open = 0; } return (TRUE); }
And then, your firmware refers to CDC_open flag, before accessing to bulk IN/OUT endpoints.
2) Unrecovered bulk IN transactions Unfortunately, Windows CDC driver has a weak point at error recovery on bulk IN transfer. USB hardware has intrinsic error detection and recovery mechanism on bulk endpoints. It retries last transaction up to three times, when it detects transaction error. But these retries occur without break, burst noise on the bus line often defeats all of these retry attempt of hardware. When retries fail, PC host controller notifies to the PC driver of the owner of the bulk endpoint. At this error, Windows CDC driver just stops bulk transfer silently, without recovering the endpoint.
The details is discussed here, www.microchip.com/.../m538194.aspx
Once the driver falls in this state, just unplug-replug (or soft-detach/attach) of the CDC device recovers the bulk IN communication.
Tsuneo