Reply by Danish Ali June 8, 20072007-06-08
Yes that is what I meant you to try. Yes it would also
slow the PWM frequency. Sorry it didn't help.

Checking the User Manual I see things are more
complicated on the LPC2300 because you have
PCLKSEL to individually select clocks for each
peripheral.

Regards,
Danish
--- In l..., "bobtransformer" wrote:
>
> >>Does the behaviour change if you alter the division ratio between
> >>AHB and VPB i.e. VPBDIV?
>
> Hmmmmm. I DID try changing VPBDIV from 01 to 02 (Divide by 1 to
> Divide by 2) and it didn't fix it, however it did slow my PWM
> frequency down. Is this what you meant for me to try, Danish ??
>
> Thank you,
> boB

An Engineer's Guide to the LPC2100 Series

Reply by bobtransformer June 8, 20072007-06-08
>>Does the behaviour change if you alter the division ratio between
>>AHB and VPB i.e. VPBDIV?

Hmmmmm. I DID try changing VPBDIV from 01 to 02 (Divide by 1 to
Divide by 2) and it didn't fix it, however it did slow my PWM
frequency down. Is this what you meant for me to try, Danish ??

Thank you,
boB
--- In l..., "Danish Ali" wrote:
>
> 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
>
Reply by Danish Ali June 7, 20072007-06-07
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
Reply by jayasooriah June 7, 20072007-06-07
--- 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
Reply by bobtransformer June 7, 20072007-06-07
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
>
Reply by jayasooriah June 6, 20072007-06-06
--- 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
Reply by bobtransformer June 6, 20072007-06-06
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
>
Reply by jayasooriah June 6, 20072007-06-06
--- 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
Reply by bobtransformer June 6, 20072007-06-06
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
>
Reply by jayasooriah June 6, 20072007-06-06
--- 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