LPC1788 EEPROM protected page?

[lpcware]

Content originally posted in LPCWare by sschwarz on Wed Mar 28 09:49:43 MST 2012
In the user manual for LPC1788 on page 803 (Rev. 1.5 - 6 July 2011) I found the sentence:

An erase/program operation on the protected page will result in an error response on
the write transfer to the command register. Unless the protected page’s protection is
overruled by setting the OVP input signal.

There is NOTHING further on protected pages in the EEPROM. If I try to program something in the last available page I get a hard fault - so it could be this mysterious protected page - or anything else.

Does someone know what is meant with this? Is there further documentation on the EEPROM? Any hints?

Thanks!
Simon

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Mon Aug 17 08:49:40 MST 2015
External EEPROMS are really cheap (SPI or I2C according to your fancy).

We don't have a big demand for EEPROM in our designs, but use a Microchip device
in favour of the internal EEPROM because it comes with a unique MAC address and
has space to hold the various network parameters.
[Several grand -- dollars or pounds -- to get a OUID from the IEEE versus 1 or 2 pence
extra (than a standard EEPROM) per board via the MicroChip solution.]

For larger application specific storage -- mainly fonts -- we use a serial data flash
which we read at startup to SDRAM.

Keep on truckin'

Regards, Mike.

[lpcware]

Content originally posted in LPCWare by funbotix on Mon Aug 17 08:07:11 MST 2015
Thanks for the quick response Mike!!

I didn't realize my user manual was out of date.  You're right about the correction in the current (V3.1) user manual.

Thanks for the suggestion to trap the memory fault. I'll have to update my code to handle that.

As for allowing leeway in the spec for 4032 versus 4096 bytes, I don't think I like that.  But... if one's LPC1788 design really requires 4096 bytes of EEPROM, one should read the EEPROM section in the manual carefully (just like for every other needed peripheral, right?).  And... one should always make sure they're using the current user manual whenever starting a new project.  My bad for not checking.

Thanks again (it was really bugging me).
Dave

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Mon Aug 17 06:35:31 MST 2015
I agree that the manual was confusing. It was updated.

The OVP signal referred to is (in my best guess) an internal signal available as part of the intellectual property design kit
for silicon implementers and not a 'real' user accessable signal. In my opinion, it should not even be mentioned in the manual.

As to 4032 versus 4096, I think that we can allow some leeway in the term as simple rounding up for descriptive purposes.
The manual does talk about the last page being unavailable after all.
There other 'implementation' signals mentioned elsewhere in the manual that enable optional behaviour etc. These too are
not appropriate for a user manual.

As to you getting a hard fault, this is entirely to be expected as you are trying to access non-existant memory.

[By the way, the hard fault is because you are not trapping memory and or bus faults  and these get 'promoted'
to a hard fault. Check the hard fault status register bits to see which it is.]

EDIT: The 'OVP' reference has been removed from later revisions of the user manual.

Regards, Mike.

[lpcware]

Content originally posted in LPCWare by funbotix on Sun Aug 16 20:05:46 MST 2015
Hi... thanks for the above posts.  I too found that writing to page 64 in the LPC1788's EEPROM generated HARD FAULT errors, and can find nothing else about the EEPROM's protected page or the OVP signal in the user's manual.  This is disconcerting since the above posts are years old.  There's nothing in the LPC1788's errata sheet about the EEPROM.  Can anyone shed any light on this issue?

It would seem then that the EEPROM actually has 4032 (usable) bytes, not the advertised 4096.

Unless... of course... the mysterious OVP signal is publicly (and correctly) documented and its proper usage allows all 4096 bytes to be used.

Comments... anyone...?

[lpcware]

Content originally posted in LPCWare by sschwarz on Mon Apr 02 00:15:12 MST 2012
Hi Lien,

yep, that's the problems cause - thank you!

Regards
Simon

[lpcware]

Content originally posted in LPCWare by Lien.Nguyen on Wed Mar 28 19:21:00 MST 2012
Hi Simon,
As I know, EEPROM has 63 pages (4032 bytes), not 64 pages (4096 bytes) as described in UM. This is an mistake of UM.
Is this the cause of your problem?

Best Regards,
Lien