Lpc2000

Hello all,
I am new to this group and to the LPC chips in general.
I have been working on implementing an USB device using LPC2148. 

When the chip read in packets of data from the host PC, occasionally,
a byte goes missing. I checked the data packets over an USB analyzer,
and they appeared to be perfect. So the data got corrupted somewhere
between acknowledging the data packet and reading the data from the
USB endpoint RAM.

It might be of interest to you that I used a modified USB stack from
the virtual com port example from phillip's website. The example was
written for Keil, but it was ported to IAR workbench.

Sometimes the chip also hangs after writing a command to usb protocol
engine, when it waits for CCEMTY to be set.

anyone seen this before?

Eugene

Please check the update in the latest Keil's example
and use it as the reference. There were some problems
in CC_EMPTY and CD_FULL bit hanging issue in the older
Keil's example, and these bugs have been fixed already. 
But, the fixes have not been merged into the Virtual 
COM port driver yet.

Find out the differences between the two for now, we 
will update the Virtual COM port driver example shortly.

Philips app.



--- In lpc2000@yahoogroups.com, "y3peng" <eugene.peng@...> wrote:
>
> Hello all,
> I am new to this group and to the LPC chips in general.
> I have been working on implementing an USB device using LPC2148. 
> 
> When the chip read in packets of data from the host PC, 
occasionally,
> a byte goes missing. I checked the data packets over an USB 
analyzer,
> and they appeared to be perfect. So the data got corrupted 
somewhere
> between acknowledging the data packet and reading the data from the
> USB endpoint RAM.
> 
> It might be of interest to you that I used a modified USB stack 
from
> the virtual com port example from phillip's website. The example 
was
> written for Keil, but it was ported to IAR workbench.
> 
> Sometimes the chip also hangs after writing a command to usb 
protocol

> engine, when it waits for CCEMTY to be set.
> 
> anyone seen this before?
> 
> Eugene
>

Hello Eugene,

that might seem off topic but please try to increase the frequency to
the USB peripheral. 
There is a parameter in a SFR called VPBDIV and the default is set to
divide the CPU frequency by 4. Running at 48 MHz or 60 MHz this
results in 12 or 15 MHz clock for the USB perpheral which is connected
to the VPBBUS which is equivalent to the ARM APBBUS.

If not done so already please modify the VPBDIV to divide by 2 instead
of divide by 4. We have noticed some occasional problems going away
when we did this.

Hope this helps, Bob

--- In lpc2000@yahoogroups.com, "y3peng" <eugene.peng@...> wrote:

>
> Hello all,
> I am new to this group and to the LPC chips in general.
> I have been working on implementing an USB device using LPC2148. 
> 
> When the chip read in packets of data from the host PC, occasionally,
> a byte goes missing. I checked the data packets over an USB analyzer,
> and they appeared to be perfect. So the data got corrupted somewhere
> between acknowledging the data packet and reading the data from the
> USB endpoint RAM.
> 
> It might be of interest to you that I used a modified USB stack from
> the virtual com port example from phillip's website. The example was
> written for Keil, but it was ported to IAR workbench.
> 
> Sometimes the chip also hangs after writing a command to usb protocol
> engine, when it waits for CCEMTY to be set.
> 
> anyone seen this before?
> 
> Eugene
>

Hi Bob,

Sorry to butt in on this, but IMHO doing what you recommend is not a good 
thing.

Transient and/or intermittent problems are difficult to track down. Doing 
what you suggest for the reasons you suggest only serves embed the problem 
deeper in the scheme of things.

If one is interesting in fixing the problem at its source, I would not 
recommend changing anything without justification.

Hope you take the post in the right way.

Jaya

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@...> wrote:
 > If not done so already please modify the VPBDIV to divide by 2 instead
 > of divide by 4. We have noticed some occasional problems going away
 > when we did this.

Send instant messages to your online friends http://au.messenger.yahoo.com

Hi Eugene,

> Hello all,
> I am new to this group and to the LPC chips in general.
> I have been working on implementing an USB device using LPC2148.
> 
> When the chip read in packets of data from the host PC, occasionally,
> a byte goes missing. I checked the data packets over an USB analyzer,
> and they appeared to be perfect. So the data got corrupted somewhere
> between acknowledging the data packet and reading the data from the
> USB endpoint RAM.
> 
> It might be of interest to you that I used a modified USB stack from
> the virtual com port example from phillip's website. The example was
> written for Keil, but it was ported to IAR workbench.
> 
> Sometimes the chip also hangs after writing a command to usb protocol
> engine, when it waits for CCEMTY to be set.


Since you're working with IAR, be sure to take a look at the MSD example
project.  

It can be found here:
<install drive>\Program Files\IAR Systems\Embedded Workbench
4.0\arm\src\examples\Philips\LPC214x\MassStorage_USB_LPC2148

It is a major revision to IAR's HID example, and a good starting point for
writing LPC2148 device code. 


Joel

> Since you're working with IAR, be sure to take a look at the MSD example
> project.
> 
> It can be found here:
> <install drive>\Program Files\IAR Systems\Embedded Workbench
> 4.0\arm\src\examples\Philips\LPC214x\MassStorage_USB_LPC2148
> 
> It is a major revision to IAR's HID example, and a good starting point for
> writing LPC2148 device code.

I should have mentioned I've had my share of issue's with the Keil USB
stack.  I've ported all the Keil examples to IAR.  In comparison the IAR USB
stack is clean.

This is addressing the problem by the source. 
http://groups.yahoo.com/group/lpc2000/message/12923

Philips Apps

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Hi Bob,

> 
> Sorry to butt in on this, but IMHO doing what you recommend is not a
good 
> thing.
> 
> Transient and/or intermittent problems are difficult to track down.
Doing 
> what you suggest for the reasons you suggest only serves embed the
problem 
> deeper in the scheme of things.
> 
> If one is interesting in fixing the problem at its source, I would not 
> recommend changing anything without justification.
> 
> Hope you take the post in the right way.
> 
> Jaya
> 
> --- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@> wrote:
>  > If not done so already please modify the VPBDIV to divide by 2
instead
>  > of divide by 4. We have noticed some occasional problems going away
>  > when we did this.
> 
> Send instant messages to your online friends
http://au.messenger.yahoo.com
>

Message: 10        

      From: "Joel Winarske" <joelw@...>

<Subject: RE: scrambled data packet in LPC2148 usb buffer

 

> <I should have mentioned I've had my share of issue's with the Keil USB

<stack.  I've ported all the Keil examples to IAR.  In comparison the IAR
USB

stack is clean.<

 

Hi Can you send me the IAR ported Keil Examples.

 

Thanks 

 

Juval

 

 

 

 



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

Hi Juval,

> Hi Can you send me the IAR ported Keil Examples.

My customer paid for my time to do this, they own it.  So no, I cannot send
them to you.  The changes are ultimately semantics, as IAR is stricter than
Keil.

I would recommend you closely examine the IAR MSD example.  It integrates
DMA, and is much more thorough than the Keil code base.  Cleaner code too.

Joel