Lpc2000

Karsten Weiss ha scritto:

>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:
>  
>
A good idea when dealing with communications is to deal with 
disconnection/reconnection problem. This seems to be a very old lesson 
implemented also in tcp
that has a FSM to manage all communications phases.
Massimo Manca, Micron Engineering

>  
>
>>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
>>
>>
>>
>>
>>
>>
>>
>>
>> 
>>
>>    
>>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>


  ----------

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.16/225 - Release Date: 09/01/2006


[Non-text portions of this message have been removed]