Forums

MAM bug in the LPC213x

Started by philips_apps July 12, 2005

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


An Engineer's Guide to the LPC2100 Series

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@lpc2..., "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


Does this only affect reading from RAM (as opposed to wirting to
RAM)? In other words, is it safe to write to RAM before changing the
MAM setting from its reset value? --- In lpc2000@lpc2..., "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



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@lpc2..., "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@lpc2..., "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


I have not checked this personally, but I have spoken to a couple of
people who have. It seems that the POP from stack problem which
keithgw originally posted in Message 7898 is indeed the result of the
MAM bug posted by Philips Apps in Message 8032. It is not the result
of a reset problem, as proposed in Message 8010.

The description of the problem in Philips Apps' post needs some
clarification. Incorrect read of data from SRAM can occur while code
is running from Flash and MAM is disabled (i.e.: MAMCR = 0) with
MAMTIM
not set to 1. Unfortunately, this is the Reset condition.

I am not sure that Philips has fully characterized what additional
conditions are required for the bug to manifest itself. However, it
appears that implementing either of the work-arounds proposed in
their
post, before doing any reads from RAM (including stack POPs on return
from subroutine or interrupt) will solve the problem.