2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

I would like to organize a cooperative investigation of the issues
that several users are experiencing with the lpc23xx parts' MAM. I've
directly emailed those users on this list that have previously
reported MAM problems.

First, I'd like to make it clear that I have no interest in
NXP-bashing. They make a great product, and we believe they continue
to have the best solution to an entire class of our product needs.

Our primary goal is to identify a simple test case that can be
reproduced on various users' configurations. Previous comments
indicate that the problem is limited to certain parts, which my
experience also suggests. Once we have identified a simple test case,
and examined it for any possible bugs, all interested users can try it
out on their systems, both those that do and do not seem vulnerable to
this issue.

To Edwin Olson: In the message here (
http://tech.groups.yahoo.com/group/lpc2000/message/23611 ), you
suggested that you had a simple test case. It would be extremely
valuable as a starting point for this investigation. Please consider
uploading it to the files area of this group. Also, to Ryan Niemi: you
mentioned having this problem. Do you have a simple test case? I will
also look into trying to trim down a simple test case on our "problem
board", but if anyone else has one ready and available, please speak
up!

Our secondary goal is to pressure NXP to release an official errata
ASAP, *if* they have known issues, as some have suggested. I have
received personal confirmation that a new revision of silicon is in
the works, but no details on what the differences or fixes in the
revision are. The cost of engineering time of any delay in public
acknowledgment of problems like these is very, very high, especially
to the typical (to my estimation) lpc2xxx customer - small engineering
houses.

To Sashi Ono: In the message here (
http://tech.groups.yahoo.com/group/lpc2000/message/24166 ), you
suggested that you had direct contact with NXP representatives: "they
reported to me that they have found the problem and have already re
spun a new batch of silicon," confirming the existence of a known
problem that has not yet been publicly acknowledged. Can you verify
this assertion? If this is true, can you exert any pressure on your
NXP contacts to publicly acknowledge this issue?

Thank you all for your collaboration,
--
Bryce Schober



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I would like to organize a cooperative investigation of the issues
>that several users are experiencing with the lpc23xx parts' MAM. I've
>directly emailed those users on this list that have previously
>reported MAM problems.
>
>First, I'd like to make it clear that I have no interest in
>NXP-bashing. They make a great product, and we believe they continue
>to have the best solution to an entire class of our product needs.
>
>Our primary goal is to identify a simple test case that can be
>reproduced on various users' configurations. Previous comments
>indicate that the problem is limited to certain parts, which my
>experience also suggests. Once we have identified a simple test case,
>and examined it for any possible bugs, all interested users can try it
>out on their systems, both those that do and do not seem vulnerable to
>this issue.
>
>To Edwin Olson: In the message here (
>http://tech.groups.yahoo.com/group/lpc2000/message/23611 ), you
>suggested that you had a simple test case. It would be extremely
>valuable as a starting point for this investigation. Please consider
>uploading it to the files area of this group. Also, to Ryan Niemi: you
>mentioned having this problem. Do you have a simple test case? I will
>also look into trying to trim down a simple test case on our "problem
>board", but if anyone else has one ready and available, please speak
>up!
>
>Our secondary goal is to pressure NXP to release an official errata
>ASAP, *if* they have known issues, as some have suggested. I have
>received personal confirmation that a new revision of silicon is in
>the works, but no details on what the differences or fixes in the
>revision are. The cost of engineering time of any delay in public
>acknowledgment of problems like these is very, very high, especially
>to the typical (to my estimation) lpc2xxx customer - small engineering
>houses.
>
>To Sashi Ono: In the message here (
>http://tech.groups.yahoo.com/group/lpc2000/message/24166 ), you
>suggested that you had direct contact with NXP representatives: "they
>reported to me that they have found the problem and have already re
>spun a new batch of silicon," confirming the existence of a known
>problem that has not yet been publicly acknowledged. Can you verify
>this assertion? If this is true, can you exert any pressure on your
>NXP contacts to publicly acknowledge this issue?
>
>Thank you all for your collaboration,
>--
>Bryce Schober

I emailed NXP regarding this issue, this is their reply:

---------------------------------------------------------------------------
NXP Semiconductors answer:
We have not been able to confirm any issue with the MAM and >48MHz operation. There is a confirmed errata limiting the output range of the PLL to between 275-290MHz. If you enable the PLL and set it to anything outside of that range all bets are off on what will fail. This errata will be fixed in the next revision.

-Dave
---------------------------------------------------------------------------

I'm in the process of selecting a uC for my project, the LPC2378 looks like a nice chip but this MAM issue makes it a difficult choice. Whom to believe, the several competent sounding posters who reported this problem or NXP? Could it be that both are right--that this problem affects only a small percentage of chips, and NXP hasn't been able to catch the problem.

Is there anyone out there who has been able to successfuly run an LPC23xx @72Mhz with a program of >32k size in Flash?

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, marioml@... wrote:

>
> I'm in the process of selecting a uC for my project, the LPC2378
looks like a nice chip but this MAM issue makes it a difficult choice.
Whom to believe, the several competent sounding posters who reported
this problem or NXP? Could it be that both are right--that this
problem affects only a small percentage of chips, and NXP hasn't been
able to catch the problem.
>
> Is there anyone out there who has been able to successfuly run an
LPC23xx @72Mhz with a program of >32k size in Flash?
>

I have application with LPC2378 @72MHz and (running make . . . ) ca.
240KB of code (debug mode). I have just one chip so I can't tell if
I'm just lucky. Main crystal is 12MHz. MAM is fully enabled (2) and 4
fetch cycles duration. PLLCFG = 11 (so this makes M = 12 an N = 1).
CCLKCFG = 3 (so this makes CCLK = 72MHz).

Chip was produced in 29th week of 2006, initial revision.
Last line of top-side marking is ZSG0629-Y
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hello,

Our engineering team working on a LPC2378 also faced the same problem.
Even if the PLL errata was applied the execution of the code was not
stable. With MAM disabled and CPU@48Mhz the same code works fine.

I hope NXP finds out something here because the new silicon revision
will be useless with just the PLL issue fixed. As we see the thing there
is a potential MAM problem.

Marko

m...@rcn.com wrote:
>
> I would like to organize a cooperative investigation of the issues
> >that several users are experiencing with the lpc23xx parts' MAM. I've
> >directly emailed those users on this list that have previously
> >reported MAM problems.
> >
> >First, I'd like to make it clear that I have no interest in
> >NXP-bashing. They make a great product, and we believe they continue
> >to have the best solution to an entire class of our product needs.
> >
> >Our primary goal is to identify a simple test case that can be
> >reproduced on various users' configurations. Previous comments
> >indicate that the problem is limited to certain parts, which my
> >experience also suggests. Once we have identified a simple test case,
> >and examined it for any possible bugs, all interested users can try it
> >out on their systems, both those that do and do not seem vulnerable to
> >this issue.
> >
> >To Edwin Olson: In the message here (
> >http://tech.groups.yahoo.com/group/lpc2000/message/23611
> ), you
> >suggested that you had a simple test case. It would be extremely
> >valuable as a starting point for this investigation. Please consider
> >uploading it to the files area of this group. Also, to Ryan Niemi: you
> >mentioned having this problem. Do you have a simple test case? I will
> >also look into trying to trim down a simple test case on our "problem
> >board", but if anyone else has one ready and available, please speak
> >up!
> >
> >Our secondary goal is to pressure NXP to release an official errata
> >ASAP, *if* they have known issues, as some have suggested. I have
> >received personal confirmation that a new revision of silicon is in
> >the works, but no details on what the differences or fixes in the
> >revision are. The cost of engineering time of any delay in public
> >acknowledgment of problems like these is very, very high, especially
> >to the typical (to my estimation) lpc2xxx customer - small engineering
> >houses.
> >
> >To Sashi Ono: In the message here (
> >http://tech.groups.yahoo.com/group/lpc2000/message/24166
> ), you
> >suggested that you had direct contact with NXP representatives: "they
> >reported to me that they have found the problem and have already re
> >spun a new batch of silicon," confirming the existence of a known
> >problem that has not yet been publicly acknowledged. Can you verify
> >this assertion? If this is true, can you exert any pressure on your
> >NXP contacts to publicly acknowledge this issue?
> >
> >Thank you all for your collaboration,
> >--
> >Bryce Schober
> >
> > I emailed NXP regarding this issue, this is their reply:
>
> ----------------------------------------------------------
> NXP Semiconductors answer:
> We have not been able to confirm any issue with the MAM and >48MHz
> operation. There is a confirmed errata limiting the output range of
> the PLL to between 275-290MHz. If you enable the PLL and set it to
> anything outside of that range all bets are off on what will fail.
> This errata will be fixed in the next revision.
>
> -Dave
> ----------------------------------------------------------
>
> I'm in the process of selecting a uC for my project, the LPC2378 looks
> like a nice chip but this MAM issue makes it a difficult choice. Whom
> to believe, the several competent sounding posters who reported this
> problem or NXP? Could it be that both are right--that this problem
> affects only a small percentage of chips, and NXP hasn't been able to
> catch the problem.
>
> Is there anyone out there who has been able to successfuly run an
> LPC23xx @72Mhz with a program of >32k size in Flash?
>
>


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, marioml@... wrote:
>
> I emailed NXP regarding this issue, this is their reply:
>
> --------------------------------------------------------------------
-------
> NXP Semiconductors answer:
> We have not been able to confirm any issue with the MAM and >48MHz
operation. There is a confirmed errata limiting the output range of
the PLL to between 275-290MHz. If you enable the PLL and set it to
anything outside of that range all bets are off on what will fail.
This errata will be fixed in the next revision.
>
> -Dave
> --------------------------------------------------------------------
-------
>
> I'm in the process of selecting a uC for my project, the LPC2378
looks like a nice chip but this MAM issue makes it a difficult
choice. Whom to believe, the several competent sounding posters who
reported this problem or NXP? Could it be that both are right--that
this problem affects only a small percentage of chips, and NXP hasn't
been able to catch the problem.

Dave,

I see no reason why both can't be believed: there's no conflict that
I see.

On the one hand, NXP are saying they haven't confirmed any MAM or
related bug that hasn't already been documented and on the other
there are some (clearly competent, as you point out) people out there
who have systems that behave in a way that leads them to suspect
there may be a problem with MAM. These are not incompatible
positions. On one side there are other possible explanations for the
behaviour observed and on the other maybe NXP's testing hasn't
uncovered a possible bug. Unless and until someone can provide a
complete (and preferably small) example that shows definitively where
the problem is, and can be tested independently, I'd say it's case
unproven.

>
> Is there anyone out there who has been able to successfuly run an
LPC23xx @72Mhz with a program of >32k size in Flash?
>

Do you suspect the size of the program is the issue, or the address
range from which it is running?

Good question, though, as it's an attempt to isolate the conditions
where the problem manifests itself.

I'd agree with you though, that until someone isolates the problem,
I'd be slow to use the particular part (at least in the relevant
clocking/MAM settings).

Brendan



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi

> > Is there anyone out there who has been able to successfuly run an
> LPC23xx @72Mhz with a program of >32k size in Flash?
> >

I am using the MCB2300 board with LPC2368 on it at 72MHz

My code size is > 90KB.
Also I am using following peripherals in interrupt Mode for testing
2 Timers
2 UARTs (Planned to use 4)
I2C

I had also tested the use of IAP for on field update for firmware.

All other IOs in FIO mode.

The code is working fine and i had not yet come across any MAM issue.
Regards
Suvidh

--- In l...@yahoogroups.com, "Brendan Murphy"
wrote:
>
> --- In l...@yahoogroups.com, marioml@ wrote:
> >
> > I emailed NXP regarding this issue, this is their reply:
> >
> > --------------------------------------------------------------------
> -------
> > NXP Semiconductors answer:
> > We have not been able to confirm any issue with the MAM and >48MHz
> operation. There is a confirmed errata limiting the output range of
> the PLL to between 275-290MHz. If you enable the PLL and set it to
> anything outside of that range all bets are off on what will fail.
> This errata will be fixed in the next revision.
> >
> > -Dave
> > --------------------------------------------------------------------
> -------
> >
> > I'm in the process of selecting a uC for my project, the LPC2378
> looks like a nice chip but this MAM issue makes it a difficult
> choice. Whom to believe, the several competent sounding posters who
> reported this problem or NXP? Could it be that both are right--that
> this problem affects only a small percentage of chips, and NXP hasn't
> been able to catch the problem.
>
> Dave,
>
> I see no reason why both can't be believed: there's no conflict that
> I see.
>
> On the one hand, NXP are saying they haven't confirmed any MAM or
> related bug that hasn't already been documented and on the other
> there are some (clearly competent, as you point out) people out there
> who have systems that behave in a way that leads them to suspect
> there may be a problem with MAM. These are not incompatible
> positions. On one side there are other possible explanations for the
> behaviour observed and on the other maybe NXP's testing hasn't
> uncovered a possible bug. Unless and until someone can provide a
> complete (and preferably small) example that shows definitively where
> the problem is, and can be tested independently, I'd say it's case
> unproven.
>
> >
> > Is there anyone out there who has been able to successfuly run an
> LPC23xx @72Mhz with a program of >32k size in Flash?
> > Do you suspect the size of the program is the issue, or the address
> range from which it is running?
>
> Good question, though, as it's an attempt to isolate the conditions
> where the problem manifests itself.
>
> I'd agree with you though, that until someone isolates the problem,
> I'd be slow to use the particular part (at least in the relevant
> clocking/MAM settings).
>
> Brendan
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hello,

I'm working with Marko Panger and I'm directly involved in the design
(HW and SW) of our new product based on two LPC2368. From the
beginning of the project I'm experiencing strange behavior of the new
NXP processors. I have tried putting new one processors but the
problem staid, even with 2366 I cud not get stable application
executing on 72MHz and MAM enabled.

Here is my mail sent on 04/20/2007 to our dealer in hope that he will
pass it to NXP and help us to check our suspicious:

"Dear,

We started to experience new kind of problems during new project
development. After many tests my conclusion is that there is a problem
with MAM(Memory Accelerator Module) in general maybe even with
instruction prefetch from entire range of flash.

Somehow it seams that if application is smaller then 32kB,
CCLK(processor clock) = 72MHz, and MAMTIM = 4 everything works fine
but if the code greater then 32kB application ends up on Prefetch
abort vector almost every time. I tried lovering the processor clock,
higher MAMTIM values, but even with disabled MAM there are cases when
application aborts. The most stable running we achieve with processor
clock of 48MHz, and disabled MAM, but even in this case we are
experiencing application aborts.

Like You knew we are heading very high speed design on the end point
of project, please try to contact NXP and confirm our suspicion about
MAM. We doubt that there is some work around for this (except new
silicon revision), so try to give us information when can we expect
new production samples of LPC23xx.

Many thanks for your help."

I didn't get an answer on this mail from NXP :(.

I made many tests also, putting the code on different addresses,
moving data section, an the result was the same, application work(?)
only when the code is less then 32kB and CPU clk 48MHz and MAM disabled.

I have spick with developer from L-TEK, manufacturer of MCB2300 board
and received a negative answer on this issue. They didn't have problem
with MAM.

Based on so many test we did with our code, in linking of application,
changing of processors, etc.(taking care to all documented errata) I
can conclude that obviously there is potential MAM problem.

I hope NXP finds out something here because if they stay on the
conclusion that only PLL has a problem like we can see form "marmil.."
post:
---------------------------------------------------------------------------
"NXP Semiconductors answer:
We have not been able to confirm any issue with the MAM and >48MHz
operation.
There is a confirmed errata limiting the output range of the PLL to
between
275-290MHz. If you enable the PLL and set it to anything outside of
that range
all bets are off on what will fail. This errata will be fixed in the next
revision.

-Dave"
---------------------------------------------------------------------------the
then the new silicon revision will be useless.

I don't see some work around for this issue if you need fast
application executing.

Aleksandar

--- In l...@yahoogroups.com, "Bryce Schober" wrote:
>
> I would like to organize a cooperative investigation of the issues
> that several users are experiencing with the lpc23xx parts' MAM. I've
> directly emailed those users on this list that have previously
> reported MAM problems.
>
> First, I'd like to make it clear that I have no interest in
> NXP-bashing. They make a great product, and we believe they continue
> to have the best solution to an entire class of our product needs.
>
> Our primary goal is to identify a simple test case that can be
> reproduced on various users' configurations. Previous comments
> indicate that the problem is limited to certain parts, which my
> experience also suggests. Once we have identified a simple test case,
> and examined it for any possible bugs, all interested users can try it
> out on their systems, both those that do and do not seem vulnerable to
> this issue.
>
> To Edwin Olson: In the message here (
> http://tech.groups.yahoo.com/group/lpc2000/message/23611 ), you
> suggested that you had a simple test case. It would be extremely
> valuable as a starting point for this investigation. Please consider
> uploading it to the files area of this group. Also, to Ryan Niemi: you
> mentioned having this problem. Do you have a simple test case? I will
> also look into trying to trim down a simple test case on our "problem
> board", but if anyone else has one ready and available, please speak
> up!
>
> Our secondary goal is to pressure NXP to release an official errata
> ASAP, *if* they have known issues, as some have suggested. I have
> received personal confirmation that a new revision of silicon is in
> the works, but no details on what the differences or fixes in the
> revision are. The cost of engineering time of any delay in public
> acknowledgment of problems like these is very, very high, especially
> to the typical (to my estimation) lpc2xxx customer - small engineering
> houses.
>
> To Sashi Ono: In the message here (
> http://tech.groups.yahoo.com/group/lpc2000/message/24166 ), you
> suggested that you had direct contact with NXP representatives: "they
> reported to me that they have found the problem and have already re
> spun a new batch of silicon," confirming the existence of a known
> problem that has not yet been publicly acknowledged. Can you verify
> this assertion? If this is true, can you exert any pressure on your
> NXP contacts to publicly acknowledge this issue?
>
> Thank you all for your collaboration,
> --
> Bryce Schober
>

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Do you have simple test cases that don't require any confidential
code? If so, please publish them by uploading them to the files
section of this group, so that others can verify them. Also, could you
verify the test case that was recently uploaded to the files section
on your hardware?

On 5/11/07, Aleksandar Savic wrote:
> Hello,
>
> I'm working with Marko Panger and I'm directly involved in the design
> (HW and SW) of our new product based on two LPC2368. From the
> beginning of the project I'm experiencing strange behavior of the new
> NXP processors. I have tried putting new one processors but the
> problem staid, even with 2366 I cud not get stable application
> executing on 72MHz and MAM enabled.
>
> Here is my mail sent on 04/20/2007 to our dealer in hope that he will
> pass it to NXP and help us to check our suspicious:
>
> "Dear,
>
> We started to experience new kind of problems during new project
> development. After many tests my conclusion is that there is a problem
> with MAM(Memory Accelerator Module) in general maybe even with
> instruction prefetch from entire range of flash.
>
> Somehow it seams that if application is smaller then 32kB,
> CCLK(processor clock) = 72MHz, and MAMTIM = 4 everything works fine
> but if the code greater then 32kB application ends up on Prefetch
> abort vector almost every time. I tried lovering the processor clock,
> higher MAMTIM values, but even with disabled MAM there are cases when
> application aborts. The most stable running we achieve with processor
> clock of 48MHz, and disabled MAM, but even in this case we are
> experiencing application aborts.
>
> Like You knew we are heading very high speed design on the end point
> of project, please try to contact NXP and confirm our suspicion about
> MAM. We doubt that there is some work around for this (except new
> silicon revision), so try to give us information when can we expect
> new production samples of LPC23xx.
>
> Many thanks for your help."
>
> I didn't get an answer on this mail from NXP :(.
>
> I made many tests also, putting the code on different addresses,
> moving data section, an the result was the same, application work(?)
> only when the code is less then 32kB and CPU clk 48MHz and MAM disabled.
>
> I have spick with developer from L-TEK, manufacturer of MCB2300 board
> and received a negative answer on this issue. They didn't have problem
> with MAM.
>
> Based on so many test we did with our code, in linking of application,
> changing of processors, etc.(taking care to all documented errata) I
> can conclude that obviously there is potential MAM problem.
>
> I hope NXP finds out something here because if they stay on the
> conclusion that only PLL has a problem like we can see form "marmil.."
> post:
> ---------------------------------------------------------------------------
> "NXP Semiconductors answer:
> We have not been able to confirm any issue with the MAM and >48MHz
> operation.
> There is a confirmed errata limiting the output range of the PLL to
> between
> 275-290MHz. If you enable the PLL and set it to anything outside of
> that range
> all bets are off on what will fail. This errata will be fixed in the next
> revision.
>
> -Dave"
> ---------------------------------------------------------------------------the
> then the new silicon revision will be useless.
>
> I don't see some work around for this issue if you need fast
> application executing.
>
> Aleksandar
>
> --- In l...@yahoogroups.com, "Bryce Schober" wrote:
> >
> > I would like to organize a cooperative investigation of the issues
> > that several users are experiencing with the lpc23xx parts' MAM. I've
> > directly emailed those users on this list that have previously
> > reported MAM problems.
> >
> > First, I'd like to make it clear that I have no interest in
> > NXP-bashing. They make a great product, and we believe they continue
> > to have the best solution to an entire class of our product needs.
> >
> > Our primary goal is to identify a simple test case that can be
> > reproduced on various users' configurations. Previous comments
> > indicate that the problem is limited to certain parts, which my
> > experience also suggests. Once we have identified a simple test case,
> > and examined it for any possible bugs, all interested users can try it
> > out on their systems, both those that do and do not seem vulnerable to
> > this issue.
> >
> > To Edwin Olson: In the message here (
> > http://tech.groups.yahoo.com/group/lpc2000/message/23611 ), you
> > suggested that you had a simple test case. It would be extremely
> > valuable as a starting point for this investigation. Please consider
> > uploading it to the files area of this group. Also, to Ryan Niemi: you
> > mentioned having this problem. Do you have a simple test case? I will
> > also look into trying to trim down a simple test case on our "problem
> > board", but if anyone else has one ready and available, please speak
> > up!
> >
> > Our secondary goal is to pressure NXP to release an official errata
> > ASAP, *if* they have known issues, as some have suggested. I have
> > received personal confirmation that a new revision of silicon is in
> > the works, but no details on what the differences or fixes in the
> > revision are. The cost of engineering time of any delay in public
> > acknowledgment of problems like these is very, very high, especially
> > to the typical (to my estimation) lpc2xxx customer - small engineering
> > houses.
> >
> > To Sashi Ono: In the message here (
> > http://tech.groups.yahoo.com/group/lpc2000/message/24166 ), you
> > suggested that you had direct contact with NXP representatives: "they
> > reported to me that they have found the problem and have already re
> > spun a new batch of silicon," confirming the existence of a known
> > problem that has not yet been publicly acknowledged. Can you verify
> > this assertion? If this is true, can you exert any pressure on your
> > NXP contacts to publicly acknowledge this issue?
> >
> > Thank you all for your collaboration,
> > --
> > Bryce Schober
> > Yahoo! Groups Links
--
Bryce Schober



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Aleksandar Savic"
wrote:
>
> Hello,
>
> I'm working with Marko Panger and I'm directly involved in the
design
> (HW and SW) of our new product based on two LPC2368. From the
> beginning of the project I'm experiencing strange behavior of the
new
> NXP processors. I have tried putting new one processors but the
> problem staid, even with 2366 I cud not get stable application
> executing on 72MHz and MAM enabled.
>
> Here is my mail sent on 04/20/2007 to our dealer in hope that he
will
> pass it to NXP and help us to check our suspicious:
>
> "Dear,
>
> We started to experience new kind of problems during new project
> development. After many tests my conclusion is that there is a
problem
> with MAM(Memory Accelerator Module) in general maybe even with
> instruction prefetch from entire range of flash.
>
> Somehow it seams that if application is smaller then 32kB,
> CCLK(processor clock) = 72MHz, and MAMTIM = 4 everything works fine
> but if the code greater then 32kB application ends up on Prefetch
> abort vector almost every time. I tried lovering the processor
clock,
> higher MAMTIM values, but even with disabled MAM there are cases
when
> application aborts. The most stable running we achieve with
processor
> clock of 48MHz, and disabled MAM, but even in this case we are
> experiencing application aborts.
>
> Like You knew we are heading very high speed design on the end point
> of project, please try to contact NXP and confirm our suspicion
about
> MAM. We doubt that there is some work around for this (except new
> silicon revision), so try to give us information when can we expect
> new production samples of LPC23xx.
>
> Many thanks for your help."
>
> I didn't get an answer on this mail from NXP :(.
>
> I made many tests also, putting the code on different addresses,
> moving data section, an the result was the same, application work(?)
> only when the code is less then 32kB and CPU clk 48MHz and MAM
disabled.
>
> I have spick with developer from L-TEK, manufacturer of MCB2300
board
> and received a negative answer on this issue. They didn't have
problem
> with MAM.
>

Aleksandar,

I think it's disappointing that your dealer/NXP didn't even
acknowledge your note, but I also think you'd have to be a lot more
specific about the exact failure mode and can document in detail how
the system is non-conformant to its specification before it'll be
considered in detail.

You're saying you have a system that fails, but works if you adjust
some timing-related items. There could be any number of causes for
this behaviour.

I don't know of any MCU manufacturer that runs a service to debug
people's systems for them, even if there is a suspicion of a fault in
the device.

If you can provide a complete system that others (mainly NXP) can
check on some standard system that shows the specific underlying
problem in action, then you might get somewhere. By complete system,
I mean all source code, object code, details of system's environment
(clock speed etc.). It doesn't have to be related to your
application: just demonstrating the same (erroneous) behaviour.

Brendan



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi,

I'm recently working on a project based on LP2368. My code is little above
36K, runs at 72MHz and MAM enabled (MAMTIM=3). I did not so far experince
such a problem. It has been two weeks though since I started. But if you
could indicate the top printing of the LPC, I can check with mine and see if
there is a difference. I got the samples just 3 weeks ago.

Another possibility I can think of is your 3.3V quality which may cause
problems when the clock rate is increased and MAM enabled, due to increased
current consumption. It happened many years ago, an instable uP as a result
of poor power supply.

Like I said, I use the same uC. Thus I also look forward to see the end of
this discussion...

Kerem

From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On Behalf Of
Aleksandar Savic
Sent: Friday, May 11, 2007 6:00 PM
To: l...@yahoogroups.com
Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues

Hello,

I'm working with Marko Panger and I'm directly involved in the design
(HW and SW) of our new product based on two LPC2368. From the
beginning of the project I'm experiencing strange behavior of the new
NXP processors. I have tried putting new one processors but the
problem staid, even with 2366 I cud not get stable application
executing on 72MHz and MAM enabled.

Here is my mail sent on 04/20/2007 to our dealer in hope that he will
pass it to NXP and help us to check our suspicious:

"Dear,

We started to experience new kind of problems during new project
development. After many tests my conclusion is that there is a problem
with MAM(Memory Accelerator Module) in general maybe even with
instruction prefetch from entire range of flash.

Somehow it seams that if application is smaller then 32kB,
CCLK(processor clock) = 72MHz, and MAMTIM = 4 everything works fine
but if the code greater then 32kB application ends up on Prefetch
abort vector almost every time. I tried lovering the processor clock,
higher MAMTIM values, but even with disabled MAM there are cases when
application aborts. The most stable running we achieve with processor
clock of 48MHz, and disabled MAM, but even in this case we are
experiencing application aborts.

Like You knew we are heading very high speed design on the end point
of project, please try to contact NXP and confirm our suspicion about
MAM. We doubt that there is some work around for this (except new
silicon revision), so try to give us information when can we expect
new production samples of LPC23xx.

Many thanks for your help."

I didn't get an answer on this mail from NXP :(.

I made many tests also, putting the code on different addresses,
moving data section, an the result was the same, application work(?)
only when the code is less then 32kB and CPU clk 48MHz and MAM disabled.

I have spick with developer from L-TEK, manufacturer of MCB2300 board
and received a negative answer on this issue. They didn't have problem
with MAM.

Based on so many test we did with our code, in linking of application,
changing of processors, etc.(taking care to all documented errata) I
can conclude that obviously there is potential MAM problem.

I hope NXP finds out something here because if they stay on the
conclusion that only PLL has a problem like we can see form "marmil.."
post:
----------------------------------------------------------
"NXP Semiconductors answer:
We have not been able to confirm any issue with the MAM and >48MHz
operation.
There is a confirmed errata limiting the output range of the PLL to
between
275-290MHz. If you enable the PLL and set it to anything outside of
that range
all bets are off on what will fail. This errata will be fixed in the next
revision.

-Dave"
----------------------------------------------------------the
then the new silicon revision will be useless.

I don't see some work around for this issue if you need fast
application executing.

Aleksandar

--- In l...@yahoogroups.com , "Bryce
Schober" wrote:
>
> I would like to organize a cooperative investigation of the issues
> that several users are experiencing with the lpc23xx parts' MAM. I've
> directly emailed those users on this list that have previously
> reported MAM problems.
>
> First, I'd like to make it clear that I have no interest in
> NXP-bashing. They make a great product, and we believe they continue
> to have the best solution to an entire class of our product needs.
>
> Our primary goal is to identify a simple test case that can be
> reproduced on various users' configurations. Previous comments
> indicate that the problem is limited to certain parts, which my
> experience also suggests. Once we have identified a simple test case,
> and examined it for any possible bugs, all interested users can try it
> out on their systems, both those that do and do not seem vulnerable to
> this issue.
>
> To Edwin Olson: In the message here (
> http://tech.groups.yahoo.com/group/lpc2000/message/23611 ), you
> suggested that you had a simple test case. It would be extremely
> valuable as a starting point for this investigation. Please consider
> uploading it to the files area of this group. Also, to Ryan Niemi: you
> mentioned having this problem. Do you have a simple test case? I will
> also look into trying to trim down a simple test case on our "problem
> board", but if anyone else has one ready and available, please speak
> up!
>
> Our secondary goal is to pressure NXP to release an official errata
> ASAP, *if* they have known issues, as some have suggested. I have
> received personal confirmation that a new revision of silicon is in
> the works, but no details on what the differences or fixes in the
> revision are. The cost of engineering time of any delay in public
> acknowledgment of problems like these is very, very high, especially
> to the typical (to my estimation) lpc2xxx customer - small engineering
> houses.
>
> To Sashi Ono: In the message here (
> http://tech.groups.yahoo.com/group/lpc2000/message/24166 ), you
> suggested that you had direct contact with NXP representatives: "they
> reported to me that they have found the problem and have already re
> spun a new batch of silicon," confirming the existence of a known
> problem that has not yet been publicly acknowledged. Can you verify
> this assertion? If this is true, can you exert any pressure on your
> NXP contacts to publicly acknowledge this issue?
>
> Thank you all for your collaboration,
> --
> Bryce Schober
>

[Non-text portions of this message have been removed]
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Bryce Schober" wrote:
>
> I would like to organize a cooperative investigation of the issues
> that several users are experiencing with the lpc23xx parts' MAM. I've
> directly emailed those users on this list that have previously
> reported MAM problems.
>
> First, I'd like to make it clear that I have no interest in
> NXP-bashing. They make a great product, and we believe they continue
> to have the best solution to an entire class of our product needs.
>
> Our primary goal is to identify a simple test case that can be
> reproduced on various users' configurations. Previous comments
> indicate that the problem is limited to certain parts, which my
> experience also suggests. Once we have identified a simple test case,
> and examined it for any possible bugs, all interested users can try it
> out on their systems, both those that do and do not seem vulnerable to
> this issue.
>
> To Edwin Olson: In the message here (
> http://tech.groups.yahoo.com/group/lpc2000/message/23611 ), you
> suggested that you had a simple test case. It would be extremely
> valuable as a starting point for this investigation. Please consider
> uploading it to the files area of this group. Also, to Ryan Niemi: you
> mentioned having this problem. Do you have a simple test case? I will
> also look into trying to trim down a simple test case on our "problem
> board", but if anyone else has one ready and available, please speak
> up!
>
> Our secondary goal is to pressure NXP to release an official errata
> ASAP, *if* they have known issues, as some have suggested. I have
> received personal confirmation that a new revision of silicon is in
> the works, but no details on what the differences or fixes in the
> revision are. The cost of engineering time of any delay in public
> acknowledgment of problems like these is very, very high, especially
> to the typical (to my estimation) lpc2xxx customer - small engineering
> houses.
>
> To Sashi Ono: In the message here (
> http://tech.groups.yahoo.com/group/lpc2000/message/24166 ), you
> suggested that you had direct contact with NXP representatives: "they
> reported to me that they have found the problem and have already re
> spun a new batch of silicon," confirming the existence of a known
> problem that has not yet been publicly acknowledged. Can you verify
> this assertion? If this is true, can you exert any pressure on your
> NXP contacts to publicly acknowledge this issue?
>
> Thank you all for your collaboration,
> --
> Bryce Schober
>

Hello,

It appears there is a timing issue with ABORT signal used to raise
PREFETCH (and DATA?) aborts. This appears to occur when: a) CCLK > 48
MHz; b) MAM is enabled; and c) when higher order address bits are set.

I would suggest creating a sequence that forces PREFETCH (or DATA?)
abort, then altering the conditions such that this abort should NOT
occur and see what happens.

Regards,

Jaya


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I am working on the LPC2132 since past January. I have data abort
problem and below is the description:

Compiler: Keil's CARM V2.40
IDE: uVision3
controller: LPC2132
crystal freq: 12.288MHz
PLL: enable, MSEL=4, PSEL=2
MAM: fully enable, Timing = 3
memory usage: code 10K, data 10K

Problem: Data abort consistantly happens at the same location of the
codes, but fails to manifest itself from single-steppping through the
codes using ULINK.

Work-around: When I changed MAM Timing setting from 3 to 5-7, or
disable the MAM, everything works. When compared the working hex code
with the one that didn't work, both are identical except the MAM byte.

Enclosed at the file section with name "data abort problem.zip" is my
project for anyone who would like to dig to the bottom to find out if
this is MAM issue, or it is just my bug in the code. Read the "Read
me first.pdf" to see how I duplicate the problem with ULINK.

Hian

--- In l...@yahoogroups.com, "Kerem Or" wrote:
>
> Hi,
>
>
>
> I'm recently working on a project based on LP2368. My code is
little above
> 36K, runs at 72MHz and MAM enabled (MAMTIM=3). I did not so far
experince
> such a problem. It has been two weeks though since I started. But
if you
> could indicate the top printing of the LPC, I can check with mine
and see if
> there is a difference. I got the samples just 3 weeks ago.
>
>
>
> Another possibility I can think of is your 3.3V quality which may
cause
> problems when the clock rate is increased and MAM enabled, due to
increased
> current consumption. It happened many years ago, an instable uP as
a result
> of poor power supply.
>
>
>
> Like I said, I use the same uC. Thus I also look forward to see
the end of
> this discussion...
>
>
>
> Kerem
>
>
>
> From: l...@yahoogroups.com [mailto:l...@yahoogroups.com] On
Behalf Of
> Aleksandar Savic
> Sent: Friday, May 11, 2007 6:00 PM
> To: l...@yahoogroups.com
> Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues
>
>
>
> Hello,
>
> I'm working with Marko Panger and I'm directly involved in the
design
> (HW and SW) of our new product based on two LPC2368. From the
> beginning of the project I'm experiencing strange behavior of the
new
> NXP processors. I have tried putting new one processors but the
> problem staid, even with 2366 I cud not get stable application
> executing on 72MHz and MAM enabled.
>
> Here is my mail sent on 04/20/2007 to our dealer in hope that he
will
> pass it to NXP and help us to check our suspicious:
>
> "Dear,
>
> We started to experience new kind of problems during new project
> development. After many tests my conclusion is that there is a
problem
> with MAM(Memory Accelerator Module) in general maybe even with
> instruction prefetch from entire range of flash.
>
> Somehow it seams that if application is smaller then 32kB,
> CCLK(processor clock) = 72MHz, and MAMTIM = 4 everything works fine
> but if the code greater then 32kB application ends up on Prefetch
> abort vector almost every time. I tried lovering the processor
clock,
> higher MAMTIM values, but even with disabled MAM there are cases
when
> application aborts. The most stable running we achieve with
processor
> clock of 48MHz, and disabled MAM, but even in this case we are
> experiencing application aborts.
>
> Like You knew we are heading very high speed design on the end point
> of project, please try to contact NXP and confirm our suspicion
about
> MAM. We doubt that there is some work around for this (except new
> silicon revision), so try to give us information when can we expect
> new production samples of LPC23xx.
>
> Many thanks for your help."
>
> I didn't get an answer on this mail from NXP :(.
>
> I made many tests also, putting the code on different addresses,
> moving data section, an the result was the same, application work(?)
> only when the code is less then 32kB and CPU clk 48MHz and MAM
disabled.
>
> I have spick with developer from L-TEK, manufacturer of MCB2300
board
> and received a negative answer on this issue. They didn't have
problem
> with MAM.
>
> Based on so many test we did with our code, in linking of
application,
> changing of processors, etc.(taking care to all documented errata) I
> can conclude that obviously there is potential MAM problem.
>
> I hope NXP finds out something here because if they stay on the
> conclusion that only PLL has a problem like we can see
form "marmil.."
> post:
> ----------------------------------------------------------
> "NXP Semiconductors answer:
> We have not been able to confirm any issue with the MAM and >48MHz
> operation.
> There is a confirmed errata limiting the output range of the PLL to
> between
> 275-290MHz. If you enable the PLL and set it to anything outside of
> that range
> all bets are off on what will fail. This errata will be fixed in
the next
> revision.
>
> -Dave"
> ----------------------------------------------------------the
> then the new silicon revision will be useless.
>
> I don't see some work around for this issue if you need fast
> application executing.
>
> Aleksandar
>
> --- In l...@yahoogroups.com 40yahoogroups.com> , "Bryce
> Schober" wrote:
> >
> > I would like to organize a cooperative investigation of the issues
> > that several users are experiencing with the lpc23xx parts' MAM.
I've
> > directly emailed those users on this list that have previously
> > reported MAM problems.
> >
> > First, I'd like to make it clear that I have no interest in
> > NXP-bashing. They make a great product, and we believe they
continue
> > to have the best solution to an entire class of our product needs.
> >
> > Our primary goal is to identify a simple test case that can be
> > reproduced on various users' configurations. Previous comments
> > indicate that the problem is limited to certain parts, which my
> > experience also suggests. Once we have identified a simple test
case,
> > and examined it for any possible bugs, all interested users can
try it
> > out on their systems, both those that do and do not seem
vulnerable to
> > this issue.
> >
> > To Edwin Olson: In the message here (
> > http://tech.groups.yahoo.com/group/lpc2000/message/23611 ), you
> > suggested that you had a simple test case. It would be extremely
> > valuable as a starting point for this investigation. Please
consider
> > uploading it to the files area of this group. Also, to Ryan
Niemi: you
> > mentioned having this problem. Do you have a simple test case? I
will
> > also look into trying to trim down a simple test case on
our "problem
> > board", but if anyone else has one ready and available, please
speak
> > up!
> >
> > Our secondary goal is to pressure NXP to release an official
errata
> > ASAP, *if* they have known issues, as some have suggested. I have
> > received personal confirmation that a new revision of silicon is
in
> > the works, but no details on what the differences or fixes in the
> > revision are. The cost of engineering time of any delay in public
> > acknowledgment of problems like these is very, very high,
especially
> > to the typical (to my estimation) lpc2xxx customer - small
engineering
> > houses.
> >
> > To Sashi Ono: In the message here (
> > http://tech.groups.yahoo.com/group/lpc2000/message/24166 ), you
> > suggested that you had direct contact with NXP
representatives: "they
> > reported to me that they have found the problem and have already
re
> > spun a new batch of silicon," confirming the existence of a known
> > problem that has not yet been publicly acknowledged. Can you
verify
> > this assertion? If this is true, can you exert any pressure on
your
> > NXP contacts to publicly acknowledge this issue?
> >
> > Thank you all for your collaboration,
> > --
> > Bryce Schober
> >
>
> [Non-text portions of this message have been removed]
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> -----Original Message-----
> From: l...@yahoogroups.com
> [mailto:l...@yahoogroups.com]On Behalf
> Of hschew00
> Sent: Friday, May 11, 2007 7:38 PM
> To: l...@yahoogroups.com
> Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues
> I am working on the LPC2132 since past January. I have data abort
> problem and below is the description:
>
> Compiler: Keil's CARM V2.40
> IDE: uVision3
> controller: LPC2132
> crystal freq: 12.288MHz
> PLL: enable, MSEL=4, PSEL=2
> MAM: fully enable, Timing = 3
> memory usage: code 10K, data 10K
>
> Problem: Data abort consistantly happens at the same location of the
> codes, but fails to manifest itself from single-steppping through the
> codes using ULINK.
>
> Work-around: When I changed MAM Timing setting from 3 to 5-7, or
> disable the MAM, everything works. When compared the working hex code
> with the one that didn't work, both are identical except the MAM byte.
>
> Enclosed at the file section with name "data abort problem.zip" is my
> project for anyone who would like to dig to the bottom to find out if
> this is MAM issue, or it is just my bug in the code. Read the "Read
> me first.pdf" to see how I duplicate the problem with ULINK.
>
> Hian

I just had a quick look through your code, and noticed a number of
things you should look at. These may or may not be causing what
you are seeing, but they should be looked at.

You should probably set the default VIC vector to something useful,
just in case you get spurious interrupts. If you are doing this,
I can't find it.

Variables that are updated inside interrupt routines, and accessed
outside of interrupt routines should be declared as volatile. Your
variable self_test_timer would be an example of a variable that is
volatile.

The UART1 interrupt handler must do something other than just respond
to the VIC. The interrupt flag must be cleared via some other method,
depending on what triggered it.

Given that the LPC2132 has existed for quite some time, and that there
have not been reports of MAM issues like you describe, this is likely
still a software problem. In fact, given that there appear to be some
interrupt issues, I would see if you can duplicate the problem with
interrupts disabled.

Others on this list may have many more suggestions (and knowledge)
regarding this than I have, but these are a number of issues that
you should consider.

Mike

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Michael Anton" wrote:
> Given that the LPC2132 has existed for quite some time, and that there
> have not been reports of MAM issues like you describe, this is likely
> still a software problem. In fact, given that there appear to be some
> interrupt issues, I would see if you can duplicate the problem with
> interrupts disabled.
>

The interesting thing about this is (given you're almost certainly
correct in doubting a MAM problem exists in the LPC213x) that this is
an example of a problem that seems to be MAM related but has its root
cause elsewhere.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Mike,
Thanks for the hint. I followed your instruction by doing the
following:
1)declare all the variables as volatile (instead of searching one by
one in the code)
2)disable interrupt for USART and I2C, only enable TMR0 and EXT0.
Somehow when I disable EXT0, the compiled code size change, and hence
memory mapping.

The above changes does not change the code size. Data abort occurs as
usual at the same location. Any other idea that you can guide me?

Hian

--- In l...@yahoogroups.com, "Michael Anton" wrote:
>
> > -----Original Message-----
> > From: l...@yahoogroups.com
> > [mailto:l...@yahoogroups.com]On Behalf
> > Of hschew00
> > Sent: Friday, May 11, 2007 7:38 PM
> > To: l...@yahoogroups.com
> > Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues
> >
> >
> > I am working on the LPC2132 since past January. I have data abort
> > problem and below is the description:
> >
> > Compiler: Keil's CARM V2.40
> > IDE: uVision3
> > controller: LPC2132
> > crystal freq: 12.288MHz
> > PLL: enable, MSEL=4, PSEL=2
> > MAM: fully enable, Timing = 3
> > memory usage: code 10K, data 10K
> >
> > Problem: Data abort consistantly happens at the same location of
the
> > codes, but fails to manifest itself from single-steppping through
the
> > codes using ULINK.
> >
> > Work-around: When I changed MAM Timing setting from 3 to 5-7, or
> > disable the MAM, everything works. When compared the working hex
code
> > with the one that didn't work, both are identical except the MAM
byte.
> >
> > Enclosed at the file section with name "data abort problem.zip"
is my
> > project for anyone who would like to dig to the bottom to find
out if
> > this is MAM issue, or it is just my bug in the code. Read
the "Read
> > me first.pdf" to see how I duplicate the problem with ULINK.
> >
> > Hian
> >
> > I just had a quick look through your code, and noticed a number of
> things you should look at. These may or may not be causing what
> you are seeing, but they should be looked at.
>
> You should probably set the default VIC vector to something useful,
> just in case you get spurious interrupts. If you are doing this,
> I can't find it.
>
> Variables that are updated inside interrupt routines, and accessed
> outside of interrupt routines should be declared as volatile. Your
> variable self_test_timer would be an example of a variable that is
> volatile.
>
> The UART1 interrupt handler must do something other than just
respond
> to the VIC. The interrupt flag must be cleared via some other
method,
> depending on what triggered it.
>
> Given that the LPC2132 has existed for quite some time, and that
there
> have not been reports of MAM issues like you describe, this is
likely
> still a software problem. In fact, given that there appear to be
some
> interrupt issues, I would see if you can duplicate the problem with
> interrupts disabled.
>
> Others on this list may have many more suggestions (and knowledge)
> regarding this than I have, but these are a number of issues that
> you should consider.
>
> Mike
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> -----Original Message-----
> From: l...@yahoogroups.com
> [mailto:l...@yahoogroups.com]On Behalf
> Of hschew00
> Sent: Monday, May 14, 2007 2:26 PM
> To: l...@yahoogroups.com
> Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues
> Mike,
> Thanks for the hint. I followed your instruction by doing the
> following:
> 1)declare all the variables as volatile (instead of searching one by
> one in the code)
> 2)disable interrupt for USART and I2C, only enable TMR0 and EXT0.
> Somehow when I disable EXT0, the compiled code size change, and hence
> memory mapping.
>
> The above changes does not change the code size. Data abort occurs as
> usual at the same location. Any other idea that you can guide me?
>
> Hian
>
> --- In l...@yahoogroups.com, "Michael Anton" wrote:

Did you set the VIC default vector so something useful?

Mike
> >
> >
> >
> > > -----Original Message-----
> > > From: l...@yahoogroups.com
> > > [mailto:l...@yahoogroups.com]On Behalf
> > > Of hschew00
> > > Sent: Friday, May 11, 2007 7:38 PM
> > > To: l...@yahoogroups.com
> > > Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues
> > >
> > >
> > > I am working on the LPC2132 since past January. I have data abort
> > > problem and below is the description:
> > >
> > > Compiler: Keil's CARM V2.40
> > > IDE: uVision3
> > > controller: LPC2132
> > > crystal freq: 12.288MHz
> > > PLL: enable, MSEL=4, PSEL=2
> > > MAM: fully enable, Timing = 3
> > > memory usage: code 10K, data 10K
> > >
> > > Problem: Data abort consistantly happens at the same location of
> the
> > > codes, but fails to manifest itself from single-steppping through
> the
> > > codes using ULINK.
> > >
> > > Work-around: When I changed MAM Timing setting from 3 to 5-7, or
> > > disable the MAM, everything works. When compared the working hex
> code
> > > with the one that didn't work, both are identical except the MAM
> byte.
> > >
> > > Enclosed at the file section with name "data abort problem.zip"
> is my
> > > project for anyone who would like to dig to the bottom to find
> out if
> > > this is MAM issue, or it is just my bug in the code. Read
> the "Read
> > > me first.pdf" to see how I duplicate the problem with ULINK.
> > >
> > > Hian
> > >
> > >
> >
> > I just had a quick look through your code, and noticed a number of
> > things you should look at. These may or may not be causing what
> > you are seeing, but they should be looked at.
> >
> > You should probably set the default VIC vector to something useful,
> > just in case you get spurious interrupts. If you are doing this,
> > I can't find it.
> >
> > Variables that are updated inside interrupt routines, and accessed
> > outside of interrupt routines should be declared as volatile. Your
> > variable self_test_timer would be an example of a variable that is
> > volatile.
> >
> > The UART1 interrupt handler must do something other than just
> respond
> > to the VIC. The interrupt flag must be cleared via some other
> method,
> > depending on what triggered it.
> >
> > Given that the LPC2132 has existed for quite some time, and that
> there
> > have not been reports of MAM issues like you describe, this is
> likely
> > still a software problem. In fact, given that there appear to be
> some
> > interrupt issues, I would see if you can duplicate the problem with
> > interrupts disabled.
> >
> > Others on this list may have many more suggestions (and knowledge)
> > regarding this than I have, but these are a number of issues that
> > you should consider.
> >
> > Mike
> >
>
> Yahoo! Groups Links
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Whats are the size of your stacks.
Are they properly alligned to 4 byte boundaries?

Regards
Suvidh

--- In l...@yahoogroups.com, "Michael Anton" wrote:
>
> > -----Original Message-----
> > From: l...@yahoogroups.com
> > [mailto:l...@yahoogroups.com]On Behalf
> > Of hschew00
> > Sent: Monday, May 14, 2007 2:26 PM
> > To: l...@yahoogroups.com
> > Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues
> >
> >
> > Mike,
> > Thanks for the hint. I followed your instruction by doing the
> > following:
> > 1)declare all the variables as volatile (instead of searching one by
> > one in the code)
> > 2)disable interrupt for USART and I2C, only enable TMR0 and EXT0.
> > Somehow when I disable EXT0, the compiled code size change, and hence
> > memory mapping.
> >
> > The above changes does not change the code size. Data abort occurs as
> > usual at the same location. Any other idea that you can guide me?
> >
> > Hian
> >
> > --- In l...@yahoogroups.com, "Michael Anton" wrote:
>
> Did you set the VIC default vector so something useful?
>
> Mike
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: l...@yahoogroups.com
> > > > [mailto:l...@yahoogroups.com]On Behalf
> > > > Of hschew00
> > > > Sent: Friday, May 11, 2007 7:38 PM
> > > > To: l...@yahoogroups.com
> > > > Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues
> > > >
> > > >
> > > > I am working on the LPC2132 since past January. I have data abort
> > > > problem and below is the description:
> > > >
> > > > Compiler: Keil's CARM V2.40
> > > > IDE: uVision3
> > > > controller: LPC2132
> > > > crystal freq: 12.288MHz
> > > > PLL: enable, MSEL=4, PSEL=2
> > > > MAM: fully enable, Timing = 3
> > > > memory usage: code 10K, data 10K
> > > >
> > > > Problem: Data abort consistantly happens at the same location of
> > the
> > > > codes, but fails to manifest itself from single-steppping through
> > the
> > > > codes using ULINK.
> > > >
> > > > Work-around: When I changed MAM Timing setting from 3 to 5-7, or
> > > > disable the MAM, everything works. When compared the working hex
> > code
> > > > with the one that didn't work, both are identical except the MAM
> > byte.
> > > >
> > > > Enclosed at the file section with name "data abort problem.zip"
> > is my
> > > > project for anyone who would like to dig to the bottom to find
> > out if
> > > > this is MAM issue, or it is just my bug in the code. Read
> > the "Read
> > > > me first.pdf" to see how I duplicate the problem with ULINK.
> > > >
> > > > Hian
> > > >
> > > >
> > >
> > > I just had a quick look through your code, and noticed a number of
> > > things you should look at. These may or may not be causing what
> > > you are seeing, but they should be looked at.
> > >
> > > You should probably set the default VIC vector to something useful,
> > > just in case you get spurious interrupts. If you are doing this,
> > > I can't find it.
> > >
> > > Variables that are updated inside interrupt routines, and accessed
> > > outside of interrupt routines should be declared as volatile. Your
> > > variable self_test_timer would be an example of a variable that is
> > > volatile.
> > >
> > > The UART1 interrupt handler must do something other than just
> > respond
> > > to the VIC. The interrupt flag must be cleared via some other
> > method,
> > > depending on what triggered it.
> > >
> > > Given that the LPC2132 has existed for quite some time, and that
> > there
> > > have not been reports of MAM issues like you describe, this is
> > likely
> > > still a software problem. In fact, given that there appear to be
> > some
> > > interrupt issues, I would see if you can duplicate the problem with
> > > interrupts disabled.
> > >
> > > Others on this list may have many more suggestions (and knowledge)
> > > regarding this than I have, but these are a number of issues that
> > > you should consider.
> > >
> > > Mike
> > >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
>
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Suvidh,
The stack sizes are listed as follow:
User/System Mode 0x0400
Interrupt Mode 0x0080

The following are never used but declared as
Fast Interrupt Mode 0x0004
Abort Mode 0x0004
Supervisor Mode 0x0004
Undefined Mode 0x0004

I am sure the code never use more than the above allocation. When you
mentioned "properly alligned to 4 byte boundaries", how do I do
that? Shouldn't the compiler handle all these?
Thanks for the help.
Hian
--- In l...@yahoogroups.com, "suvidhk"
wrote:
>
> Whats are the size of your stacks.
> Are they properly alligned to 4 byte boundaries?
>
> Regards
> Suvidh
>
> --- In l...@yahoogroups.com, "Michael Anton" wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: l...@yahoogroups.com
> > > [mailto:l...@yahoogroups.com]On Behalf
> > > Of hschew00
> > > Sent: Monday, May 14, 2007 2:26 PM
> > > To: l...@yahoogroups.com
> > > Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues
> > >
> > >
> > > Mike,
> > > Thanks for the hint. I followed your instruction by doing the
> > > following:
> > > 1)declare all the variables as volatile (instead of searching
one by
> > > one in the code)
> > > 2)disable interrupt for USART and I2C, only enable TMR0 and
EXT0.
> > > Somehow when I disable EXT0, the compiled code size change, and
hence
> > > memory mapping.
> > >
> > > The above changes does not change the code size. Data abort
occurs as
> > > usual at the same location. Any other idea that you can guide
me?
> > >
> > > Hian
> > >
> > > --- In l...@yahoogroups.com, "Michael Anton" wrote:
> >
> > Did you set the VIC default vector so something useful?
> >
> > Mike
> >
> >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: l...@yahoogroups.com
> > > > > [mailto:l...@yahoogroups.com]On Behalf
> > > > > Of hschew00
> > > > > Sent: Friday, May 11, 2007 7:38 PM
> > > > > To: l...@yahoogroups.com
> > > > > Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues
> > > > >
> > > > >
> > > > > I am working on the LPC2132 since past January. I have data
abort
> > > > > problem and below is the description:
> > > > >
> > > > > Compiler: Keil's CARM V2.40
> > > > > IDE: uVision3
> > > > > controller: LPC2132
> > > > > crystal freq: 12.288MHz
> > > > > PLL: enable, MSEL=4, PSEL=2
> > > > > MAM: fully enable, Timing = 3
> > > > > memory usage: code 10K, data 10K
> > > > >
> > > > > Problem: Data abort consistantly happens at the same
location of
> > > the
> > > > > codes, but fails to manifest itself from single-steppping
through
> > > the
> > > > > codes using ULINK.
> > > > >
> > > > > Work-around: When I changed MAM Timing setting from 3 to 5-
7, or
> > > > > disable the MAM, everything works. When compared the
working hex
> > > code
> > > > > with the one that didn't work, both are identical except
the MAM
> > > byte.
> > > > >
> > > > > Enclosed at the file section with name "data abort
problem.zip"
> > > is my
> > > > > project for anyone who would like to dig to the bottom to
find
> > > out if
> > > > > this is MAM issue, or it is just my bug in the code. Read
> > > the "Read
> > > > > me first.pdf" to see how I duplicate the problem with ULINK.
> > > > >
> > > > > Hian
> > > > >
> > > > >
> > > >
> > > > I just had a quick look through your code, and noticed a
number of
> > > > things you should look at. These may or may not be causing
what
> > > > you are seeing, but they should be looked at.
> > > >
> > > > You should probably set the default VIC vector to something
useful,
> > > > just in case you get spurious interrupts. If you are doing
this,
> > > > I can't find it.
> > > >
> > > > Variables that are updated inside interrupt routines, and
accessed
> > > > outside of interrupt routines should be declared as
volatile. Your
> > > > variable self_test_timer would be an example of a variable
that is
> > > > volatile.
> > > >
> > > > The UART1 interrupt handler must do something other than just
> > > respond
> > > > to the VIC. The interrupt flag must be cleared via some
other
> > > method,
> > > > depending on what triggered it.
> > > >
> > > > Given that the LPC2132 has existed for quite some time, and
that
> > > there
> > > > have not been reports of MAM issues like you describe, this
is
> > > likely
> > > > still a software problem. In fact, given that there appear
to be
> > > some
> > > > interrupt issues, I would see if you can duplicate the
problem with
> > > > interrupts disabled.
> > > >
> > > > Others on this list may have many more suggestions (and
knowledge)
> > > > regarding this than I have, but these are a number of issues
that
> > > > you should consider.
> > > >
> > > > Mike
> > > >
> > >
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
>
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Whats DEBUG_PROBLEM ?
Do You get an data abort error when you undefine this ?
Suvidh
--- In l...@yahoogroups.com, "hschew00" wrote:
>
> Suvidh,
> The stack sizes are listed as follow:
> User/System Mode 0x0400
> Interrupt Mode 0x0080
>
> The following are never used but declared as
> Fast Interrupt Mode 0x0004
> Abort Mode 0x0004
> Supervisor Mode 0x0004
> Undefined Mode 0x0004
>
> I am sure the code never use more than the above allocation. When you
> mentioned "properly alligned to 4 byte boundaries", how do I do
> that? Shouldn't the compiler handle all these?
> Thanks for the help.
> Hian
> --- In l...@yahoogroups.com, "suvidhk"
> wrote:
> >
> >
> >
> > Whats are the size of your stacks.
> > Are they properly alligned to 4 byte boundaries?
> >
> > Regards
> >
> >
> > Suvidh
> >
> > --- In l...@yahoogroups.com, "Michael Anton" wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: l...@yahoogroups.com
> > > > [mailto:l...@yahoogroups.com]On Behalf
> > > > Of hschew00
> > > > Sent: Monday, May 14, 2007 2:26 PM
> > > > To: l...@yahoogroups.com
> > > > Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues
> > > >
> > > >
> > > > Mike,
> > > > Thanks for the hint. I followed your instruction by doing the
> > > > following:
> > > > 1)declare all the variables as volatile (instead of searching
> one by
> > > > one in the code)
> > > > 2)disable interrupt for USART and I2C, only enable TMR0 and
> EXT0.
> > > > Somehow when I disable EXT0, the compiled code size change, and
> hence
> > > > memory mapping.
> > > >
> > > > The above changes does not change the code size. Data abort
> occurs as
> > > > usual at the same location. Any other idea that you can guide
> me?
> > > >
> > > > Hian
> > > >
> > > > --- In l...@yahoogroups.com, "Michael Anton" wrote:
> > >
> > > Did you set the VIC default vector so something useful?
> > >
> > > Mike
> > >
> > >
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: l...@yahoogroups.com
> > > > > > [mailto:l...@yahoogroups.com]On Behalf
> > > > > > Of hschew00
> > > > > > Sent: Friday, May 11, 2007 7:38 PM
> > > > > > To: l...@yahoogroups.com
> > > > > > Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues
> > > > > >
> > > > > >
> > > > > > I am working on the LPC2132 since past January. I have data
> abort
> > > > > > problem and below is the description:
> > > > > >
> > > > > > Compiler: Keil's CARM V2.40
> > > > > > IDE: uVision3
> > > > > > controller: LPC2132
> > > > > > crystal freq: 12.288MHz
> > > > > > PLL: enable, MSEL=4, PSEL=2
> > > > > > MAM: fully enable, Timing = 3
> > > > > > memory usage: code 10K, data 10K
> > > > > >
> > > > > > Problem: Data abort consistantly happens at the same
> location of
> > > > the
> > > > > > codes, but fails to manifest itself from single-steppping
> through
> > > > the
> > > > > > codes using ULINK.
> > > > > >
> > > > > > Work-around: When I changed MAM Timing setting from 3 to 5-
> 7, or
> > > > > > disable the MAM, everything works. When compared the
> working hex
> > > > code
> > > > > > with the one that didn't work, both are identical except
> the MAM
> > > > byte.
> > > > > >
> > > > > > Enclosed at the file section with name "data abort
> problem.zip"
> > > > is my
> > > > > > project for anyone who would like to dig to the bottom to
> find
> > > > out if
> > > > > > this is MAM issue, or it is just my bug in the code. Read
> > > > the "Read
> > > > > > me first.pdf" to see how I duplicate the problem with ULINK.
> > > > > >
> > > > > > Hian
> > > > > >
> > > > > >
> > > > >
> > > > > I just had a quick look through your code, and noticed a
> number of
> > > > > things you should look at. These may or may not be causing
> what
> > > > > you are seeing, but they should be looked at.
> > > > >
> > > > > You should probably set the default VIC vector to something
> useful,
> > > > > just in case you get spurious interrupts. If you are doing
> this,
> > > > > I can't find it.
> > > > >
> > > > > Variables that are updated inside interrupt routines, and
> accessed
> > > > > outside of interrupt routines should be declared as
> volatile. Your
> > > > > variable self_test_timer would be an example of a variable
> that is
> > > > > volatile.
> > > > >
> > > > > The UART1 interrupt handler must do something other than just
> > > > respond
> > > > > to the VIC. The interrupt flag must be cleared via some
> other
> > > > method,
> > > > > depending on what triggered it.
> > > > >
> > > > > Given that the LPC2132 has existed for quite some time, and
> that
> > > > there
> > > > > have not been reports of MAM issues like you describe, this
> is
> > > > likely
> > > > > still a software problem. In fact, given that there appear
> to be
> > > > some
> > > > > interrupt issues, I would see if you can duplicate the
> problem with
> > > > > interrupts disabled.
> > > > >
> > > > > Others on this list may have many more suggestions (and
> knowledge)
> > > > > regarding this than I have, but these are a number of issues
> that
> > > > > you should consider.
> > > > >
> > > > > Mike
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > >
>


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Suvidh,
When I undefined DEBUG_PROBLEM, I don't see the problem. The compiled
code size is identical in both cases, but major change on the hex
files when I compared the two. One will expect the changes should
occur at that section, but this is not the case.

I know I didn't initialize the variable "total_boiler" when
DEBUG_PROBLEM is defined. However, from ULINK debugging, the value is
0 when data abort occurs.

Regarding "properly alligned to 4 byte boundaries", is there anywhere
in the codes or uvision3 environment that I need to set for this?

Hian

--- In l...@yahoogroups.com, "suvidhk"
wrote:
> Whats DEBUG_PROBLEM ?
> Do You get an data abort error when you undefine this ?
> Suvidh
> --- In l...@yahoogroups.com, "hschew00" wrote:
> >
> > Suvidh,
> > The stack sizes are listed as follow:
> > User/System Mode 0x0400
> > Interrupt Mode 0x0080
> >
> > The following are never used but declared as
> > Fast Interrupt Mode 0x0004
> > Abort Mode 0x0004
> > Supervisor Mode 0x0004
> > Undefined Mode 0x0004
> >
> > I am sure the code never use more than the above allocation. When
you
> > mentioned "properly alligned to 4 byte boundaries", how do I do
> > that? Shouldn't the compiler handle all these?
> > Thanks for the help.
> > Hian
> >
> >
> > --- In l...@yahoogroups.com, "suvidhk"
> > wrote:
> > >
> > >
> > >
> > > Whats are the size of your stacks.
> > > Are they properly alligned to 4 byte boundaries?
> > >
> > > Regards
> > >
> > >
> > > Suvidh
> > >
> > > --- In l...@yahoogroups.com, "Michael Anton" wrote:
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: l...@yahoogroups.com
> > > > > [mailto:l...@yahoogroups.com]On Behalf
> > > > > Of hschew00
> > > > > Sent: Monday, May 14, 2007 2:26 PM
> > > > > To: l...@yahoogroups.com
> > > > > Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues
> > > > >
> > > > >
> > > > > Mike,
> > > > > Thanks for the hint. I followed your instruction by doing
the
> > > > > following:
> > > > > 1)declare all the variables as volatile (instead of
searching
> > one by
> > > > > one in the code)
> > > > > 2)disable interrupt for USART and I2C, only enable TMR0 and
> > EXT0.
> > > > > Somehow when I disable EXT0, the compiled code size change,
and
> > hence
> > > > > memory mapping.
> > > > >
> > > > > The above changes does not change the code size. Data abort
> > occurs as
> > > > > usual at the same location. Any other idea that you can
guide
> > me?
> > > > >
> > > > > Hian
> > > > >
> > > > > --- In l...@yahoogroups.com, "Michael Anton"
wrote:
> > > >
> > > > Did you set the VIC default vector so something useful?
> > > >
> > > > Mike
> > > >
> > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: l...@yahoogroups.com
> > > > > > > [mailto:l...@yahoogroups.com]On Behalf
> > > > > > > Of hschew00
> > > > > > > Sent: Friday, May 11, 2007 7:38 PM
> > > > > > > To: l...@yahoogroups.com
> > > > > > > Subject: [lpc2000] Re: Investigation of LPC23xx MAM
Issues
> > > > > > >
> > > > > > >
> > > > > > > I am working on the LPC2132 since past January. I have
data
> > abort
> > > > > > > problem and below is the description:
> > > > > > >
> > > > > > > Compiler: Keil's CARM V2.40
> > > > > > > IDE: uVision3
> > > > > > > controller: LPC2132
> > > > > > > crystal freq: 12.288MHz
> > > > > > > PLL: enable, MSEL=4, PSEL=2
> > > > > > > MAM: fully enable, Timing = 3
> > > > > > > memory usage: code 10K, data 10K
> > > > > > >
> > > > > > > Problem: Data abort consistantly happens at the same
> > location of
> > > > > the
> > > > > > > codes, but fails to manifest itself from single-
steppping
> > through
> > > > > the
> > > > > > > codes using ULINK.
> > > > > > >
> > > > > > > Work-around: When I changed MAM Timing setting from 3
to 5-
> > 7, or
> > > > > > > disable the MAM, everything works. When compared the
> > working hex
> > > > > code
> > > > > > > with the one that didn't work, both are identical
except
> > the MAM
> > > > > byte.
> > > > > > >
> > > > > > > Enclosed at the file section with name "data abort
> > problem.zip"
> > > > > is my
> > > > > > > project for anyone who would like to dig to the bottom
to
> > find
> > > > > out if
> > > > > > > this is MAM issue, or it is just my bug in the code.
Read
> > > > > the "Read
> > > > > > > me first.pdf" to see how I duplicate the problem with
ULINK.
> > > > > > >
> > > > > > > Hian
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > I just had a quick look through your code, and noticed a
> > number of
> > > > > > things you should look at. These may or may not be
causing
> > what
> > > > > > you are seeing, but they should be looked at.
> > > > > >
> > > > > > You should probably set the default VIC vector to
something
> > useful,
> > > > > > just in case you get spurious interrupts. If you are
doing
> > this,
> > > > > > I can't find it.
> > > > > >
> > > > > > Variables that are updated inside interrupt routines, and
> > accessed
> > > > > > outside of interrupt routines should be declared as
> > volatile. Your
> > > > > > variable self_test_timer would be an example of a
variable
> > that is
> > > > > > volatile.
> > > > > >
> > > > > > The UART1 interrupt handler must do something other than
just
> > > > > respond
> > > > > > to the VIC. The interrupt flag must be cleared via some
> > other
> > > > > method,
> > > > > > depending on what triggered it.
> > > > > >
> > > > > > Given that the LPC2132 has existed for quite some time,
and
> > that
> > > > > there
> > > > > > have not been reports of MAM issues like you describe,
this
> > is
> > > > > likely
> > > > > > still a software problem. In fact, given that there
appear
> > to be
> > > > > some
> > > > > > interrupt issues, I would see if you can duplicate the
> > problem with
> > > > > > interrupts disabled.
> > > > > >
> > > > > > Others on this list may have many more suggestions (and
> > knowledge)
> > > > > > regarding this than I have, but these are a number of
issues
> > that
> > > > > > you should consider.
> > > > > >
> > > > > > Mike
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Yahoo! Groups Links
> > > > >
> > > > >
> > > > >
> > > >
> > >
>
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

The variable can definately be a problem .Because the compiler may
identify few things for it and produce a code which you may see
irrelevant.
As far your problem is considered I think it is definately somewhere
in your interrupts . Accessing locations of an array beyond its
declared value will definately give the type of behaviour you are
describing.
When this thing happens in interrupt it will be very difficult for you
to judge. The variable may somehow corrupt your stack. And the problem
may not appear (or you will not see it appear) even when you add or
delete a line of code somewhere else.

So make sure you dont have anything like this in your interrupt
routines. Make your interrupt routines perfect. It will be very easy
for you to debug any problems then.

For stack boundary I think you had not made any changes related to
stack in standard startup.s so that wont be a problem.

Suvidh
--- In l...@yahoogroups.com, "hschew00" wrote:
>
> Suvidh,
> When I undefined DEBUG_PROBLEM, I don't see the problem. The compiled
> code size is identical in both cases, but major change on the hex
> files when I compared the two. One will expect the changes should
> occur at that section, but this is not the case.
>
> I know I didn't initialize the variable "total_boiler" when
> DEBUG_PROBLEM is defined. However, from ULINK debugging, the value is
> 0 when data abort occurs.
>
> Regarding "properly alligned to 4 byte boundaries", is there anywhere
> in the codes or uvision3 environment that I need to set for this?
>
> Hian
>
> --- In l...@yahoogroups.com, "suvidhk"
> wrote:
> >
> >
> > Whats DEBUG_PROBLEM ?
> > Do You get an data abort error when you undefine this ?
> >
> >
> > Suvidh
> >
> >
> > --- In l...@yahoogroups.com, "hschew00" wrote:
> > >
> > > Suvidh,
> > > The stack sizes are listed as follow:
> > > User/System Mode 0x0400
> > > Interrupt Mode 0x0080
> > >
> > > The following are never used but declared as
> > > Fast Interrupt Mode 0x0004
> > > Abort Mode 0x0004
> > > Supervisor Mode 0x0004
> > > Undefined Mode 0x0004
> > >
> > > I am sure the code never use more than the above allocation. When
> you
> > > mentioned "properly alligned to 4 byte boundaries", how do I do
> > > that? Shouldn't the compiler handle all these?
> > > Thanks for the help.
> > > Hian
> > >
> > >
> > > --- In l...@yahoogroups.com, "suvidhk"
> > > wrote:
> > > >
> > > >
> > > >
> > > > Whats are the size of your stacks.
> > > > Are they properly alligned to 4 byte boundaries?
> > > >
> > > > Regards
> > > >
> > > >
> > > > Suvidh
> > > >
> > > > --- In l...@yahoogroups.com, "Michael Anton" wrote:
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: l...@yahoogroups.com
> > > > > > [mailto:l...@yahoogroups.com]On Behalf
> > > > > > Of hschew00
> > > > > > Sent: Monday, May 14, 2007 2:26 PM
> > > > > > To: l...@yahoogroups.com
> > > > > > Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues
> > > > > >
> > > > > >
> > > > > > Mike,
> > > > > > Thanks for the hint. I followed your instruction by doing
> the
> > > > > > following:
> > > > > > 1)declare all the variables as volatile (instead of
> searching
> > > one by
> > > > > > one in the code)
> > > > > > 2)disable interrupt for USART and I2C, only enable TMR0 and
> > > EXT0.
> > > > > > Somehow when I disable EXT0, the compiled code size change,
> and
> > > hence
> > > > > > memory mapping.
> > > > > >
> > > > > > The above changes does not change the code size. Data abort
> > > occurs as
> > > > > > usual at the same location. Any other idea that you can
> guide
> > > me?
> > > > > >
> > > > > > Hian
> > > > > >
> > > > > > --- In l...@yahoogroups.com, "Michael Anton"
> wrote:
> > > > >
> > > > > Did you set the VIC default vector so something useful?
> > > > >
> > > > > Mike
> > > > >
> > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: l...@yahoogroups.com
> > > > > > > > [mailto:l...@yahoogroups.com]On Behalf
> > > > > > > > Of hschew00
> > > > > > > > Sent: Friday, May 11, 2007 7:38 PM
> > > > > > > > To: l...@yahoogroups.com
> > > > > > > > Subject: [lpc2000] Re: Investigation of LPC23xx MAM
> Issues
> > > > > > > >
> > > > > > > >
> > > > > > > > I am working on the LPC2132 since past January. I have
> data
> > > abort
> > > > > > > > problem and below is the description:
> > > > > > > >
> > > > > > > > Compiler: Keil's CARM V2.40
> > > > > > > > IDE: uVision3
> > > > > > > > controller: LPC2132
> > > > > > > > crystal freq: 12.288MHz
> > > > > > > > PLL: enable, MSEL=4, PSEL=2
> > > > > > > > MAM: fully enable, Timing = 3
> > > > > > > > memory usage: code 10K, data 10K
> > > > > > > >
> > > > > > > > Problem: Data abort consistantly happens at the same
> > > location of
> > > > > > the
> > > > > > > > codes, but fails to manifest itself from single-
> steppping
> > > through
> > > > > > the
> > > > > > > > codes using ULINK.
> > > > > > > >
> > > > > > > > Work-around: When I changed MAM Timing setting from 3
> to 5-
> > > 7, or
> > > > > > > > disable the MAM, everything works. When compared the
> > > working hex
> > > > > > code
> > > > > > > > with the one that didn't work, both are identical
> except
> > > the MAM
> > > > > > byte.
> > > > > > > >
> > > > > > > > Enclosed at the file section with name "data abort
> > > problem.zip"
> > > > > > is my
> > > > > > > > project for anyone who would like to dig to the bottom
> to
> > > find
> > > > > > out if
> > > > > > > > this is MAM issue, or it is just my bug in the code.
> Read
> > > > > > the "Read
> > > > > > > > me first.pdf" to see how I duplicate the problem with
> ULINK.
> > > > > > > >
> > > > > > > > Hian
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > I just had a quick look through your code, and noticed a
> > > number of
> > > > > > > things you should look at. These may or may not be
> causing
> > > what
> > > > > > > you are seeing, but they should be looked at.
> > > > > > >
> > > > > > > You should probably set the default VIC vector to
> something
> > > useful,
> > > > > > > just in case you get spurious interrupts. If you are
> doing
> > > this,
> > > > > > > I can't find it.
> > > > > > >
> > > > > > > Variables that are updated inside interrupt routines, and
> > > accessed
> > > > > > > outside of interrupt routines should be declared as
> > > volatile. Your
> > > > > > > variable self_test_timer would be an example of a
> variable
> > > that is
> > > > > > > volatile.
> > > > > > >
> > > > > > > The UART1 interrupt handler must do something other than
> just
> > > > > > respond
> > > > > > > to the VIC. The interrupt flag must be cleared via some
> > > other
> > > > > > method,
> > > > > > > depending on what triggered it.
> > > > > > >
> > > > > > > Given that the LPC2132 has existed for quite some time,
> and
> > > that
> > > > > > there
> > > > > > > have not been reports of MAM issues like you describe,
> this
> > > is
> > > > > > likely
> > > > > > > still a software problem. In fact, given that there
> appear
> > > to be
> > > > > > some
> > > > > > > interrupt issues, I would see if you can duplicate the
> > > problem with
> > > > > > > interrupts disabled.
> > > > > > >
> > > > > > > Others on this list may have many more suggestions (and
> > > knowledge)
> > > > > > > regarding this than I have, but these are a number of
> issues
> > > that
> > > > > > > you should consider.
> > > > > > >
> > > > > > > Mike
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Yahoo! Groups Links
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi,

I'm attaching a mail which was sent to NXP regarding the investigation
on the potential MAM issue. Please check the files section to get the
debug session screen shots (LPC2368_MAM_Debug_session.zip):

http://f1.grp.yahoofs.com/v1/UHVdRr6OOPRwgdwVazrtrDWonvP7hF2rSdOmFbMQUTuy6qq-hVrAZsEr3gSkDmOSskDbEjuPcJAOxVob95KhA5OzlYkGD77T2w/LPC2368_MAM_Debug_session.zip

Dear Sir,

In the past week we have been trying to produce a simple test case
which demonstrates the potential faulty behavior of the LPC2368
derivate. Our research has been focused on the interaction between the
MAM module and the position of the application code inside the
internal flash of the device. Unfortunately we were unable to produce
a simple test case due to the fact that the problem seems to be
related to the position of the code, stack pointer location and the
instruction operations. However we managed to produce a test case
which lead to a erroneous behavior by just adding a "nop" into the code.

Before we get to the example I would like to point out the following
starting points:
1) The application does nothing with the peripherals up to the point
that in crashes. The only exception is setting up the PLL and MAM.
2) CPU speed is set to 72Mhz and MAMTIM=0x04. According to users
manual MAMTIM should be set to 0x03 for cclk beyond 40Mhz. But,
according to Hitex's "Insiders guide to LPC..." minimum flash access
time is 50ns (20Mhz) which guided us to set MAMTIM to 0x04 (72Mhz/4 is
< 20 Mhz).
3) The IRQ and FIQ exceptions are disabled.
4) The function that leads to the crash is called with exactly the
same input parameters in booth cases.
5) The stack is initialized and cleared to 0xFF in booth cases. The
same applies to the .bss section which is cleared to 0x00 (global
variables).
6) With MAM timing set to 7 it does not crash.
7) Based on the above statements we can conclude that our function
that causes the crash does not have a bug itself since it is called
both times with the same input parameters, the stack is filled up in
the same way and contains the same data. The same applies to the .bss
section. The only difference is one "nop" just before calling the
function. The function can't be affected by this "nop" as it simply
initializes some global variables.
8) The code without the "nop" instruction produces the undefined
instruction abort (UND) but the abort is not issued due to a badly
decoded instruction but due to the fact that the code corrupts the
stack which leads to a invalid link register when exiting the
function. The abort is than caused by jumping to an non "code" area
(in the particular case the code returns with "bx lr" to RAM).
9) Environment:
- Compiler: CodeSourcery arm-2006q3-27-arm.none-eabi.exe
- Debugger: Signum System Chameleon 2.99.16
- Device: NXP LPC2368FDB100; S61054.1 07;ZSG0711-Y

The example consist of two pictures. The first picture shows the state
of the CPU just before the instruction that is not executed properly.
The second picture shows the wrong CPU state after single stepping
through the instruction.

1) without_nop_before_LDR.jpg
The debugger shows the CPU state just before executing the LDR
instruction which is badly executed. The instruction should load R12
with the value where R5 points + 0x24 offset, thus R12 should be
loaded with the value at the address 0x40000118.

2) without_nop_after_LDR.jpg
The debugger shows the CPU state after the execution of the LDR
instruction. Please note the value of R12 which has the same value as
in the picture 1) above. It seems that the LDR instruction was not
executed. Of course this leads to stack corruption 5 instructions
later as the location pointed by R12 is written wit the value of R0
(address 0x8264).

By just adding a "nop" instruction before the call to MBX_Init
function which causes the critical LDR instruction to be located at
0x8254 and not at 0x8250 as shown in the pictures, the LDR instruction
is executed properly (R12 is loaded with 0x4000201C).

Conclusions:
1) As we see the thing there is a potential MAM problem.
2) Faulty behavior is observed only on some devices. It seems it is
part related.
3) Moving linking order seems to solve (or hide) the problem.
4) Faulty behavior could be related to JTAG interface. Scrolling the
source window seems to affect proper execution of the LDR instruction
in question.
5) To help the community the screen shots of the debug session and
comments will be posted on the Yahoo's LPC2000 forum in reply to the
"Investigation of LPC23xx MAM Issues" post.

Yours Sincerely,

Marko Panger
Aleksandar Savic
--- In l...@yahoogroups.com, "Bryce Schober" wrote:
>
> I would like to organize a cooperative investigation of the issues
> that several users are experiencing with the lpc23xx parts' MAM. I've
> directly emailed those users on this list that have previously
> reported MAM problems.
>
> First, I'd like to make it clear that I have no interest in
> NXP-bashing. They make a great product, and we believe they continue
> to have the best solution to an entire class of our product needs.
>
> Our primary goal is to identify a simple test case that can be
> reproduced on various users' configurations. Previous comments
> indicate that the problem is limited to certain parts, which my
> experience also suggests. Once we have identified a simple test case,
> and examined it for any possible bugs, all interested users can try it
> out on their systems, both those that do and do not seem vulnerable to
> this issue.
>
> To Edwin Olson: In the message here (
> http://tech.groups.yahoo.com/group/lpc2000/message/23611 ), you
> suggested that you had a simple test case. It would be extremely
> valuable as a starting point for this investigation. Please consider
> uploading it to the files area of this group. Also, to Ryan Niemi: you
> mentioned having this problem. Do you have a simple test case? I will
> also look into trying to trim down a simple test case on our "problem
> board", but if anyone else has one ready and available, please speak
> up!
>
> Our secondary goal is to pressure NXP to release an official errata
> ASAP, *if* they have known issues, as some have suggested. I have
> received personal confirmation that a new revision of silicon is in
> the works, but no details on what the differences or fixes in the
> revision are. The cost of engineering time of any delay in public
> acknowledgment of problems like these is very, very high, especially
> to the typical (to my estimation) lpc2xxx customer - small engineering
> houses.
>
> To Sashi Ono: In the message here (
> http://tech.groups.yahoo.com/group/lpc2000/message/24166 ), you
> suggested that you had direct contact with NXP representatives: "they
> reported to me that they have found the problem and have already re
> spun a new batch of silicon," confirming the existence of a known
> problem that has not yet been publicly acknowledged. Can you verify
> this assertion? If this is true, can you exert any pressure on your
> NXP contacts to publicly acknowledge this issue?
>
> Thank you all for your collaboration,
> --
> Bryce Schober
>

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Can you upload the code which produces this error so that someone can
try if it replicates on other board ?

Regards
Suvidh

--- In l...@yahoogroups.com, "Marko Panger" wrote:
>
> Hi,
>
> I'm attaching a mail which was sent to NXP regarding the investigation
> on the potential MAM issue. Please check the files section to get the
> debug session screen shots (LPC2368_MAM_Debug_session.zip):
http://f1.grp.yahoofs.com/v1/UHVdRr6OOPRwgdwVazrtrDWonvP7hF2rSdOmFbMQUTuy6qq-hVrAZsEr3gSkDmOSskDbEjuPcJAOxVob95KhA5OzlYkGD77T2w/LPC2368_MAM_Debug_session.zip
>
> Dear Sir,
>
> In the past week we have been trying to produce a simple test case
> which demonstrates the potential faulty behavior of the LPC2368
> derivate. Our research has been focused on the interaction between the
> MAM module and the position of the application code inside the
> internal flash of the device. Unfortunately we were unable to produce
> a simple test case due to the fact that the problem seems to be
> related to the position of the code, stack pointer location and the
> instruction operations. However we managed to produce a test case
> which lead to a erroneous behavior by just adding a "nop" into the code.
>
> Before we get to the example I would like to point out the following
> starting points:
> 1) The application does nothing with the peripherals up to the point
> that in crashes. The only exception is setting up the PLL and MAM.
> 2) CPU speed is set to 72Mhz and MAMTIM=0x04. According to users
> manual MAMTIM should be set to 0x03 for cclk beyond 40Mhz. But,
> according to Hitex's "Insiders guide to LPC..." minimum flash access
> time is 50ns (20Mhz) which guided us to set MAMTIM to 0x04 (72Mhz/4 is
> < 20 Mhz).
> 3) The IRQ and FIQ exceptions are disabled.
> 4) The function that leads to the crash is called with exactly the
> same input parameters in booth cases.
> 5) The stack is initialized and cleared to 0xFF in booth cases. The
> same applies to the .bss section which is cleared to 0x00 (global
> variables).
> 6) With MAM timing set to 7 it does not crash.
> 7) Based on the above statements we can conclude that our function
> that causes the crash does not have a bug itself since it is called
> both times with the same input parameters, the stack is filled up in
> the same way and contains the same data. The same applies to the .bss
> section. The only difference is one "nop" just before calling the
> function. The function can't be affected by this "nop" as it simply
> initializes some global variables.
> 8) The code without the "nop" instruction produces the undefined
> instruction abort (UND) but the abort is not issued due to a badly
> decoded instruction but due to the fact that the code corrupts the
> stack which leads to a invalid link register when exiting the
> function. The abort is than caused by jumping to an non "code" area
> (in the particular case the code returns with "bx lr" to RAM).
> 9) Environment:
> - Compiler: CodeSourcery arm-2006q3-27-arm.none-eabi.exe
> - Debugger: Signum System Chameleon 2.99.16
> - Device: NXP LPC2368FDB100; S61054.1 07;ZSG0711-Y
>
> The example consist of two pictures. The first picture shows the state
> of the CPU just before the instruction that is not executed properly.
> The second picture shows the wrong CPU state after single stepping
> through the instruction.
>
> 1) without_nop_before_LDR.jpg
> The debugger shows the CPU state just before executing the LDR
> instruction which is badly executed. The instruction should load R12
> with the value where R5 points + 0x24 offset, thus R12 should be
> loaded with the value at the address 0x40000118.
>
> 2) without_nop_after_LDR.jpg
> The debugger shows the CPU state after the execution of the LDR
> instruction. Please note the value of R12 which has the same value as
> in the picture 1) above. It seems that the LDR instruction was not
> executed. Of course this leads to stack corruption 5 instructions
> later as the location pointed by R12 is written wit the value of R0
> (address 0x8264).
>
> By just adding a "nop" instruction before the call to MBX_Init
> function which causes the critical LDR instruction to be located at
> 0x8254 and not at 0x8250 as shown in the pictures, the LDR instruction
> is executed properly (R12 is loaded with 0x4000201C).
>
> Conclusions:
> 1) As we see the thing there is a potential MAM problem.
> 2) Faulty behavior is observed only on some devices. It seems it is
> part related.
> 3) Moving linking order seems to solve (or hide) the problem.
> 4) Faulty behavior could be related to JTAG interface. Scrolling the
> source window seems to affect proper execution of the LDR instruction
> in question.
> 5) To help the community the screen shots of the debug session and
> comments will be posted on the Yahoo's LPC2000 forum in reply to the
> "Investigation of LPC23xx MAM Issues" post.
>
> Yours Sincerely,
>
> Marko Panger
> Aleksandar Savic
> --- In l...@yahoogroups.com, "Bryce Schober" wrote:
> >
> > I would like to organize a cooperative investigation of the issues
> > that several users are experiencing with the lpc23xx parts' MAM. I've
> > directly emailed those users on this list that have previously
> > reported MAM problems.
> >
> > First, I'd like to make it clear that I have no interest in
> > NXP-bashing. They make a great product, and we believe they continue
> > to have the best solution to an entire class of our product needs.
> >
> > Our primary goal is to identify a simple test case that can be
> > reproduced on various users' configurations. Previous comments
> > indicate that the problem is limited to certain parts, which my
> > experience also suggests. Once we have identified a simple test case,
> > and examined it for any possible bugs, all interested users can try it
> > out on their systems, both those that do and do not seem vulnerable to
> > this issue.
> >
> > To Edwin Olson: In the message here (
> > http://tech.groups.yahoo.com/group/lpc2000/message/23611 ), you
> > suggested that you had a simple test case. It would be extremely
> > valuable as a starting point for this investigation. Please consider
> > uploading it to the files area of this group. Also, to Ryan Niemi: you
> > mentioned having this problem. Do you have a simple test case? I will
> > also look into trying to trim down a simple test case on our "problem
> > board", but if anyone else has one ready and available, please speak
> > up!
> >
> > Our secondary goal is to pressure NXP to release an official errata
> > ASAP, *if* they have known issues, as some have suggested. I have
> > received personal confirmation that a new revision of silicon is in
> > the works, but no details on what the differences or fixes in the
> > revision are. The cost of engineering time of any delay in public
> > acknowledgment of problems like these is very, very high, especially
> > to the typical (to my estimation) lpc2xxx customer - small engineering
> > houses.
> >
> > To Sashi Ono: In the message here (
> > http://tech.groups.yahoo.com/group/lpc2000/message/24166 ), you
> > suggested that you had direct contact with NXP representatives: "they
> > reported to me that they have found the problem and have already re
> > spun a new batch of silicon," confirming the existence of a known
> > problem that has not yet been publicly acknowledged. Can you verify
> > this assertion? If this is true, can you exert any pressure on your
> > NXP contacts to publicly acknowledge this issue?
> >
> > Thank you all for your collaboration,
> > --
> > Bryce Schober
>


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hello,

I just wondering if anyone can help me with the RTC. I am currently using a
LPC2136 with an external 32K crystal connected to the RTC. I have set the
RTC source to external. It seems to be working as expected.

However, for our application we need a clock with a finer granularity than 1
second which is what the RTC provides. So I am attempted to read from the
RTC Counter and divide this by 32.768 to get a ms portion of time. Has
anyone else done this? Is this method Reliable? And can I use this method to
get the amount time it was in power down mode?

Also, does anyone know if I manually increment say the RTCSEC, and it
overflows i.e. gets to 60 will it update RTCMin, or is that my job J

Cheers,

James

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


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "James Brown" wrote:
>
> Hello,
>
>
>
> I just wondering if anyone can help me with the RTC. I am currently
using a
> LPC2136 with an external 32K crystal connected to the RTC. I have
set the
> RTC source to external. It seems to be working as expected.
>
>
>
> However, for our application we need a clock with a finer
granularity than 1
> second which is what the RTC provides. So I am attempted to read
from the
> RTC Counter and divide this by 32.768 to get a ms portion of time. Has
> anyone else done this? Is this method Reliable? And can I use this
method to
> get the amount time it was in power down mode?
>
>
>
> Also, does anyone know if I manually increment say the RTCSEC, and it
> overflows i.e. gets to 60 will it update RTCMin, or is that my job J
>
>
>
> Cheers,
>
>
>
> James
>
> [Non-text portions of this message have been removed]
>

Hi James,

I remember someone doing tests related to this subject a while ago.
Check message 19016 in this forum

Bob


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

See the thread entitled "Speed Problem on LPC2300 & LPC2101/2/" for
NXP's first public response regarding this issue. I have been working
with them offline, and now they're nearing release of an errata
document.

It is not clear that they knew about this issue before I pushed
further contact with them. Other user's implications that they did
could conceivably be the result of miscommunication about a different
silicon revision in the works for production reasons (not erratum)
that has caused the recent product shortages.

As far as workarounds go, they suggest NOPs, hopefully the errata will
be more clearer. For us, using a MAMCR value of 1 (as opposed to 2),
has resolved our erroneous behavior - though without a specific errata
I couldn't guarantee that it will fix all cases.

Their initial posting suggests that we could possibly function
correctly at 60MHz with full MAM acceleration, but we're moving on,
having already spent too much time on the problem, and not needing the
performance that badly at this time.

--
Bryce Schober

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Below is the response from NXP regarding MAM issue on LPC2132:

It is confirmed from our side that the LPC213x has MAM issue with MAM
fully enable mode.
We plan on implementing a fix on the MAM which will allow you to use
fully enable mode in the next revision.

In the meantime, with the current LPC213x devices, workaround is to
use MAM partially enable mode.
We will be publishing an errata out.....please see below for details.
We will let you know about the time schedule for next revision.

Only for MAM fully enable mode, the problem relates to condition
under which the problem can occur is dependent on the code itself
along with its positioning within the FLASH memory.
So if someone sees this failure occuring and adds one NOP or modifies
the code little bit, problem disappears.
In the discussion forum you mentioned, its possible that most
engineers might have seen this problem in the past but when they
change their code to the slightest extent,
problem disappeared and they must have moved on and not consider it
an issue.

Amish Desai
Applications Engieer

--- In l...@yahoogroups.com, "hschew00" wrote:
>
> Suvidh,
> When I undefined DEBUG_PROBLEM, I don't see the problem. The
compiled
> code size is identical in both cases, but major change on the hex
> files when I compared the two. One will expect the changes should
> occur at that section, but this is not the case.
>
> I know I didn't initialize the variable "total_boiler" when
> DEBUG_PROBLEM is defined. However, from ULINK debugging, the value
is
> 0 when data abort occurs.
>
> Regarding "properly alligned to 4 byte boundaries", is there
anywhere
> in the codes or uvision3 environment that I need to set for this?
>
> Hian
>
> --- In l...@yahoogroups.com, "suvidhk"
> wrote:
> >
> >
> > Whats DEBUG_PROBLEM ?
> > Do You get an data abort error when you undefine this ?
> >
> >
> > Suvidh
> >
> >
> > --- In l...@yahoogroups.com, "hschew00" wrote:
> > >
> > > Suvidh,
> > > The stack sizes are listed as follow:
> > > User/System Mode 0x0400
> > > Interrupt Mode 0x0080
> > >
> > > The following are never used but declared as
> > > Fast Interrupt Mode 0x0004
> > > Abort Mode 0x0004
> > > Supervisor Mode 0x0004
> > > Undefined Mode 0x0004
> > >
> > > I am sure the code never use more than the above allocation.
When
> you
> > > mentioned "properly alligned to 4 byte boundaries", how do I
do
> > > that? Shouldn't the compiler handle all these?
> > > Thanks for the help.
> > > Hian
> > >
> > >
> > > --- In l...@yahoogroups.com, "suvidhk"
> > > wrote:
> > > >
> > > >
> > > >
> > > > Whats are the size of your stacks.
> > > > Are they properly alligned to 4 byte boundaries?
> > > >
> > > > Regards
> > > >
> > > >
> > > > Suvidh
> > > >
> > > > --- In l...@yahoogroups.com, "Michael Anton"
wrote:
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: l...@yahoogroups.com
> > > > > > [mailto:l...@yahoogroups.com]On Behalf
> > > > > > Of hschew00
> > > > > > Sent: Monday, May 14, 2007 2:26 PM
> > > > > > To: l...@yahoogroups.com
> > > > > > Subject: [lpc2000] Re: Investigation of LPC23xx MAM Issues
> > > > > >
> > > > > >
> > > > > > Mike,
> > > > > > Thanks for the hint. I followed your instruction by doing
> the
> > > > > > following:
> > > > > > 1)declare all the variables as volatile (instead of
> searching
> > > one by
> > > > > > one in the code)
> > > > > > 2)disable interrupt for USART and I2C, only enable TMR0
and
> > > EXT0.
> > > > > > Somehow when I disable EXT0, the compiled code size
change,
> and
> > > hence
> > > > > > memory mapping.
> > > > > >
> > > > > > The above changes does not change the code size. Data
abort
> > > occurs as
> > > > > > usual at the same location. Any other idea that you can
> guide
> > > me?
> > > > > >
> > > > > > Hian
> > > > > >
> > > > > > --- In l...@yahoogroups.com, "Michael Anton"
> wrote:
> > > > >
> > > > > Did you set the VIC default vector so something useful?
> > > > >
> > > > > Mike
> > > > >
> > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: l...@yahoogroups.com
> > > > > > > > [mailto:l...@yahoogroups.com]On Behalf
> > > > > > > > Of hschew00
> > > > > > > > Sent: Friday, May 11, 2007 7:38 PM
> > > > > > > > To: l...@yahoogroups.com
> > > > > > > > Subject: [lpc2000] Re: Investigation of LPC23xx MAM
> Issues
> > > > > > > >
> > > > > > > >
> > > > > > > > I am working on the LPC2132 since past January. I
have
> data
> > > abort
> > > > > > > > problem and below is the description:
> > > > > > > >
> > > > > > > > Compiler: Keil's CARM V2.40
> > > > > > > > IDE: uVision3
> > > > > > > > controller: LPC2132
> > > > > > > > crystal freq: 12.288MHz
> > > > > > > > PLL: enable, MSEL=4, PSEL=2
> > > > > > > > MAM: fully enable, Timing = 3
> > > > > > > > memory usage: code 10K, data 10K
> > > > > > > >
> > > > > > > > Problem: Data abort consistantly happens at the same
> > > location of
> > > > > > the
> > > > > > > > codes, but fails to manifest itself from single-
> steppping
> > > through
> > > > > > the
> > > > > > > > codes using ULINK.
> > > > > > > >
> > > > > > > > Work-around: When I changed MAM Timing setting from 3
> to 5-
> > > 7, or
> > > > > > > > disable the MAM, everything works. When compared the
> > > working hex
> > > > > > code
> > > > > > > > with the one that didn't work, both are identical
> except
> > > the MAM
> > > > > > byte.
> > > > > > > >
> > > > > > > > Enclosed at the file section with name "data abort
> > > problem.zip"
> > > > > > is my
> > > > > > > > project for anyone who would like to dig to the
bottom
> to
> > > find
> > > > > > out if
> > > > > > > > this is MAM issue, or it is just my bug in the code.
> Read
> > > > > > the "Read
> > > > > > > > me first.pdf" to see how I duplicate the problem with
> ULINK.
> > > > > > > >
> > > > > > > > Hian
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > I just had a quick look through your code, and noticed
a
> > > number of
> > > > > > > things you should look at. These may or may not be
> causing
> > > what
> > > > > > > you are seeing, but they should be looked at.
> > > > > > >
> > > > > > > You should probably set the default VIC vector to
> something
> > > useful,
> > > > > > > just in case you get spurious interrupts. If you are
> doing
> > > this,
> > > > > > > I can't find it.
> > > > > > >
> > > > > > > Variables that are updated inside interrupt routines,
and
> > > accessed
> > > > > > > outside of interrupt routines should be declared as
> > > volatile. Your
> > > > > > > variable self_test_timer would be an example of a
> variable
> > > that is
> > > > > > > volatile.
> > > > > > >
> > > > > > > The UART1 interrupt handler must do something other
than
> just
> > > > > > respond
> > > > > > > to the VIC. The interrupt flag must be cleared via
some
> > > other
> > > > > > method,
> > > > > > > depending on what triggered it.
> > > > > > >
> > > > > > > Given that the LPC2132 has existed for quite some time,
> and
> > > that
> > > > > > there
> > > > > > > have not been reports of MAM issues like you describe,
> this
> > > is
> > > > > > likely
> > > > > > > still a software problem. In fact, given that there
> appear
> > > to be
> > > > > > some
> > > > > > > interrupt issues, I would see if you can duplicate the
> > > problem with
> > > > > > > interrupts disabled.
> > > > > > >
> > > > > > > Others on this list may have many more suggestions (and
> > > knowledge)
> > > > > > > regarding this than I have, but these are a number of
> issues
> > > that
> > > > > > > you should consider.
> > > > > > >
> > > > > > > Mike
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Yahoo! Groups Links
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
>


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On Tue, 10 Jul 2007 00:29:23 -0000, you wrote:

>Below is the response from NXP regarding MAM issue on LPC2132:
>
>It is confirmed from our side that the LPC213x has MAM issue with MAM
>fully enable mode.
>We plan on implementing a fix on the MAM which will allow you to use
>fully enable mode in the next revision.
>
>In the meantime, with the current LPC213x devices, workaround is to
>use MAM partially enable mode.
>We will be publishing an errata out.....please see below for details.
>We will let you know about the time schedule for next revision.
>
>Only for MAM fully enable mode, the problem relates to condition
>under which the problem can occur is dependent on the code itself
>along with its positioning within the FLASH memory.
>So if someone sees this failure occuring and adds one NOP or modifies
>the code little bit, problem disappears.
>In the discussion forum you mentioned, its possible that most
>engineers might have seen this problem in the past but when they
>change their code to the slightest extent,
>problem disappeared and they must have moved on and not consider it
>an issue.
>
>Amish Desai
>Applications Engieer

This is mentioned in this errata document, dated June 8th
http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/errata.lpc2136.01.pdf

Unfortunately this document does NOT appear in the list of docs on the product page - you have to
actively search for it by searching for "lpc2136 erratasheet"

And as this sheet is for the 2136/01, the absence of this sheet on the main product page might imply
that the problem is new to the /01 variants - from what I recall of the origianl thread this is not
the case.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> This is mentioned in this errata document, dated June 8th
>
http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/errata.lpc2136.01.pdf
>
> Unfortunately this document does NOT appear in the list of docs on
the product page - you have to
> actively search for it by searching for "lpc2136 erratasheet"
>
> And as this sheet is for the 2136/01, the absence of this sheet on
the main product page might imply
> that the problem is new to the /01 variants - from what I recall of
the origianl thread this is not
> the case.
>

In light of the above problems, I've looked for an updated version of
the errata sheet for the LPC2148 which we use, and found the same
issue mentioned for this chip, as a new addition. The new errata was
published on the 8th June. Because of the lack of information given in
the errata sheet I can assume the only safe option is to always set
MAMCR to either 0 or 1, and take the performance hit. :-(

I'm using Rowley Crossworks and this is very easy to do by defining
MAMCR_VAL = 1 in the Solution, common, preprocessor, properties.

The errata states that this bug is in REV A and REV B versions of the
chip.

What are other peoples thoughts on this problem? Without regression
testing after every code change you cannot be sure that a simple code
edit will not cause this problem.

Regards

Martin Honeywill


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Martin Honeywill"
> What are other peoples thoughts on this problem? Without regression
> testing after every code change you cannot be sure that a simple
code
> edit will not cause this problem.
>

My thought is that it is a disastrous problem: it's not properly
charecterised (i.e. if you do X and Y then Z happens), so there's no
way you can avoid it (other than to avoid using the relevant MAM
setting). Saying that it happens when some code runs at some
locations or whatever isn't definitife enough.

Regression testing everything after each code change is not viable
for most products.

I wouldn't even consider using the part in a mode where the problem
might assert itself.

Just my opinion, of course...

Brendan.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Brendan Murphy"
wrote:
>
> --- In l...@yahoogroups.com, "Martin Honeywill"
> > What are other peoples thoughts on this problem? Without regression
> > testing after every code change you cannot be sure that a simple
> code
> > edit will not cause this problem.
> > My thought is that it is a disastrous problem: it's not properly
> charecterised (i.e. if you do X and Y then Z happens), so there's no
> way you can avoid it (other than to avoid using the relevant MAM
> setting). Saying that it happens when some code runs at some
> locations or whatever isn't definitife enough.
>
> Regression testing everything after each code change is not viable
> for most products.
>
> I wouldn't even consider using the part in a mode where the problem
> might assert itself.
>
> Just my opinion, of course...
>
> Brendan.
>

Just a note:

When I was working with IAR on this problem going back 2/1/06 with
Mark Moran who was working with someone at Philips, I believe they
only mentioned that the "startup" needs to have the MAM set and then
when it jumps to main then the MAM can be set to FULLY on.

I have checked the latest IAR cstartup assembly code and found that
they added the following code for all processors:

Add initialization needed before setup of stack pointers here

; LPC2148 Errata
; Date: August 5, 2005
; Document Release: Version 1.0
; Device Affected: LPC2148
; Incorrect read of data from SRAM after Reset and MAM is not enabled
or partially enabled MAM.1
; Init MAM before acsses to SRAM

ldr r0,=MAMCR
ldr r1,=MAMTIM
ldr r2,=0
str r2,[r0]
ldr r2,=7
str r2,[r1]
ldr r2,=2
str r2,[r0]

regards,
Charles



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>
> My thought is that it is a disastrous problem: it's not properly
> charecterised (i.e. if you do X and Y then Z happens), so there's no
> way you can avoid it (other than to avoid using the relevant MAM
> setting). Saying that it happens when some code runs at some
> locations or whatever isn't definitife enough.
>
> Regression testing everything after each code change is not viable
> for most products.
>
> I wouldn't even consider using the part in a mode where the problem
> might assert itself.
>
> Just my opinion, of course...
>
> Brendan.
>

And my opinion too, I would suggest MAMCR should NEVER be set to 2,
This could be the cause of unexplained problems I've had before and
spent days trying to fix and never been able to trace properly.

I wish NXP would just say don't use the MAM in mode 2 in their errata.

An earlier version of our product was based on the LPC2129 and I
wonder if this chip has the same problem, as its errata sheet has not
been updated since may 2006. My guess is that this chip is ok because
the MAM fault only effects Revisions C and D of the LPC213x chips.
Implying that the fault was introduced with a silicon update to the
core chip design and this fault was propagated through to all new
members of the LPC range. LPC214x, LPC236x etc.

As there is no way for our code to tell which revision of the chip it
is running on when will have to assume that MAMCR will always have to
be set to 1, even if this problem is fixed in a later revision of the
chip.

Here is a link to the latest LPC2148 errata sheet
http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/errata.lpc2148.pdf

If you look at this errata it has a fault MAM.1 with revision - of the
chips, the fix for this is to set MAMCR to 2. Then there is the MAM.2
fault referred to above and the fix is to set MAMCR to 0 or 1. I.e.
the fixes are mutually exclusive.

I would suggest people look very carefully at which revision of chip
they are using, maybe the version of boot loader might be a way of
telling which revision of chip you have?

Cheers

Martin



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On Tue, Jul 10, 2007 at 12:39:21PM -0000, Martin Honeywill wrote:
[snip]
> Here is a link to the latest LPC2148 errata sheet
> http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/errata.lpc2148.pdf
>
> If you look at this errata it has a fault MAM.1 with revision - of the
> chips, the fix for this is to set MAMCR to 2. Then there is the MAM.2
> fault referred to above and the fix is to set MAMCR to 0 or 1. I.e.
> the fixes are mutually exclusive.
>
> I would suggest people look very carefully at which revision of chip
> they are using, maybe the version of boot loader might be a way of
> telling which revision of chip you have?

Crikey! Can someone (ideally NXP) comment on bootloader versions to distinguish
lpc2138 device revisions "-,A,B" from "C,D" please??

Alternately is there a simple test case (a couple of lines of assembler perhaps,
ideally for gcc/as) that can be used to determine the chip revision that I can
incorporate into my startup code to ultimately setup the MAM correctly?

I have products in the field that I'd like to upgrade without requiring users to
open up boxes to stare at chip revisions to decide which software to load!

Thank you,

--Craig



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

You're suggestion to be able to have the code determine chip
revision, does not solve the problem!

On the LPC2138, both MAM.1 bug (which requires mode 2 to workaround),
and MAM.2 bug (which requires other than mode 2 to workaround) exist
on the -, A, and B chip revisions. Assuming the code could read the
revision (which apparently it can't), what would you do if you found
it was rev B? No MAM mode is reliable on these chips!!!

We have a lot of product in the field with LPC2138 (including chips
with rev A and B). The present code runs with MAM mode 2, because at
the time of development we experienced the MAM.1 bug. To my
knowledge, we have never experienced the MAM.2 problem in this
product, but we are about to release a firmware upgrade. It seems
that we are in a Catch-22 regarding what MAM setting to use.

Is there any other workaround to either of these bugs, which would
allow use of the other MAM settings?

The errata says "The conditions under which the problem can occur is
dependent on the code itself along with its positioning within the
Flash memory". Is there any reliable way to tell whether we will
encounter this probllem? For instance:

When the problem occurs, will it always crash the processor, or is it
possible it might just incorrectly execute some line of code -
resulting in a subtle execution error?

Could the problem only occur if I execute a specific line of code,
which might be executed very rarely?

If the problem occurs, will it occur all the time, or might it be
intermittent (depending on temperature, subtle timing issue, etc.)?

If the problem occurs, will it occur on every chip, or might it occur
on some but not others?

In other words, if I run my code on one unit here, and I don't see a
problem can I be sure everything is OK? Or might it still show up in
the field?

HELP!!!
--- In l...@yahoogroups.com, Craig Schlenter
wrote:
>
> On Tue, Jul 10, 2007 at 12:39:21PM -0000, Martin Honeywill wrote:
> [snip]
> > Here is a link to the latest LPC2148 errata sheet
> >
http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/
errata.lpc2148.pdf
> >
> > If you look at this errata it has a fault MAM.1 with revision -
of the
> > chips, the fix for this is to set MAMCR to 2. Then there is the
MAM.2
> > fault referred to above and the fix is to set MAMCR to 0 or 1.
I.e.
> > the fixes are mutually exclusive.
> >
> > I would suggest people look very carefully at which revision of
chip
> > they are using, maybe the version of boot loader might be a way of
> > telling which revision of chip you have?
>
> Crikey! Can someone (ideally NXP) comment on bootloader versions to
distinguish
> lpc2138 device revisions "-,A,B" from "C,D" please??
>
> Alternately is there a simple test case (a couple of lines of
assembler perhaps,
> ideally for gcc/as) that can be used to determine the chip revision
that I can
> incorporate into my startup code to ultimately setup the MAM
correctly?
>
> I have products in the field that I'd like to upgrade without
requiring users to
> open up boxes to stare at chip revisions to decide which software
to load!
>
> Thank you,
>
> --Craig
>

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> The errata says "The conditions under which the problem can occur is
> dependent on the code itself along with its positioning within the
> Flash memory".
Yeah, what a cop-out. That's got to be the most cryptically useless
errata ever. Thanks NXP!

> When the problem occurs, will it always crash the processor, or is it
> possible it might just incorrectly execute some line of code -
> resulting in a subtle execution error?
>
My experiences on LPC2378 are that execution is subtly affected-- as
though a read is corrupted when read from flash. The vast majority of
these do NOT seem to cause an illegal instruction exception.

> Could the problem only occur if I execute a specific line of code,
> which might be executed very rarely?
>
Yes!
> If the problem occurs, will it occur all the time, or might it be
> intermittent (depending on temperature, subtle timing issue, etc.)?
>
The problem on LPC2378 was intermittent, but occurred relatively
frequently if it was going to occur at all.

> If the problem occurs, will it occur on every chip, or might it occur
> on some but not others?
>
Yes again. We anecdotally found several of our boards to work just fine,
and others exhibited the problem. Our development board population was
~20, and about 4 had the problem bad enough for us to recognize the
symptoms.

> In other words, if I run my code on one unit here, and I don't see a
> problem can I be sure everything is OK? Or might it still show up in
> the field?
>
Yeah, you're screwed. We run our parts at low speed with MAM=1 (which on
LPC2378 seems pretty conservative). You might have to disable MAM
altogether depending on how the errata goes with LPC21xx.

-Ed


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On Wed, Sep 26, 2007 at 05:26:37PM -0000, lp2000c wrote:
> You're suggestion to be able to have the code determine chip
> revision, does not solve the problem!

I disagree, see below.

> On the LPC2138, both MAM.1 bug (which requires mode 2 to workaround),
> and MAM.2 bug (which requires other than mode 2 to workaround) exist
> on the -, A, and B chip revisions.

Not according to the errata I am reading. MAM.1 affects -, A and B.
MAM2 affects C and D. See page 4 of the June 8 2007 lpc2138 errata
sheet (version 1.7). Revision B is thus only crippled by MAM.1
according to my reading of the errata.

Is there a later version or did I miss something?

[snip]
> The errata says "The conditions under which the problem can occur is
> dependent on the code itself along with its positioning within the
> Flash memory". Is there any reliable way to tell whether we will
> encounter this probllem? For instance:

I haven't encountered either problem that I am aware of but I fear
that changing a line of code somewhere may trigger problems. I am
very unhappy with NXP for not releasing proper details of how to
determine which chip revision we are running with - I have product
in the field and without opening up units we can't determine what
revision is in use. It should be a simple matter for someone that
actually has details of the bug (which at this point is only
NXP!) to throw together some assembler code for the startup of the
chip to choose the right MAM mode or at least provide sufficient
detail so that someone else can.

I wish I could answer your other questions but I can't without more
detail from NXP.

Come on NXP!!!!! This isn't rocket science!!! There have been
repeated calls for help on this matter and there has been no
response! Maybe it's time for me to move to another processor
where the support is actually reasonable ...

Thanks,

--Craig

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi,

I have downloaded the IAR WorkBench 4.42 IDE 30 day limited version and
found it doesn't create a HEX file.

May I ask a question: how can I burn the project's output file ( should be a
HEX file) onto LPC2148 flash?

I use an evaluation board UNI_DS3 of Mikroelektronika Company ( with MCU
LPC2148 stuffed ).

There is no a problem to do it with Keil's uVision3.

Thanks.

With best regards,

Arthur Khachatryan.

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


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Well here the MAM give us quite a problem. The the problem was easy to see,=
as the program went totally out of control, the worst situation was on a u=
ncondional branch instruction (ie: B 0x7FFF0000), the program just passed t=
rough the branch and continue do execute without braching. There wher many =
other strange things hapening when the MAM was enable. But the program work=
just fine if you partially enable the MAM, and put CPU on a frequency limi=
ted to 48MHz.
=20=20=20
Regards,=20
Fernando Almeida.
=20=20=20
=20=20
Edwin Olson escreveu:
=20=20=20=20=20=20=20=20=20=20
> The errata says "The conditions under which the problem can occur is=20
> dependent on the code itself along with its positioning within the=20
> Flash memory".=20
Yeah, what a cop-out. That's got to be the most cryptically useless=20
errata ever. Thanks NXP!

> When the problem occurs, will it always crash the processor, or is it=20
> possible it might just incorrectly execute some line of code -=20
> resulting in a subtle execution error?
>=20
My experiences on LPC2378 are that execution is subtly affected-- as=20
though a read is corrupted when read from flash. The vast majority of=20
these do NOT seem to cause an illegal instruction exception.

> Could the problem only occur if I execute a specific line of code,=20
> which might be executed very rarely?
>=20
Yes!
> If the problem occurs, will it occur all the time, or might it be=20
> intermittent (depending on temperature, subtle timing issue, etc.)?
>=20
The problem on LPC2378 was intermittent, but occurred relatively=20
frequently if it was going to occur at all.

> If the problem occurs, will it occur on every chip, or might it occur=20
> on some but not others?
>=20
Yes again. We anecdotally found several of our boards to work just fine,=20
and others exhibited the problem. Our development board population was=20
~20, and about 4 had the problem bad enough for us to recognize the=20
symptoms.

> In other words, if I run my code on one unit here, and I don't see a=20
> problem can I be sure everything is OK? Or might it still show up in=20
> the field?
>=20
Yeah, you're screwed. We run our parts at low speed with MAM=3D1 (which on=
=20
LPC2378 seems pretty conservative). You might have to disable MAM=20
altogether depending on how the errata goes with LPC21xx.

-Ed

=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20

Flickr agora em portugu=EAs. Voc=EA clica, todo mundo v=EA. Saiba ma=
is.

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

=20

=20


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Fernando Augusto wrote:
> Well here the MAM give us quite a problem. The the problem was easy to see, as the program went totally out of control, the worst situation was on a uncondional branch instruction (ie: B 0x7FFF0000), the program just passed trough the branch and continue do execute without braching. There wher many other strange things hapening when the MAM was enable. But the program work just fine if you partially e
I had similar problems with MAM on LPC2103/01.
There were situations that triggered CPU in program abort when MAM=2 at
60 MHz.
Setting MAM=1 solved the problems...

NXP, please tell us what is going on!

Regards,
Aleš

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, Craig Schlenter
wrote:
[snip]
> Not according to the errata I am reading. MAM.1 affects -, A and B.
> MAM2 affects C and D. See page 4 of the June 8 2007 lpc2138 errata
> sheet (version 1.7). Revision B is thus only crippled by MAM.1
> according to my reading of the errata.
>
> Is there a later version or did I miss something?
>

There is a later version.

In Version 1.8 of the LPC2138 Erratasheet (July 9, 2007), "Errata
history table for MAM.2 was updated".

They now show the MAM.2 bug affecting versions: -, A, B, C, D (i.e.:
all versions of this chip).

Thus versions -, A, and B of this chip are affected by both MAM.1 and
MAM.2, with mutually exclusive workarounds!

This Erratasheet is available at:
http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/
errata.lpc2138.pdf



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On Mon, Oct 01, 2007 at 05:28:30PM -0000, lp2000c wrote:
> --- In l...@yahoogroups.com, Craig Schlenter
> wrote:
> [snip]
> > Not according to the errata I am reading. MAM.1 affects -, A and B.
> > MAM2 affects C and D. See page 4 of the June 8 2007 lpc2138 errata
> > sheet (version 1.7). Revision B is thus only crippled by MAM.1
> > according to my reading of the errata.
> >
> > Is there a later version or did I miss something?
> > There is a later version.
>
> In Version 1.8 of the LPC2138 Erratasheet (July 9, 2007), "Errata
> history table for MAM.2 was updated".
>
> They now show the MAM.2 bug affecting versions: -, A, B, C, D (i.e.:
> all versions of this chip).
>
> Thus versions -, A, and B of this chip are affected by both MAM.1 and
> MAM.2, with mutually exclusive workarounds!
>
> This Erratasheet is available at:
> http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/errata.lpc2138.pdf

Yikes!!!!!!! :-(

I submitted a query to NXP through their website (before I saw your
mail) and they said that "MAM.1 & MAM.2 are speed sensitive paths that
may work on some parts and not on others. They are not hard failures
on those die revs". So the only way to figure out which part it is is
by looking at the mark on the part itself :(

Thanks!

--Craig

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Marko Panger" wrote:
[snip]
> 6) With MAM timing set to 7 it does not crash.

Philips:

Is it so that increasing the MAMTIM setting is a reliable workaround
for this bug?
If so, what value does it need to be increased to for a given CCLK
frequency?
Is this the same for all LPC2000 family processors?

Anyone else have experience with this solving the problem?

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On Mon, Oct 01, 2007 at 05:28:30PM -0000, lp2000c wrote:
> --- In l...@yahoogroups.com, Craig Schlenter
> wrote:
> [snip]
> > Not according to the errata I am reading. MAM.1 affects -, A and B.
> > MAM2 affects C and D. See page 4 of the June 8 2007 lpc2138 errata
> > sheet (version 1.7). Revision B is thus only crippled by MAM.1
> > according to my reading of the errata.
> >
> > Is there a later version or did I miss something?
> > There is a later version.
>
> In Version 1.8 of the LPC2138 Erratasheet (July 9, 2007), "Errata
> history table for MAM.2 was updated".
>
> They now show the MAM.2 bug affecting versions: -, A, B, C, D (i.e.:
> all versions of this chip).
>
> Thus versions -, A, and B of this chip are affected by both MAM.1 and
> MAM.2, with mutually exclusive workarounds!
>
> This Erratasheet is available at:
> http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/errata.lpc2138.pdf

I got an answer from NXP on this btw. (the www.nxp.com/support people are
quick and helpful). The recommended approach is to fully enable the MAM
as per MAM.1 but to run at < 60MHz to avoid MAM.2.

bye,

--Craig



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On Fri, 5 Oct 2007, Craig Schlenter wrote:

> The recommended approach is to fully enable the MAM as per MAM.1 but to
> run at < 60MHz to avoid MAM.2.

Uh oh ... did they say how much less makes a difference?

-Kenny

--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Los Angeles
O: 3630 S. Sepulveda Blvd. #138, L.A., CA 90034-6809 (888) 454-8181



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On 05 Oct 2007, at 5:12 PM, Kenneth Crudup wrote:
>
> On Fri, 5 Oct 2007, Craig Schlenter wrote:
>
>> The recommended approach is to fully enable the MAM as per MAM.1
>> but to
>> run at < 60MHz to avoid MAM.2.
>
> Uh oh ... did they say how much less makes a difference?

Nope ... the reply I got said "< 60Mhz" but remember that not every
application
and/or die will be affected. I've seen no evidence of the problem in
my application
for example running at 60Mhz on several different chip revisions of
the 2138 but
I've cut back to 48Mhz (M=4 instead of M=5 for the PLL) just in case.

bye,

--Craig

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On Fri, 5 Oct 2007, Craig Schlenter wrote:

> ... but remember that not every application and/or die will be affected.

Is it a "you'll know right away" kind of thing, or more of an "one day,
it'll just up and die on you" kind of thing? I'd *reallllly* like both
MAM2 *and* 60MHz (gotta do some FP in my customer's app), but I don't
want them dying once I release these products into the wild.

-Kenny

--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Los Angeles
O: 3630 S. Sepulveda Blvd. #138, L.A., CA 90034-6809 (888) 454-8181



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On 05 Oct 2007, at 8:01 PM, Kenneth Crudup wrote:

>
> On Fri, 5 Oct 2007, Craig Schlenter wrote:
>
>> ... but remember that not every application and/or die will be
>> affected.
>
> Is it a "you'll know right away" kind of thing, or more of an "one
> day,
> it'll just up and die on you" kind of thing? I'd *reallllly* like both
> MAM2 *and* 60MHz (gotta do some FP in my customer's app), but I don't
> want them dying once I release these products into the wild.

What chip revisions? Remember that my problem is that I have early
chip revisions that theoretically could exhibit both MAM.1 and MAM.2
so for me I wanted an answer to the conflicting information in the
errata
as to how to solve the problem. If you are only affected by MAM.2 then
partially enabling the MAM as the errata suggests could be faster/better
in your app than slowing down to less than 60Mhz? Also MAM.2 is,
according to the errata, dependent on the code and the positioning
in the flash thus you could probably get a fair degree of confidence
if you
ensure 100% test coverage of your code base without seeing problems
but I'm really not the best person to be asking this ... I merely have a
couple of random snippets of info gleaned from nxp.com/support that
I wanted to share with the group - the most important one being that
nxp.com/support is more responsive than nxp is to postings in this
group so I'd suggest trying to get more detail from there if the
information
in the errata doesn't help.

I'll be slowing my app down to 48Mhz (M=4 instead of 5 on the PLL)
because my app isn't speed dependent and I'll sleep better at night
even though I haven't seen MAM.2 problems in my application at
the moment.

bye,

--Craig



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Our usage of the lpc2364 showed that we could only get reliable performance
at the upper end of the temperature spec if we ran at 48 MHz and MAMCR=1.
We're using a 32kHz crystal for the clock source and we need to ship soon
and could only get rev '-' parts. With the Fcco limitation of 290 MHz and
the absence of even dividers in CCLKSEL (!!!!), the highest output clock is
48MHz. Oh, and our USBDemon debuggers aren't very stable at those settings,
for some reason, even at slower JTAG clocks.

Note that we only saw the additional instability at higher (but within spec)
temperatures, so you can't make any assumptions about stability based on
your normal bench-testing setup. The bottom line is that you must severely
limit the performance in order to be safe, unless you can wait for a newer
silicon rev. If you can wait, do!

On 10/5/07, Craig Schlenter wrote:
>
> On 05 Oct 2007, at 8:01 PM, Kenneth Crudup wrote:
>
> >
> > On Fri, 5 Oct 2007, Craig Schlenter wrote:
> >
> >> ... but remember that not every application and/or die will be
> >> affected.
> >
> > Is it a "you'll know right away" kind of thing, or more of an "one
> > day,
> > it'll just up and die on you" kind of thing? I'd *reallllly* like both
> > MAM2 *and* 60MHz (gotta do some FP in my customer's app), but I don't
> > want them dying once I release these products into the wild.
>
> What chip revisions? Remember that my problem is that I have early
> chip revisions that theoretically could exhibit both MAM.1 and MAM.2
> so for me I wanted an answer to the conflicting information in the
> errata
> as to how to solve the problem. If you are only affected by MAM.2 then
> partially enabling the MAM as the errata suggests could be faster/better
> in your app than slowing down to less than 60Mhz? Also MAM.2 is,
> according to the errata, dependent on the code and the positioning
> in the flash thus you could probably get a fair degree of confidence
> if you
> ensure 100% test coverage of your code base without seeing problems
> but I'm really not the best person to be asking this ... I merely have a
> couple of random snippets of info gleaned from nxp.com/support that
> I wanted to share with the group - the most important one being that
> nxp.com/support is more responsive than nxp is to postings in this
> group so I'd suggest trying to get more detail from there if the
> information
> in the errata doesn't help.
>
> I'll be slowing my app down to 48Mhz (M=4 instead of 5 on the PLL)
> because my app isn't speed dependent and I'll sleep better at night
> even though I haven't seen MAM.2 problems in my application at
> the moment.
>
> bye,
>
> --Craig



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

The published NXP eratta on this issue, say that the workaround is to
set MAMCR to 1 (or 0).

However, some posts on this site claim, or imply, that doing so will
not fix the problem, unless the frequency is also lowered.

Also, some posts claim, or imply, that lowering the frequency will
fix the problem, even if MAMCR=2. (Some even claim that NXP told
them this.) They differ as to whether frequency needs to be lowered
below 60 MHz or 48 MHz.

See the snips of posts below for details.

Can the people who posted these items, or anyone else, provide any
more insight into these contradictions?

Is it possible that the workaround is different for different members
of the LPC2000 family?

--- In Message #28222, "Bryce Schober" wrote:
>
> Our usage of the lpc2364 showed that we could only get reliable
performance
> at the upper end of the temperature spec if we ran at 48 MHz and
MAMCR=1.

Bryce:

The published errata says that setting MMACR=1 should solve the
problem at any frequency. Do I understand correctly from your post,
that you did not try at higher frequency (because of unrelated
issues), and you have no reason to believe that it will not work with
MAMCR=1 at higher frequencies?

Do I also understand correctly that at 48MHz, you had problems with
MAMCR=2?
--- In Message #28121, Craig Schlenter wrote:
> I got an answer from NXP on this btw. (the www.nxp.com/support
people are
> quick and helpful). The recommended approach is to fully enable the
MAM
> as per MAM.1 but to run at < 60MHz to avoid MAM.2.

Craig:

This seems to contradict what Bryce found above, and what Edwin found
below. Are they saying this for only LPC2138, or LPC2364, as well?
Are they willing to put something in writing?
--- In Message #27842, Fernando Augusto wrote:
>
> But the program work just fine if you partially enable the MAM, and
put CPU on a frequency limited to 48MHz.

Fernando:

Did you try MAMCR=1 at higher frequency? Did you try 48MHz with
MAMCR=2? If so, what were results?
Which chip are you using?

--- In Message #24866, "jayasooriah" wrote:
> This appears to occur when: a) CCLK > 48
> MHz; b) MAM is enabled; and c) when higher order address bits are
set.

Jaya:

You seem to be saying that at CCLK =< 48 MHz, there is no problem.
This seems to be contradicted by some of the other findings above.
What is your basis for this information?

--- In Message #23611, Edwin Olson wrote:
> Also, setting MAMCR=1 ("partially
> enabled") also seems to change the nature of the failure, but it
still
> fails.
>
> If I reduce the CPU clock all the way down to 48MHz, even
configuration
> B starts working. (57 MHz still does NOT work).
>

Edwin:
You state that setting MAMCR=1, does not fix the problem. This
contradicts the published workaround in the errata. Your post was
from a while ago, do you still believe this to be the case?

You also say that lowering the frequency below 60 MHz did not fix.
This contradicts what Craig says he was told by NXP, above.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Note: This is all as regards the 236x, the only series we're currently
testing thoroughly.

On 10/8/07, lp2000c wrote:
>
> --- In Message #28222, "Bryce Schober" wrote:
> >
> > Our usage of the lpc2364 showed that we could only get reliable
> performance
> > at the upper end of the temperature spec if we ran at 48 MHz and
> MAMCR=1.
>
> Bryce:
>
> The published errata says that setting MMACR=1 should solve the
> problem at any frequency. Do I understand correctly from your post,
> that you did not try at higher frequency (because of unrelated
> issues), and you have no reason to believe that it will not work with
> MAMCR=1 at higher frequencies?
No, in fact we were running at 72MHz (288/4) and MAMCR=1 (for errata MAM.1)
successfully until we performed our temperature qualification. Then we
contacted NXP and they informed us that the clock speed must also be below
60 MHz (published as errata Flash.1).

Do I also understand correctly that at 48MHz, you had problems with
> MAMCR=2?
>

I'm not sure we tried. However, given our experience, I would not attempt to
run either over 60MHz or MAMCR=2 unless the product could wait for Rev B
silicon (which I think is supposed to fix both, but have no confirmation).

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On 10/8/07, lp2000c wrote:
[snip]
> Also, some posts claim, or imply, that lowering the frequency will
> fix the problem, even if MAMCR=2. (Some even claim that NXP told
> them this.) They differ as to whether frequency needs to be lowered
> below 60 MHz or 48 MHz.

I'll clarify my position on this since there seems to be some confusion here:

1. I am only referring to the lpc2138
2. I have never experienced MAM.2 on the 2138 with my software.
3. I use a variety of different chip revisions, some of which are affected by
both MAM.1 and MAM.2 according to the latest errata
4. Originally I believed the workarounds could be chosen on the fly by a single
piece of software if the chip revision could be identified correctly
but the MAM.2
errata was extended to cover a greater revision of chips in errata 1.8 making
this approach infeasible and identifying the chip revision in software is not
possible either
5. The errata is rather vague and provides conflicting information about how
to resolve MAM.1 versus MAM.2 thus not being very useful if you have chips
potentially affected by both problems like I do
6. The feedback I got from NXP said that I should set MAMCR as per MAM.1 and
run at less than 60Mhz to avoid MAM.2. In fact the exact reply I got said:
"< 60 Mhz or so". If you want to contact NXP about it, use www.nxp.com/support
as they seem to be more responsive to that than in this group.
7. I'll be running at 48Mhz instead of 60Mhz

That's all the info I have.

--Craig



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Sorry for cluttering the issue, but I tried to make it clear that I was
referring to the lpc236x. I see that you're interested in the 2148, which
doesn't have a corresponding Flash.1 errata, and whose MAM.2 errata
corresponds to the 236x's MAM.1 errata. NXP could do a better job naming
erratum...

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

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Craig Schlenter"
wrote:
>
> On 10/8/07, lp2000c wrote:
> [snip]
> > Also, some posts claim, or imply, that lowering the frequency will
> > fix the problem, even if MAMCR=2. (Some even claim that NXP told
> > them this.) They differ as to whether frequency needs to be
lowered
> > below 60 MHz or 48 MHz.
>
> I'll clarify my position on this since there seems to be some
confusion here:
>
> 1. I am only referring to the lpc2138
> 2. I have never experienced MAM.2 on the 2138 with my software.
> 3. I use a variety of different chip revisions, some of which are
affected by
> both MAM.1 and MAM.2 according to the latest errata
> 4. Originally I believed the workarounds could be chosen on the fly
by a single
> piece of software if the chip revision could be identified correctly
> but the MAM.2
> errata was extended to cover a greater revision of chips in errata
1.8 making
> this approach infeasible and identifying the chip revision in
software is not
> possible either
> 5. The errata is rather vague and provides conflicting information
about how
> to resolve MAM.1 versus MAM.2 thus not being very useful if you
have chips
> potentially affected by both problems like I do
> 6. The feedback I got from NXP said that I should set MAMCR as per
MAM.1 and
> run at less than 60Mhz to avoid MAM.2. In fact the exact reply I
got said:
> "< 60 Mhz or so". If you want to contact NXP about it, use
www.nxp.com/support
> as they seem to be more responsive to that than in this group.
> 7. I'll be running at 48Mhz instead of 60Mhz
>
> That's all the info I have.
>
> --Craig
>

Thanks for the summary.

My situation is the same as yours - using LPC2138 with a variety of
revisions, have experienced the MAM.1 bug but not the MAM.2 bug. I
agree with your summary, except for item #6/7.

My contact at NXP says that MAM.2 bug is not affected by speed. I
believe that the person you heard from may have been confusing the
MAM issue with a different problem which is present on some other
chips in this family (e.g.: LPC2364), but not on the LPC2138.

The LPC2364 is spec'd to run at 72 MHz but has a bug in the first two
revs (Flash.1) which limits operation to 60 MHz. Furthermore, the
first rev of that chip has another bug (PLL.1) which makes it
impossible to configure for 60 MHz, thus limiting the speed to 48 MHz.

Nevertheless, my contact at NXP recommends that in our situation
(where MAM.1 and MAM.2 bugs may both be present) MAMCR should be set
to 2, since the MAM.2 bug is very rare, and if it occurs can be
remedied by shifting the code alignement (e.g.: through the addition
of NOP's). He claims that dropping the speed from 60 MHz (the
maximum specified speed for LPC2138) to 48 MHZ should make no
difference.

NXP is saying that they expect to release a new rev of the LPC2138,
with the MAM.2 bug fixed, in February 2008.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

lpc2000c wrote:
>Nevertheless, my contact at NXP recommends that in our situation
>(where MAM.1 and MAM.2 bugs may both be present) MAMCR should be set
>to 2, since the MAM.2 bug is very rare, and if it occurs can be
>remedied by shifting the code alignment (e.g.: through the addition
>of NOP's).

Does that recommendation imply that MAM.2 will occur repeatably when it
does occur ?
My impression so far is that it isn't; it can hit you out of the blue on
a unit that is identical to one that works, maybe only at a particular
temperature or mode of operation. If it is repeatable (always occurs for
a given firmware release) then I don't have a problem with this
solution. It should be reasonably straight forward to pick up in
regression tests.
If is is not repeatable, how on earth are you meant to know when to put
in the NOPs, and where ???

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi,

when checking periodically the DigiKey website I surprisingly found
most of the LC24xx being on stock (small quantities) now. I'm
interested in the LPC2458 mainly, but NXP's website confuses me:

There is *no* user manual for the LPC2458, a datasheet (preliminary)
and a errata sheet (MAM issues :-() exist, the state of the product
is marked as "Development", but the device is sold on DigiKey's website !

As far as I thought to know, the LPC2458 should come out when the new
silicon revision of the LPC23xx/LPC24xx (called LPC2488) is ready
(this seems to be the case now) and there should not be any
restrictions regarding speed and MAM anymore.

I want to avoid to walk into the same trap as many LPC2368 users did:
Using a new chip (which was already available in quantities) for a
new design and not getting any chips for production for more than a
half year then.

So can somebody (NXP ??? my distributor simply knows nothing) shed
light onto this issue and tell me as follows:

1) Is the LPC2458 available in quantities now (and will this be still
the case in some months)?
2) Do the restrictions mentioned in the errata sheet match the reality?

Any input is welcome, thanks for your help.

Herbert

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Bruce Paterson"
wrote:
> Does that recommendation imply that MAM.2 will occur repeatably
when it
> does occur ?
> My impression so far is that it isn't; it can hit you out of the
blue on
> a unit that is identical to one that works, maybe only at a
particular
> temperature or mode of operation. If it is repeatable (always
occurs for
> a given firmware release) then I don't have a problem with this
> solution. It should be reasonably straight forward to pick up in
> regression tests.
> If is is not repeatable, how on earth are you meant to know when to
put
> in the NOPs, and where ???
>
> Cheers,
> Bruce
> [Non-text portions of this message have been removed]
>

The engineer I spoke with at NXP claims that it is repeatable. Some
people on this board seem to have indicated otherwise. His
speculation is that they may have actually been seeing the results of
different bugs which were present on LPX23xx, but not on LPC213x.

I cannot vouch for the accuracy of what he told me.

Of course, even if repeatable, your testing would need to be sure to
pass through every possible code execution path, including ones which
may be dependent on rare coincidence of asynchronous events.

I am certainly not happy depending on his solution, and would not do
so for new designs, but for product which has already been shipping
with with chips prior to rev C, I don't see what alternative I have.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On 10/12/07, lp2000c wrote:
>
> The engineer I spoke with at NXP claims that it is repeatable. Some
> people on this board seem to have indicated otherwise. His
> speculation is that they may have actually been seeing the results of
> different bugs which were present on LPX23xx, but not on LPC213x.
I have seen it to be very repeatable, but very dependent on what code lines
up exactly where in the flash. Adding one nop instruction could completely
change the behavior.

I cannot vouch for the accuracy of what he told me.
>
> Of course, even if repeatable, your testing would need to be sure to
> pass through every possible code execution path, including ones which
> may be dependent on rare coincidence of asynchronous events.
Thanks for pointing out this incredibly important fact. It is difficult to
overstate how important this is, and how horribly the advice you say you
received from NXP is. Unless you can guarantee that every single instruction
in your code, in exactly the same state as shipped, has been thoroughly
tested, then you simply cannot use MAMCR=2, period. Don't even try.
Otherwise, you can have no confidence that the errata might bite you in some
obscure bit of the code that you have not tested.

I am certainly not happy depending on his solution, and would not do
> so for new designs, but for product which has already been shipping
> with with chips prior to rev C, I don't see what alternative I have.
>

Ditto.

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

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )