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.
> >
> > ------------------------------------------------------------------
--
Show quoted textHide quoted text
> -
> >
> >
> > Best Regards,
> > Philips Apps