Forums

Speed Problem on LPC2300 & LPC2101/2/3

Started by nxp_marketing_usa June 5, 2007
We have identified a speed problem affecting the LPC2101/2/3 and the
LPC23xx series. This speed path interferes with instruction
fetches, limiting the operating frequency to approximately 60 MHz.
However, this issue is code and code-position dependent, which is
why the issue was not immediately apparent in testing . Many
customers' code executes at full speed without any issues. It has
been determined that the problem is eliminated in some programs with
slight modifications to the code, such as insertion of NOPs.

We are currently in the process of implementing a silicon fix, but
these new revision will not be available until Q3 2007. Users who
are experiencing a problem should either insert NOPs or limit their
clock speed until the code executes properly. An errata sheet will
be posted in the next day or two on
http://www.standardics.nxp.com/support/documents/microcontrollers/?
type=errata

NXP apologizes for any issues this may cause you and we are doing
everything possible to implement the silicon fix as soon as
possible.

An Engineer's Guide to the LPC2100 Series

I was going to post a question regarding the fact that some of
my code would not run unless I inserted one to 4 NOP's in
certain places. I am using the LPC2103 and LPC2144 but I have
had to insert NOPs for BOTH processors.

Are you sure that this might not be a problem in the
LPC214X series as well ????? I would LOVE to have this
be the answer instead of not knowing. I can live with this
work around temporarily.

It would be nice to know though, if there is a method to
know when I need to add the NOPs in my code if possible.
I am happy that NXP has at least posted this !!
Atmel would not openly own up to their ATmega32 silicon problems
which cost my last company more than $100,000 and at least
one year of frustration and lost time. This was a similar problem
except that there were no work arounds like with the NOPs. We had to
burn in uPs and change crystals etc. It was a pain in the ass
to say the least.

boB

--- In l..., "nxp_marketing_usa"
wrote:
>
> We have identified a speed problem affecting the LPC2101/2/3 and the
> LPC23xx series. This speed path interferes with instruction
> fetches, limiting the operating frequency to approximately 60 MHz.
> However, this issue is code and code-position dependent, which is
> why the issue was not immediately apparent in testing . Many
> customers' code executes at full speed without any issues. It has
> been determined that the problem is eliminated in some programs with
> slight modifications to the code, such as insertion of NOPs.
>
> We are currently in the process of implementing a silicon fix, but
> these new revision will not be available until Q3 2007. Users who
> are experiencing a problem should either insert NOPs or limit their
> clock speed until the code executes properly. An errata sheet will
> be posted in the next day or two on
> http://www.standardics.nxp.com/support/documents/microcontrollers/?
> type=errata
>
> NXP apologizes for any issues this may cause you and we are doing
> everything possible to implement the silicon fix as soon as
> possible.
>
--- In l..., "bobtransformer" wrote:

> I am happy that NXP has at least posted this !!
> Atmel would not openly own up to their ATmega32 silicon problems
> which cost my last company more than $100,000 and at least
> one year of frustration and lost time. This was a similar problem
> except that there were no work arounds like with the NOPs. We had to
> burn in uPs and change crystals etc. It was a pain in the ass
> to say the least.

Bob,

Note that NXP has yet to admit to this problem in the original thread
where IMHO Brunce painstakingly and convincingly demonstrated (at last
to me) that there is a problem to be looked into.

Be it NXP or Atmel, it is quite common for them not to own up to a
defect (i.e. publish an errata) when it is convenient to do so, for
example, if not enough consumers know or are affected by the defect,
and especially if this defect has been fixed in subsequent silicon
revisions.

NXP denial of defects in CRP implementation is another case in point.
No doubt the situation will change when the methods to exploit these
defects become sufficiently well known.

Jaya
Jaya, where is that original thread you speak of ??

I believe that my LPC2144 has this same problem and I have
notified my local NXP FAE who is looking into this. I trust
him to follow through best he can.

How I found out that NOPs fixed these problems was that part
of my early code would not work until I moved the code around
in the function I was having a problem with, which then made
me "try" a nop or series of nops at the beginning of the function.
After that, I have had about 2 other instances where NOPs added
would make it work again.

I can't see how this would be a different problem than what was
just posted yesterday by NXP.

Atmel said I was the first to find their silicon bug in north
america, so maybe I'm the first to find this one on the LPC214X ?

I'd like to see Brunce's thread. Maybe it is the same thing, but
if so, I'll be breaking my winning streak !!

boB

--- In l..., "jayasooriah" wrote:
>
> --- In l..., "bobtransformer" wrote:
>
> > I am happy that NXP has at least posted this !!
> > Atmel would not openly own up to their ATmega32 silicon problems
> > which cost my last company more than $100,000 and at least
> > one year of frustration and lost time. This was a similar problem
> > except that there were no work arounds like with the NOPs. We had to
> > burn in uPs and change crystals etc. It was a pain in the ass
> > to say the least.
>
> Bob,
>
> Note that NXP has yet to admit to this problem in the original thread
> where IMHO Brunce painstakingly and convincingly demonstrated (at last
> to me) that there is a problem to be looked into.
>
> Be it NXP or Atmel, it is quite common for them not to own up to a
> defect (i.e. publish an errata) when it is convenient to do so, for
> example, if not enough consumers know or are affected by the defect,
> and especially if this defect has been fixed in subsequent silicon
> revisions.
>
> NXP denial of defects in CRP implementation is another case in point.
> No doubt the situation will change when the methods to exploit these
> defects become sufficiently well known.
>
> Jaya
>
--- In l..., "bobtransformer" wrote:

> Jaya, where is that original thread you speak of ??

Hi Bob,

I was thinking of:

http://tech.groups.yahoo.com/group/lpc2000/message/25254

Regards,

Jaya
AHA !! I had no idea these problems were related.
Tonight, I will try changing MAMCR from 2 to 1 and
see if THAT fixes this problem ! I bet it does !
We'll see..

Thank you very much, Jaya and Bryce.

boB

--- In l..., "jayasooriah" wrote:
>
> --- In l..., "bobtransformer" wrote:
>
> > Jaya, where is that original thread you speak of ??
>
> Hi Bob,
>
> I was thinking of:
>
> http://tech.groups.yahoo.com/group/lpc2000/message/25254
>
> Regards,
>
> Jaya
>
--- In l..., "bobtransformer" wrote:
> AHA !! I had no idea these problems were related.
> Tonight, I will try changing MAMCR from 2 to 1 and
> see if THAT fixes this problem ! I bet it does !
> We'll see..
>
> Thank you very much, Jaya and Bryce.
>
> boB
>

Aplogies to Bryce -- I just realised I how wrongly I spelt his name!

I would be very interested in the outcome of your experiment.

It would help explain a number of anomalies I attributed to MAM, and
my suspicion that NXP appears to be moving away from Philip's MAM (and
CRP) in their more recent LPC variants.

Jaya
OK, Changing MAMCR to 1 did not fix it. Changing the PLL
from 12 MHz X 5 to 12MHz X 4 did not fix it either. I will try to
explain sortof what I'm doing in my main() while(1) loop which is
where I have to add the NOP. My board has some pots and LEDs and
RS232 interface etc. I am reading A/D channels, one of which is a
TrimPOT, and I am shoving the A/D result into a INT called PWM which
is changed in my timer interrupt as well as where the A/D is managed.
Here is the simplest form of my code in the while loop...

while(1) { //while loop in main
asm("nop"); //Adding this one line fixes my PWM problem
PWM = AD1CH.absorbPot;
}

Now, my PWM works just fine with the NOP added either at beginning or
the end.

Normally, this while loop has a bunch of other code, such as LEDs etc
(using a Second counter also in timer int), UART output of Voltage
from A/D channels etc. They seem to work fine. Just the A/D to PWM
doesn't work without the NOP. If all that other code is in this while
loop, it does not change the fact that I need to add that NOP. I can
put the NOP anywhere in the code, inbetween the UART output and LEDs
blinking or whatever, and it fixes the PWM. I can turn the pot and
the PWM changes as it should. Also, I can add as many or few NOPs in
there as I want. It must have at least one NOP, anywhere to make the
PWM take the A/D value. Now I am going to go look at the output
listing and see if optimization changes do anything as well. IAR,
LPC2144 and J-Link.

Any ideas gladly looked into.
Thanks,
boB
--- In l..., "jayasooriah" wrote:
>
> --- In l..., "bobtransformer" wrote:
> >
> >
> > AHA !! I had no idea these problems were related.
> > Tonight, I will try changing MAMCR from 2 to 1 and
> > see if THAT fixes this problem ! I bet it does !
> > We'll see..
> >
> > Thank you very much, Jaya and Bryce.
> >
> > boB
> > Aplogies to Bryce -- I just realised I how wrongly I spelt his name!
>
> I would be very interested in the outcome of your experiment.
>
> It would help explain a number of anomalies I attributed to MAM, and
> my suspicion that NXP appears to be moving away from Philip's MAM (and
> CRP) in their more recent LPC variants.
>
> Jaya
>
--- In l..., "bobtransformer" wrote:
>
> Now, my PWM works just fine with the NOP added either at beginning or
> the end.
>
> Normally, this while loop has a bunch of other code, such as LEDs etc
> (using a Second counter also in timer int), UART output of Voltage
> from A/D channels etc. They seem to work fine. Just the A/D to PWM
> doesn't work without the NOP. If all that other code is in this while
> loop, it does not change the fact that I need to add that NOP. I can
> put the NOP anywhere in the code, inbetween the UART output and LEDs
> blinking or whatever, and it fixes the PWM. I can turn the pot and
> the PWM changes as it should. Also, I can add as many or few NOPs in
> there as I want. It must have at least one NOP, anywhere to make the
> PWM take the A/D value. Now I am going to go look at the output
> listing and see if optimization changes do anything as well. IAR,
> LPC2144 and J-Link.
>
> Any ideas gladly looked into.
> Thanks,
> boB

Bob

This looks to me more like a code generation problem. Sorry I missed
this out in the thread, but have you checked the assembler code with
and without the NOP?

Jaya
Pure speculation here, but it sounds to me like an
issue with the AHB to VPB bridge.
The processor (on the AHB) alternates reading and
writing to devices on the VPB.

Maybe the reads get priority (because they would
stall the processor) and somehow the system
never gets round to doing the write to the PWM
because the next read has come round (unless you
put in a NOP to delay things). The AHB-to-VPB
bridge might be too clever in that it sees that
the next-time-round-the-loop write is to the same
address, and somehow assume that it is ok to lose
the older write.
I seem to remember (on discussions of non-fast GPIO
ports, also on the VPB) that you had to issue two
consecutive writes to the VPB to be certain that
the first one had taken.

How might you test this theory? Does the behaviour
change if you alter the division ratio between
AHB and VPB i.e. VPBDIV?

Hope this helps,
Danish

--- In l..., "bobtransformer" wrote:
>
> OK, Changing MAMCR to 1 did not fix it. Changing the PLL
> from 12 MHz X 5 to 12MHz X 4 did not fix it either. I will try to
> explain sortof what I'm doing in my main() while(1) loop which is
> where I have to add the NOP. My board has some pots and LEDs and
> RS232 interface etc. I am reading A/D channels, one of which is a
> TrimPOT, and I am shoving the A/D result into a INT called PWM which
> is changed in my timer interrupt as well as where the A/D is managed.
> Here is the simplest form of my code in the while loop...
>
> while(1) { //while loop in main
> asm("nop"); //Adding this one line fixes my PWM problem
> PWM = AD1CH.absorbPot;
> }
>
> Now, my PWM works just fine with the NOP added either at beginning or
> the end.
>
> Normally, this while loop has a bunch of other code, such as LEDs etc
> (using a Second counter also in timer int), UART output of Voltage
> from A/D channels etc. They seem to work fine. Just the A/D to PWM
> doesn't work without the NOP. If all that other code is in this while
> loop, it does not change the fact that I need to add that NOP. I can
> put the NOP anywhere in the code, inbetween the UART output and LEDs
> blinking or whatever, and it fixes the PWM. I can turn the pot and
> the PWM changes as it should. Also, I can add as many or few NOPs in
> there as I want. It must have at least one NOP, anywhere to make the
> PWM take the A/D value. Now I am going to go look at the output
> listing and see if optimization changes do anything as well. IAR,
> LPC2144 and J-Link.
>
> Any ideas gladly looked into.
> Thanks,
> boB