New lpc23xx errata

NXP published new erratasheet for lpc23xx family (see previous post).
It’s available here.
To summarize – sometimes turning MAM fully enable may cause instability. Workaround – don’t (fully) enable MAM.
I’ve expected much more details, so I’m really dissapointed. Maybe they aren’t sure yet when and why exactly MAM fails…
Anyway I haven’t noticed new errata for lpc21xx family. Maybe they mismatched family name with lpc24xx, which of course is affected by this bug. “Of course” because lpc24xx is based on lpc23xx.
There is one more bug about code execution speed. If code is executed from flash memory frequency is limited to 60MHz. I’m not sure what it means. Is 60MHz maximum main clock frequency or maybe for clock faster then 60MHz code will be executed with same speed? In first case – peripherals and code work with max 60MHz. In second – code is executed as with 60MHz clock, but peripherals (like timers…) may work up to 72MHz.
Far for now – with 72MHz clock and MAM disabled I consider lpc23xx working stable.

New errata for lpc23xx?

Is this good news for NXP lpc23/24xx users..?
lpc2000 mailing list – lpc speed problem
In short – there is some issue with MAM (Memory Acceleration Module) in LPC23/24xx. If microcontroller works with high frequency clock (max is 72MHz), the MAM is enabled and there is more then 32KB of code, it may work unstable. Of course when MAM is disabled everything works just perfect. Funny thing is that same code may work perfect on another lpc microcontroller or even on the same after reflash. Same thing with frequency – you may find some information about solving MAM problem with changing frequency below 60MHz. There are also some posts about MAM problems when code is bigger then 32KB, but I think problem is related with code location, not size.
Issue may be also connected with PLL problems in lpc23xx family.
Anyway – I’m quite surprised that NXP (if guy is really from NXP…) noticed this bug so late, but better late then never. It’s hard to belive that lpc210x family has same bug (has NXP been selling it for more then a year..?).

Workaround proposition sounds like some voodoo magic – insert some NOPs and limit frequency. I would add “pray” :-).

After small reprimand I have to say that their microcontrollers even without MAM are quite fast – 72MHz is very nice frequency in ARM7. The thing is that with acceleration enabled it works even 4-5 times faster.

It’s very good that NXP finally admitted that problem exist. I hope new errata, with more precisely explanation of this bug, will be available soon.

Here is some interesting posts about MAM problems in lpc23xx family:
Investigation of LPC23xx MAM Issues – lpc2000 mailing list discussion.