Lpc2000

Message 7923 describes a bizarre stack problem on the 213x. If this is
correct, it would seem to seriously limit the usefulness of this part.

What say you Philips Ap's?

Dave

Dave,

Your pointer was a little misleading (7923) but I found the issue
described in 7898.

My question to the original poster (I guess Keith) is whether the MAM
was enabled? If not please do so.  

Did enabling the MAM change anything?



--- In lpc2000@yahoogroups.com, "dsidlauskas1" <dsidlauskas@w...> wrote:

> Message 7923 describes a bizarre stack problem on the 213x. If this is
> correct, it would seem to seriously limit the usefulness of this part.
> 
> What say you Philips Ap's?
> 
> Dave

Can you add a short summary of the problem, what the problem is ?

Regards,

         Martin

----- Original Message ----- 

From: "lpc2100_fan" <lpc2100_fan@...>
To: <lpc2000@yahoogroups.com>
Sent: Monday, July 04, 2005 8:12 AM
Subject: [lpc2000] Re: Philip Aps. - Stack Issue


> Dave,
> 
> Your pointer was a little misleading (7923) but I found the issue
> described in 7898.
> 
> My question to the original poster (I guess Keith) is whether the MAM
> was enabled? If not please do so.  
> 
> Did enabling the MAM change anything?
> 
> 
> 
> --- In lpc2000@yahoogroups.com, "dsidlauskas1" <dsidlauskas@w...> wrote:
>> Message 7923 describes a bizarre stack problem on the 213x. If this is
>> correct, it would seem to seriously limit the usefulness of this part.
>> 
>> What say you Philips Ap's?
>> 
>> Dave
> 
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
> 
>

Martin and All,

Sorry for the wrong message number. Message 7898 fully describes the
problem.

In brief:
"
It appears anytime the PC and SP are equal except for the high byte of
the address, and you run a POP {R4} instruction, the chip will pop two
times off the stack thus loading R4 with the wrong value and messing
up your stack.

for example:

0x000001F4 POP {R4} With SP = 0x400001F4.

R4 will be loaded with the contents of 0x400001F8.
"

Dave

--- In lpc2000@yahoogroups.com, "Martin Maurer" <mailingliste@c...> wrote:
> Can you add a short summary of the problem, what the problem is ?
> 
> Regards,
> 
>          Martin
> 
> ----- Original Message ----- 
> From: "lpc2100_fan" <lpc2100_fan@y...>
> To: <lpc2000@yahoogroups.com>
> Sent: Monday, July 04, 2005 8:12 AM
> Subject: [lpc2000] Re: Philip Aps. - Stack Issue
> 
> 
> > Dave,
> > 
> > Your pointer was a little misleading (7923) but I found the issue
> > described in 7898.
> > 
> > My question to the original poster (I guess Keith) is whether the MAM
> > was enabled? If not please do so.  
> > 
> > Did enabling the MAM change anything?
> > 
> > 
> > 
> > --- In lpc2000@yahoogroups.com, "dsidlauskas1" <dsidlauskas@w...>
wrote:
> >> Message 7923 describes a bizarre stack problem on the 213x. If
this is
> >> correct, it would seem to seriously limit the usefulness of this
part.

> >> 
> >> What say you Philips Ap's?
> >> 
> >> Dave
> > 
> > 
> > 
> > 
> > 
> > Yahoo! Groups Links
> > 
> > 
> > 
> > 
> > 
> > 
> >

This seems disastrous, severely limiting the usefulness of the part.  

 

Is this just a problem with the 213x parts?

 

  _____  

From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
Of dsidlauskas1
Sent: Monday, July 04, 2005 7:55 AM
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Re: Philip Aps. - Stack Issue

 

Martin and All,

Sorry for the wrong message number. Message 7898 fully describes the
problem.

In brief:
"
It appears anytime the PC and SP are equal except for the high byte of
the address, and you run a POP {R4} instruction, the chip will pop two
times off the stack thus loading R4 with the wrong value and messing
up your stack.

for example:

0x000001F4 POP {R4} With SP = 0x400001F4.

R4 will be loaded with the contents of 0x400001F8.
"

Dave

--- In lpc2000@yahoogroups.com, "Martin Maurer" <mailingliste@c...>
wrote:
> Can you add a short summary of the problem, what the problem is ?
> 
> Regards,
> 
>          Martin
> 
> ----- Original Message ----- 
> From: "lpc2100_fan" <lpc2100_fan@y...>
> To: <lpc2000@yahoogroups.com>
> Sent: Monday, July 04, 2005 8:12 AM
> Subject: [lpc2000] Re: Philip Aps. - Stack Issue
> 
> 
> > Dave,
> > 
> > Your pointer was a little misleading (7923) but I found the issue
> > described in 7898.
> > 
> > My question to the original poster (I guess Keith) is whether the
MAM
> > was enabled? If not please do so.  
> > 
> > Did enabling the MAM change anything?
> > 
> > 
> > 
> > --- In lpc2000@yahoogroups.com, "dsidlauskas1" <dsidlauskas@w...>
wrote:
> >> Message 7923 describes a bizarre stack problem on the 213x. If
this is
> >> correct, it would seem to seriously limit the usefulness of this
part.
> >> 
> >> What say you Philips Ap's?
> >> 
> >> Dave
> > 
> > 
> > 
> > 
> > 
> > Yahoo! Groups Links
> > 
> > 
> > 
> > 
> > 
> > 
> >





  _____  

YAHOO! GROUPS LINKS 

 

*	 Visit your group "lpc2000
<http://groups.yahoo.com/group/lpc2000> " on the web.
	  
*	 To unsubscribe from this group, send an email to:
	 lpc2000-unsubscribe@yahoogroups.com
<mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
	  
*	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> . 

 

  _____  



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

WOW!!

Has anyone else reproduced this?

keithgw_strider:

Have you found out anything more?



--- In lpc2000@yahoogroups.com, "dsidlauskas1" <dsidlauskas@w...> 
wrote:
> Martin and All,
> 
> Sorry for the wrong message number. Message 7898 fully describes the
> problem.
> 
> In brief:
> "
> It appears anytime the PC and SP are equal except for the high byte 
of
> the address, and you run a POP {R4} instruction, the chip will pop 
two
> times off the stack thus loading R4 with the wrong value and messing
> up your stack.
> 
> for example:
> 
> 0x000001F4 POP {R4} With SP = 0x400001F4.
> 
> R4 will be loaded with the contents of 0x400001F8.
> "
> 
> Dave
> 
> --- In lpc2000@yahoogroups.com, "Martin Maurer" <mailingliste@c...> 
wrote:
> > Can you add a short summary of the problem, what the problem is ?
> > 
> > Regards,
> > 
> >          Martin
> > 
> > ----- Original Message ----- 
> > From: "lpc2100_fan" <lpc2100_fan@y...>
> > To: <lpc2000@yahoogroups.com>
> > Sent: Monday, July 04, 2005 8:12 AM
> > Subject: [lpc2000] Re: Philip Aps. - Stack Issue
> > 
> > 
> > > Dave,
> > > 
> > > Your pointer was a little misleading (7923) but I found the 
issue
> > > described in 7898.
> > > 
> > > My question to the original poster (I guess Keith) is whether 
the MAM
> > > was enabled? If not please do so.  
> > > 
> > > Did enabling the MAM change anything?
> > > 
> > > 
> > > 
> > > --- In lpc2000@yahoogroups.com, "dsidlauskas1" 
<dsidlauskas@w...>
> wrote:
> > >> Message 7923 describes a bizarre stack problem on the 213x. If
> this is
> > >> correct, it would seem to seriously limit the usefulness of 
this

> part.
> > >> 
> > >> What say you Philips Ap's?
> > >> 
> > >> Dave
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Yahoo! Groups Links
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >

Hi, 

Help!!  I'm using lots of LPC2124, but not LPC213x yet.
Somebody pls.. pls.. confirm problem related to LPC213x only.
(something like due to moving port I/O to local bus and add
address comparator so that prefetch queue not flushed 
=> for high speed I/O port toggling.   Or whats ever)

Many Thanks and Best Regards   /MH


--- In lpc2000@yahoogroups.com, "lp2000c" <lp2000c@e...> wrote:
> WOW!!
> 
> Has anyone else reproduced this?
> 
> keithgw_strider:
> 
> Have you found out anything more?
> 
> 
> 
> --- In lpc2000@yahoogroups.com, "dsidlauskas1" <dsidlauskas@w...> 
> wrote:
> > Martin and All,
> > 
> > Sorry for the wrong message number. Message 7898 fully describes 
the
> > problem.
> > 
> > In brief:
> > "
> > It appears anytime the PC and SP are equal except for the high 
byte 
> of
> > the address, and you run a POP {R4} instruction, the chip will 
pop 
> two
> > times off the stack thus loading R4 with the wrong value and 
messing
> > up your stack.
> > 
> > for example:
> > 
> > 0x000001F4 POP {R4} With SP = 0x400001F4.
> > 
> > R4 will be loaded with the contents of 0x400001F8.
> > "
> > 
> > Dave
> > 
> > --- In lpc2000@yahoogroups.com, "Martin Maurer" 
<mailingliste@c...> 
> wrote:
> > > Can you add a short summary of the problem, what the problem 
is ?
> > > 
> > > Regards,
> > > 
> > >          Martin
> > > 
> > > ----- Original Message ----- 
> > > From: "lpc2100_fan" <lpc2100_fan@y...>
> > > To: <lpc2000@yahoogroups.com>
> > > Sent: Monday, July 04, 2005 8:12 AM
> > > Subject: [lpc2000] Re: Philip Aps. - Stack Issue
> > > 
> > > 
> > > > Dave,
> > > > 
> > > > Your pointer was a little misleading (7923) but I found the 
> issue
> > > > described in 7898.
> > > > 
> > > > My question to the original poster (I guess Keith) is 
whether 
> the MAM
> > > > was enabled? If not please do so.  
> > > > 
> > > > Did enabling the MAM change anything?
> > > > 
> > > > 
> > > > 
> > > > --- In lpc2000@yahoogroups.com, "dsidlauskas1" 
> <dsidlauskas@w...>
> > wrote:
> > > >> Message 7923 describes a bizarre stack problem on the 213x. 
If

> > this is
> > > >> correct, it would seem to seriously limit the usefulness of 
> this
> > part.
> > > >> 
> > > >> What say you Philips Ap's?
> > > >> 
> > > >> Dave
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Yahoo! Groups Links
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >

We are using the 2138 in two projects. This is an issue that should be confirmed by Philips apps. 

I am wondering if this is compiler specific too. We use GCC for our projects and so far I haven't seen any generated POP instruction in the listing file.

regards,
marko

> 
> Od: "unity0724" <unity0724@...>
> Datum: 2005/07/06 Sre AM 02:53:45 CEST
> Za: lpc2000@yahoogroups.com
> Zadeva: [lpc2000] Re: Philip Aps. - Stack Issue
> 
> Hi, 
> 
> Help!!  I'm using lots of LPC2124, but not LPC213x yet.
> Somebody pls.. pls.. confirm problem related to LPC213x only.
> (something like due to moving port I/O to local bus and add
> address comparator so that prefetch queue not flushed 
> => for high speed I/O port toggling.   Or whats ever)
> 
> Many Thanks and Best Regards   /MH
> 
> 
> --- In lpc2000@yahoogroups.com, "lp2000c" <lp2000c@e...> wrote:
> > WOW!!
> > 
> > Has anyone else reproduced this?
> > 
> > keithgw_strider:
> > 
> > Have you found out anything more?
> > 
> > 
> > 
> > --- In lpc2000@yahoogroups.com, "dsidlauskas1" <dsidlauskas@w...> 
> > wrote:
> > > Martin and All,
> > > 
> > > Sorry for the wrong message number. Message 7898 fully describes 
> the
> > > problem.
> > > 
> > > In brief:
> > > "
> > > It appears anytime the PC and SP are equal except for the high 
> byte 
> > of
> > > the address, and you run a POP {R4} instruction, the chip will 
> pop 
> > two
> > > times off the stack thus loading R4 with the wrong value and 
> messing
> > > up your stack.
> > > 
> > > for example:
> > > 
> > > 0x000001F4 POP {R4} With SP = 0x400001F4.
> > > 
> > > R4 will be loaded with the contents of 0x400001F8.
> > > "
> > > 
> > > Dave
> > > 
> > > --- In lpc2000@yahoogroups.com, "Martin Maurer" 
> <mailingliste@c...> 
> > wrote:
> > > > Can you add a short summary of the problem, what the problem 
> is ?
> > > > 
> > > > Regards,
> > > > 
> > > >          Martin
> > > > 
> > > > ----- Original Message ----- 
> > > > From: "lpc2100_fan" <lpc2100_fan@y...>
> > > > To: <lpc2000@yahoogroups.com>
> > > > Sent: Monday, July 04, 2005 8:12 AM
> > > > Subject: [lpc2000] Re: Philip Aps. - Stack Issue
> > > > 
> > > > 
> > > > > Dave,
> > > > > 
> > > > > Your pointer was a little misleading (7923) but I found the 
> > issue
> > > > > described in 7898.
> > > > > 
> > > > > My question to the original poster (I guess Keith) is 
> whether 
> > the MAM
> > > > > was enabled? If not please do so.  
> > > > > 
> > > > > Did enabling the MAM change anything?
> > > > > 
> > > > > 
> > > > > 
> > > > > --- In lpc2000@yahoogroups.com, "dsidlauskas1" 
> > <dsidlauskas@w...>
> > > wrote:
> > > > >> Message 7923 describes a bizarre stack problem on the 213x. 
> If
> > > this is
> > > > >> correct, it would seem to seriously limit the usefulness of 
> > this
> > > part.
> > > > >> 
> > > > >> What say you Philips Ap's?
> > > > >> 
> > > > >> Dave
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Yahoo! Groups Links
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
>

I sent a copy of my project to Mike Nelson at IAR. He was able to 
duplicate the problem using the latest tools on the LPC213x but he 
could NOT duplicated it on the LPC2106. I don't see how it is a 
tools issue, although if your tools never generates a POP 
instruction, you won't see this problem.

Mike modified my project so the addresses match again when compiled 
with the latest tools. He then sent a copy of the project and screen 
shots to Will Dawson of Philips, Mark Moran of IAR and myself. If 
anyone wants a copy of the project and screen shots, they will be 
posted in the the files section.





--- In lpc2000@yahoogroups.com, "unity0724" <unity0724@y...> wrote:
> Hi, 
> 
> Help!!  I'm using lots of LPC2124, but not LPC213x yet.
> Somebody pls.. pls.. confirm problem related to LPC213x only.
> (something like due to moving port I/O to local bus and add
> address comparator so that prefetch queue not flushed 
> => for high speed I/O port toggling.   Or whats ever)
> 
> Many Thanks and Best Regards   /MH
> 
> 
> --- In lpc2000@yahoogroups.com, "lp2000c" <lp2000c@e...> wrote:
> > WOW!!
> > 
> > Has anyone else reproduced this?
> > 
> > keithgw_strider:
> > 
> > Have you found out anything more?
> > 
> > 
> > 
> > --- In lpc2000@yahoogroups.com, "dsidlauskas1" 
<dsidlauskas@w...> 
> > wrote:
> > > Martin and All,
> > > 
> > > Sorry for the wrong message number. Message 7898 fully 
describes 
> the
> > > problem.
> > > 
> > > In brief:
> > > "
> > > It appears anytime the PC and SP are equal except for the high 
> byte 
> > of
> > > the address, and you run a POP {R4} instruction, the chip will 
> pop 
> > two
> > > times off the stack thus loading R4 with the wrong value and 
> messing
> > > up your stack.
> > > 
> > > for example:
> > > 
> > > 0x000001F4 POP {R4} With SP = 0x400001F4.
> > > 
> > > R4 will be loaded with the contents of 0x400001F8.
> > > "
> > > 
> > > Dave
> > > 
> > > --- In lpc2000@yahoogroups.com, "Martin Maurer" 
> <mailingliste@c...> 
> > wrote:
> > > > Can you add a short summary of the problem, what the problem 
> is ?
> > > > 
> > > > Regards,
> > > > 
> > > >          Martin
> > > > 
> > > > ----- Original Message ----- 
> > > > From: "lpc2100_fan" <lpc2100_fan@y...>
> > > > To: <lpc2000@yahoogroups.com>
> > > > Sent: Monday, July 04, 2005 8:12 AM
> > > > Subject: [lpc2000] Re: Philip Aps. - Stack Issue
> > > > 
> > > > 
> > > > > Dave,
> > > > > 
> > > > > Your pointer was a little misleading (7923) but I found 
the 
> > issue
> > > > > described in 7898.
> > > > > 
> > > > > My question to the original poster (I guess Keith) is 
> whether 
> > the MAM
> > > > > was enabled? If not please do so.  
> > > > > 
> > > > > Did enabling the MAM change anything?
> > > > > 
> > > > > 
> > > > > 
> > > > > --- In lpc2000@yahoogroups.com, "dsidlauskas1" 
> > <dsidlauskas@w...>
> > > wrote:
> > > > >> Message 7923 describes a bizarre stack problem on the 
213x. 
> If
> > > this is
> > > > >> correct, it would seem to seriously limit the usefulness 
of 

> > this
> > > part.
> > > > >> 
> > > > >> What say you Philips Ap's?
> > > > >> 
> > > > >> Dave
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Yahoo! Groups Links
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >

Please don't bother IAR with this problem. I am 99.9% sure it is NOT 
their problem. Use any tool that uses POP instructions. When the 
address of the pop instruction matches the SP address, except for 
the most significant byte, you should see this problem.

Again this has only been seen on the LPC213x family. If you have 
concerns about this, see it for yourself. The project and 
screenshots have been posted in the "files" section under "stack 
issue". I will let you know when I get any information from Philips.


--- In lpc2000@yahoogroups.com, "keithgw_strider" 
<keithgw_strider@y...> wrote:
> I sent a copy of my project to Mike Nelson at IAR. He was able to 
> duplicate the problem using the latest tools on the LPC213x but he 
> could NOT duplicated it on the LPC2106. I don't see how it is a 
> tools issue, although if your tools never generates a POP 
> instruction, you won't see this problem.
> 
> Mike modified my project so the addresses match again when 
compiled 
> with the latest tools. He then sent a copy of the project and 
screen 
> shots to Will Dawson of Philips, Mark Moran of IAR and myself. If 
> anyone wants a copy of the project and screen shots, they will be 
> posted in the the files section.
> 
> 
> 
> 
> 
> --- In lpc2000@yahoogroups.com, "unity0724" <unity0724@y...> wrote:
> > Hi, 
> > 
> > Help!!  I'm using lots of LPC2124, but not LPC213x yet.
> > Somebody pls.. pls.. confirm problem related to LPC213x only.
> > (something like due to moving port I/O to local bus and add
> > address comparator so that prefetch queue not flushed 
> > => for high speed I/O port toggling.   Or whats ever)
> > 
> > Many Thanks and Best Regards   /MH
> > 
> > 
> > --- In lpc2000@yahoogroups.com, "lp2000c" <lp2000c@e...> wrote:
> > > WOW!!
> > > 
> > > Has anyone else reproduced this?
> > > 
> > > keithgw_strider:
> > > 
> > > Have you found out anything more?
> > > 
> > > 
> > > 
> > > --- In lpc2000@yahoogroups.com, "dsidlauskas1" 
> <dsidlauskas@w...> 
> > > wrote:
> > > > Martin and All,
> > > > 
> > > > Sorry for the wrong message number. Message 7898 fully 
> describes 
> > the
> > > > problem.
> > > > 
> > > > In brief:
> > > > "
> > > > It appears anytime the PC and SP are equal except for the 
high 
> > byte 
> > > of
> > > > the address, and you run a POP {R4} instruction, the chip 
will 
> > pop 
> > > two
> > > > times off the stack thus loading R4 with the wrong value and 
> > messing
> > > > up your stack.
> > > > 
> > > > for example:
> > > > 
> > > > 0x000001F4 POP {R4} With SP = 0x400001F4.
> > > > 
> > > > R4 will be loaded with the contents of 0x400001F8.
> > > > "
> > > > 
> > > > Dave
> > > > 
> > > > --- In lpc2000@yahoogroups.com, "Martin Maurer" 
> > <mailingliste@c...> 
> > > wrote:
> > > > > Can you add a short summary of the problem, what the 
problem 
> > is ?
> > > > > 
> > > > > Regards,
> > > > > 
> > > > >          Martin
> > > > > 
> > > > > ----- Original Message ----- 
> > > > > From: "lpc2100_fan" <lpc2100_fan@y...>
> > > > > To: <lpc2000@yahoogroups.com>
> > > > > Sent: Monday, July 04, 2005 8:12 AM
> > > > > Subject: [lpc2000] Re: Philip Aps. - Stack Issue
> > > > > 
> > > > > 
> > > > > > Dave,
> > > > > > 
> > > > > > Your pointer was a little misleading (7923) but I found 
> the 
> > > issue
> > > > > > described in 7898.
> > > > > > 
> > > > > > My question to the original poster (I guess Keith) is 
> > whether 
> > > the MAM
> > > > > > was enabled? If not please do so.  
> > > > > > 
> > > > > > Did enabling the MAM change anything?
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > --- In lpc2000@yahoogroups.com, "dsidlauskas1" 
> > > <dsidlauskas@w...>
> > > > wrote:
> > > > > >> Message 7923 describes a bizarre stack problem on the 
> 213x. 
> > If
> > > > this is
> > > > > >> correct, it would seem to seriously limit the 
usefulness 

> of 
> > > this
> > > > part.
> > > > > >> 
> > > > > >> What say you Philips Ap's?
> > > > > >> 
> > > > > >> Dave
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Yahoo! Groups Links
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >

Hi, Thanks,
..mmm... May be using the LPC2138 as "LPC2137" (first
32KB of flash memory non use-able) will have that
problem fixed..   :)
Regards   /MH

--- In lpc2000@yahoogroups.com, "keithgw_strider" 
<keithgw_strider@y...> wrote:
> Please don't bother IAR with this problem. I am 99.9% sure it is 
NOT 
> their problem. Use any tool that uses POP instructions. When the 
> address of the pop instruction matches the SP address, except for 
> the most significant byte, you should see this problem.
> 
> Again this has only been seen on the LPC213x family. If you have 
> concerns about this, see it for yourself. The project and 
> screenshots have been posted in the "files" section under "stack 
> issue". I will let you know when I get any information from 
Philips.
> 
> 
> --- In lpc2000@yahoogroups.com, "keithgw_strider" 
> <keithgw_strider@y...> wrote:
> > I sent a copy of my project to Mike Nelson at IAR. He was able 
to 
> > duplicate the problem using the latest tools on the LPC213x but 
he 
> > could NOT duplicated it on the LPC2106. I don't see how it is a 
> > tools issue, although if your tools never generates a POP 
> > instruction, you won't see this problem.
> > 
> > Mike modified my project so the addresses match again when 
> compiled 
> > with the latest tools. He then sent a copy of the project and 
> screen 
> > shots to Will Dawson of Philips, Mark Moran of IAR and myself. 
If 
> > anyone wants a copy of the project and screen shots, they will 
be 
> > posted in the the files section.
> > 
> > 
> > 
> > 
> > 
> > --- In lpc2000@yahoogroups.com, "unity0724" <unity0724@y...> 
wrote:
> > > Hi, 
> > > 
> > > Help!!  I'm using lots of LPC2124, but not LPC213x yet.
> > > Somebody pls.. pls.. confirm problem related to LPC213x only.
> > > (something like due to moving port I/O to local bus and add
> > > address comparator so that prefetch queue not flushed 
> > > => for high speed I/O port toggling.   Or whats ever)
> > > 
> > > Many Thanks and Best Regards   /MH
> > > 
> > > 
> > > --- In lpc2000@yahoogroups.com, "lp2000c" <lp2000c@e...> wrote:
> > > > WOW!!
> > > > 
> > > > Has anyone else reproduced this?
> > > > 
> > > > keithgw_strider:
> > > > 
> > > > Have you found out anything more?
> > > > 
> > > > 
> > > > 
> > > > --- In lpc2000@yahoogroups.com, "dsidlauskas1" 
> > <dsidlauskas@w...> 
> > > > wrote:
> > > > > Martin and All,
> > > > > 
> > > > > Sorry for the wrong message number. Message 7898 fully 
> > describes 
> > > the
> > > > > problem.
> > > > > 
> > > > > In brief:
> > > > > "
> > > > > It appears anytime the PC and SP are equal except for the 
> high 
> > > byte 
> > > > of
> > > > > the address, and you run a POP {R4} instruction, the chip 
> will 
> > > pop 
> > > > two
> > > > > times off the stack thus loading R4 with the wrong value 
and 
> > > messing
> > > > > up your stack.
> > > > > 
> > > > > for example:
> > > > > 
> > > > > 0x000001F4 POP {R4} With SP = 0x400001F4.
> > > > > 
> > > > > R4 will be loaded with the contents of 0x400001F8.
> > > > > "
> > > > > 
> > > > > Dave
> > > > > 
> > > > > --- In lpc2000@yahoogroups.com, "Martin Maurer" 
> > > <mailingliste@c...> 
> > > > wrote:
> > > > > > Can you add a short summary of the problem, what the 
> problem 
> > > is ?
> > > > > > 
> > > > > > Regards,
> > > > > > 
> > > > > >          Martin
> > > > > > 
> > > > > > ----- Original Message ----- 
> > > > > > From: "lpc2100_fan" <lpc2100_fan@y...>
> > > > > > To: <lpc2000@yahoogroups.com>
> > > > > > Sent: Monday, July 04, 2005 8:12 AM
> > > > > > Subject: [lpc2000] Re: Philip Aps. - Stack Issue
> > > > > > 
> > > > > > 
> > > > > > > Dave,
> > > > > > > 
> > > > > > > Your pointer was a little misleading (7923) but I 
found 

> > the 
> > > > issue
> > > > > > > described in 7898.
> > > > > > > 
> > > > > > > My question to the original poster (I guess Keith) is 
> > > whether 
> > > > the MAM
> > > > > > > was enabled? If not please do so.  
> > > > > > > 
> > > > > > > Did enabling the MAM change anything?
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > --- In lpc2000@yahoogroups.com, "dsidlauskas1" 
> > > > <dsidlauskas@w...>
> > > > > wrote:
> > > > > > >> Message 7923 describes a bizarre stack problem on the 
> > 213x. 
> > > If
> > > > > this is
> > > > > > >> correct, it would seem to seriously limit the 
> usefulness 
> > of 
> > > > this
> > > > > part.
> > > > > > >> 
> > > > > > >> What say you Philips Ap's?
> > > > > > >> 
> > > > > > >> Dave
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Yahoo! Groups Links
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > >

It looks like you've done a great job documentating this.  Apparently,
the people at Philips in a position to examine this are on shut down 
this week, so we will probably need to wait a bit to get an answer 
from them.

However, someone there speculated that enabling the MAM might "fix"
the problem.  This suggestion had also been made by lpc2100_fan in
message 7926.  It looks like you are not touching the MAMCR in your 
test code, which would leave it at the default state (0=disabled).  
Are you in a position to test your code with MAM enabled, and see if 
it makes a difference?  I think that information would be helpful to 
all of us in the interim, and helpful to Philips when they are able 
to look at it next week.

Also, your test code has the offending POP instruction at 0x000001F8, 
with SP at 0x400001F8.  Are you using LPC2138?  If so, are you able
to test this with your code located 0x00040000 higher, so that the 
offending POP instruction will be at 0x000401F8, with SP at 
0x400001F8?  If this works, then unity0724's suggestion (in message 
7969) of not placing any executable code in the first 32K of Flash 
will probably work.  Of course, while this might be feasible for 
LPC2138, it obviously would not be of help for LPC2131.

Thanks again for all your thorough analysis.


--- In lpc2000@yahoogroups.com, "keithgw_strider" 
<keithgw_strider@y...> wrote:
> Please don't bother IAR with this problem. I am 99.9% sure it is 
NOT 

> their problem. Use any tool that uses POP instructions. When the 
> address of the pop instruction matches the SP address, except for 
> the most significant byte, you should see this problem.
> 
> Again this has only been seen on the LPC213x family. If you have 
> concerns about this, see it for yourself. The project and 
> screenshots have been posted in the "files" section under "stack 
> issue". I will let you know when I get any information from Philips.

I got tired of waiting for Philips so I wrote my own simple program to
investigate this stack problem. I used Keil.  The code below first
fills the stack area so that the contents of the stack is equal to the
stack address. This makes it easier to see what's being popped. 

With a break at the POP {R4}, SP=0x40000180, PC=0x0180. When the POP
is executed R4 ends up with the correct value of 0x40000180, so I
don't experience the problem. I've tried this both with MAM on and off.

Could this be a JTAG debug problem?

Dave S.

// Investigate POP R4 error in case where all byte high byte of SP and
PC are the same.

#include <LPC213x.H>                       

void main (void) {
__asm {
	// Fill the stack area *stack++ = stack
	MOV	R1, PC
	LDR	R2, =0X40000012
	ADD	R1, R2
	LDR     R2, =4
	LDR	R3, =10
LOOP:
	STR R1, [R1]
	ADD	R1, R2
	SUB	R3, #1
	BNE LOOP

   // Set up conditions for SP = PC + 0x40000000 and POP R4
	NOP			;Stack must be 4 byte alligned
	MOV	SP,PC
	LDR     R2,=0x40000002
	ADD	SP,R2

	POP {R4}
	}
}

From: "dsidlauskas1"
> I got tired of waiting for Philips so I wrote my own simple program to
> investigate this stack problem. I used Keil.  The code below first
> fills the stack area so that the contents of the stack is equal to the
> stack address. This makes it easier to see what's being popped.
>
> With a break at the POP {R4}, SP=0x40000180, PC=0x0180. When the POP
> is executed R4 ends up with the correct value of 0x40000180, so I
> don't experience the problem. I've tried this both with MAM on and off.
>
> Could this be a JTAG debug problem?

Hmmm...
I've seen two bugs in my 30 years of computerbuilding that looked like this.
Both were semi-analog problems: specific patterns on the data- and
addressbus causing analog crosstalk between lines, which then didn't meet
the timing requirements.

Could someone that can reproduce the bug try some things:

1. Try the program at a much (2x) lower speed (reprogram the PLL)

2. Check for proper decoupling of this chip (100nF ceramic SMD on EACH
Vss/Vdd pin combination, within 5mm from the chip). If not properly
decoupled, add these and try again.

3. Try at a lower temperature (freeze the board and start it quickly, or put
a bag of ice on top).

I've no board yet for the LPC2138 sample I just received, or I'd try it
myself (removing proper decoupling, that is). This is a nice bugyy to catch!

Regards,
Arie de Muynck

Hi Keith, I am Charles and part of this group. I just recieved a
message from Mark Moran at IAR. Here it is.

======================================================
If you select Project\Options in EWARM and click on the JLINK Category
and then check the "Hardware Reset" Box and fill in a delay of at
least 1 millisecond, then the code example that Keith Wentworth sent
to the NG will return from function A2D_ReadByte() properly and run
normally thereafter.

I should have thought of this sooner. That being the case I'm
investigating why this is not the default setting of the debugger.
There may be some memory mapping issues I have not thought through
completely, but I'm sure that this gets Keith back in business.
However, it still raises some interesting questions why the LPC2138
picks that point to fail when not reset. In any case, I'm sure this works.

======================================================
--- In lpc2000@yahoogroups.com, "keithgw_strider"
<keithgw_strider@y...> wrote:

> I sent a copy of my project to Mike Nelson at IAR. He was able to 
> duplicate the problem using the latest tools on the LPC213x but he 
> could NOT duplicated it on the LPC2106. I don't see how it is a 
> tools issue, although if your tools never generates a POP 
> instruction, you won't see this problem.