Lpc2000

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.