Lpc2000

Hello Gregor,
this sounds familiar to me. First of all, you should check, if the 
problem is on the host or on the client side. I haven't worked with the 
LPC USB, yet, but with other USB to serial converters (namely CP2102 
from SiLabs and FT232 from FTDI), always with the same result. In my 
case, it seems to be a problem with the OS (Win2K and WinXP), but I 
haven't found any solution up to now. I have the theory, that the USB 
framework driver of the OS is disabling the device due to communication 
errors (the reason for them might be EMV problems). It depends on the 
implementation on the host side USB driver of your device, if it handles 
this correctly. I was able to reduce this disabling by filtering the USB 
data lines of my device properly (putting two small caps of 47p between 
D+ and GND resp. D- and GND directly at the USB connector on my board).

Karsten

gcopoix schrieb:

>Hi LPC group,
>
>I have an unnice problem regarding the LPC 214x USB communication:
>
>I've built a project based on the Keil MassStorage example.
>The only difference: I changed the descriptor to a non-class device, 
>setup 7in/7out pipes (I only use 2 BULK_IN and 1 BULK_OUT, needed 
>this amount of declared pipes for descriptor compatibility reasons).
>I've also added 1 timer interrupt, and 2 UART interrupts.
>
>1 BULK_IN and 1 BULK_OUT are used as command bulk pipes which are 
>used handshaked (means every command written is answered).
>
>In application level (non-interrupt driven, called by main loop) I 
>check if I received some data e.g. over UART. The UART is buffered by 
>a ringbuffer (ISR -> ringbuffer) and the application sends the 
>received data from ringbuffer->USB (calling USB_WriteEP()).
>
>Now the problem: This works OK for several hours, but then mostly in 
>WrCmd() after writing CMD_CODE the while-loop waiting for CCEMTY_INT 
>doesn't leave, resulting in a hanging USB communication.
>
>I've seen a hanging situation also in the USB ISR after setting 
>EP_INT_CLR and waiting for CDFULL_INT.
>
>I tried to disable the USB interrupt while calling USB_WriteEP() - 
>same result (may be a bit better, but can't say exactly).
>I also tried to send only within an USB interrupt (SOF irq), same 
>result too.
>
>So my questions:
>- Does anybody else have this problem ?
>- What can be the reason for a non-accepted CMD_CODE or a
>  non-accepted write to EP_INT_CLR ?
>- What to I need to take care of before calling USB_WriteEP() ?
>- Is it forbidden to send by application level ?
>- Is there a patch for the Keil USB stack ?
>- Is there some errata about this ?
>- What can I do to prevent this or what to resolve this situation ?
>
>Thank you for your help
>
>Gregor
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>