Lpc2000

1) Apparently when MAM is disabled (defined in the USER Manual as 
MAMCR=0), the value of MAMTIM still plays a role.  (See footnote 2 to 
Table 28 and Table 29 of the User Manual).

As I now understand things, the problem only occurs when MAM is 
disabled (i.e.: MAMCR = 0) and MAMTIM is not set to 1.  
(Unfortunately, this is the Reset condition.)

Therefore, work-around 2 now makes sense.

2) Keith: Can you please tell us what the values of MAMCR and MAMTIM 
are when you experience this problem.  (You should be able to just 
look at them in the debugger.)

If you change them to the values specified in the work-around, before 
the offending POP instruction gets executed, does the problem go away?

Again, in order to not modify your code (and move the instruction 
location), you should be able to modify these with the debugger.  
(Remember, that MAMTIM can only be modified when MAMCR is 0, so you 
need to follow the sequence specified in section 4.9 of the User 
Manual when setting these.)

3) I have also been led to believe that the problem only occurs on a 
RAM read which follows a RAM write.

Keith: Your program does not show any RAM writes, but while single 
stepping, the debugger would push stuff on the stack (which is a RAM 
write).

Have you only seen this problem when single stepping, or also when 
running full speed? (e.g.: If you set a breakpoint on the BX 
instruction AFTER the POP instructions, do R1 and R4 then have the 
correct values?)

--- In lpc2000@yahoogroups.com, "lp2000c" <lp2000c@e...> wrote:
> I am missing something.
> 
> You say that there is a problem when MAM is disabled, but then work-
> around #2 says to disable the MAM!
> 
> Please clarify.
> 
> 
> --- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> 
> wrote:
> > 
> > We recently discovered a bug in the MAM block and it affects the  
> > LPC213x family, description of which is provided below. The 
Errata 
> > sheet (for this family) has been updated and is on its way for 
> > publishing. 
> > 
> > ------------------------------------------------------------------
--
> > MAM.1		
> > Incorrect read of data from SRAM while code is running from Flash 
> and 
> > MAM is disabled
> > 
> > Introduction:
> > The Memory Accelerator Module (MAM) provides nearly zero-wait 
state 
> > execution from the on-chip flash at higher frequencies.
> > 
> > Problem:
> > While code is running from the on-chip Flash, if a data fetch is 
> > initiated from SRAM, the data read might be corrupted.
> > 
> > Work-around:		
> > There are two possible workarounds: 
> > 1. Fully enable the MAM (MAMCR=0x2) and use the appropriate 
MAMTIM 
> > value. Enabling the MAM will reduce current consumption (since 
the 
> > MAM buffers four ARM or eight Thumb instructions with each Flash 
> > fetch) and also provide nearly zero-wait state execution from 
Flash 
> > above 20MHz.
> > 2. Disable MAM (MAMCR=0x0) and set MAMTIM=0x1. If the MAM is 
> > disabled, this will lead to increased current consumption as each 
> > fetch will result in a read of the Flash memory. In addition, it 
> > limits execution out of Flash to 20MHz. This approach would 
however 
> > provide deterministic behaviour.
> > 
> > The first workaround is the recommended solution as the 
application 
> > can achieve considerable power savings and also does not put any 
> > restriction on the operating frequency.	
> > 
> > ------------------------------------------------------------------
--
> -
> > 
> > 
> > Best Regards,
> > Philips Apps