LPC1347 EEPROM / IAP basic questions

lpcware · ‎06-15-2016

Content originally posted in LPCWare by a.unique.identifier on Mon Apr 15 14:40:38 MST 2013
Could somebody please let me know if I understand this stuff correctly? I'm using a LPC1347 and would like to store variables in the EEPROM over a power down cycle.

1. The EEPROM is different from the Flash memory. Flash issues such as "prepare for write", the "pageness" and word boundaries don't apply. The only two IAP commands that apply are the Write / Read (61 / 62)?

2. Do I need to be concerned about wearing out the EEPROM with to many write cycles? If this is an issue, I suppose I simply have to loop my writes through the EEPROM address space.

3. The EEPROM doesn't have any ECC restraints as the Flash does (mentioned in AN11008)?

4. You do not need to disable interrupts to write to the EEPROM? Systick can also run merrily along?

5. I cannot write to the last 64 bytes in the EEPROM. Do I still need to adjust the SP address to reserve 32 bytes for the IAP?

Last but not least: I have quite a few presets and I thought I would store them in a struct and simply write the entire struct to the EEPROM. On power up, I would read all the variables back into the struct. Since the variables in a structure are contiguous, this should work out okay. Is this the best method and memory for this purpose?

Any other help links or code examples would be appreciated.

Thanks in advance!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by a.unique.identifier on Thu Dec 05 00:38:49 MST 2013
No, I haven't seen that. It looks interesting. I'll have a look at it - thanks!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by chrisbay on Tue Nov 26 12:59:58 MST 2013
If you haven't seen it already, this may be of interest:
http://www.lpcware.com/content/blog/lpc1100lpc1300-eeprom-library

It's a software replacement for the EEPROM read/write functionality stored in the ROM. It's not quite as fully featured, but in particular it removes the need for interrupts to be disabled during EEPROM access. The linked article explains a bit more than the 1347 docs:

Quote:
Due to hardware constraints, the IAP functions are forced to disable interrupts for a short moment in order to do parameter validation. As this happens inside the IAP ROM code, your application must disable interrupts globally for the run-time of the call. Writing to EEPROM takes about 3 ms per 64-byte page or any number of bytes less than that. Reading is much faster, but can take more than 80 µs to read 100 bytes, and interrupts are not allowed here either! For the majority of applications this is a very tough limitation

lpcware · ‎06-15-2016

Content originally posted in LPCWare by a.unique.identifier on Sun Nov 24 02:35:05 MST 2013
Hello tha, sorry for the delay in answering - I haven't been online in a while.

Using the terminology in Chapter 21.8.7, I understood the interrupts must be turned off when using an IAP call to write to the Flash memory, where the program code and the interrupt vectors (normally) are stored, and not the EEPROM, where arbitrary user data may be stored. I always thought there was a technology difference between the "Flash" and "EEPROM" memory areas and hence my interpretation was re-enforced.

Disabling interrupts during a Flash write makes sense as the interrupt vectors are (normally) stored in Flash. This chapter also states that storing the interrupt vectors and handlers in RAM is an acceptable alternative to disabling the interrupts. The EEPROM has nothing to do with the interrupt vectors and so I understood a write to that memory is non-critical.

Could you please elaborate?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by a.unique.identifier on Sat Apr 27 08:49:11 MST 2013
I did some tests and I wanted to share the results with you. Chapter 21 of UM10524 mixes Flash and eeprom together, but you can trust NXP's wording.

I wrote random number of bytes and had no problems. There are indeed no "pageness" or ECC considerations.

You only need to disbale interrupts when writing to the Flash memory and not the eeprom. 21.8.7 only refers to IAP and Flash. I had systick interrupting every 1mS.

21.8.8 states you need to reserve 32 bytes of stack when writing to Flash and not eeprom. I didn't reserve anything and all went well. I stayed away from the last 64 bytes of eeprom as stated in 21.14.11.

Storing all of my preset variables in an array of structs and passing writeEEPROM the address and sizeof the array of structs works super! I can't speak to portability across N different compilers, but gcc handles this well. Alignment bytes will of course also be stored, but this isn't a problem. You need to look at the structure and see if the extra bytes are acceptable loss of eeprom space for your purposes.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Tue Apr 16 16:38:27 MST 2013

Quote: a.unique.identifier
2. Do I need to be concerned about wearing out the EEPROM with to many write cycles? If this is an issue, I suppose I simply have to loop my writes through the EEPROM address space.

Usually Wear Out endurance is far better than min. or typ. values in datasheet :)

See: #1 of http://knowledgebase.nxp.com/showthread.php?t=4321

lpcware · ‎06-15-2016

Content originally posted in LPCWare by tha on Tue Apr 16 16:31:06 MST 2013
You need to disable the interrupts when accessing the EEPROM. If an interrupt occurs during an EEPROM access, a hard fault can occur.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cfb on Tue Apr 16 15:43:37 MST 2013

Quote: a.unique.identifier
... any comments about the other items?

I'm not 100% sure without any other documentation from NXP or without doing the experiments that you could do yourself but I would bet on the following:

1. Yes.
3. Agreed.
4. Agreed.
5. Possibly, yes.

I would also use the 'struct' method to store a group of related variables in EEPROM. That is exactly the method I used for the Oberon example I published last month:

http://www.astrobe.com/forum/viewtopic.php?f=9&t=277

However, when using C you have to make sure that all aspects of the definition of the struct you use for writing are identical to the one used for reading (alignment, packing etc.)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by a.unique.identifier on Tue Apr 16 10:25:25 MST 2013
Thanks!
@cfb: I've gotten so used to looking at the User Manual... any comments about the other items?

@R2D2: My basic assumption is that an array of structs would be stored in contiguous memory locations, including the unsed alignment bytes. I would simply save and restore the unsed bytes along with the used data. Did you have another suggestion?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Tue Apr 16 02:02:57 MST 2013

Quote: a.unique.identifier
Since the variables in a structure are contiguous, this should work out okay.

Yes and No :) GCC spaces (to align data) in your struct can ruin that. See 'Packed Structures': http://support.code-red-tech.com/CodeRedWiki/PackedStructs

Quote: a.unique.identifier
Is this the best method and memory for this purpose?

At least an usual method.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cfb on Tue Apr 16 01:19:08 MST 2013
2. The EEPROM characteristics are listed in Section 10.1 of the LPC1315/16/17/45/46/47 Product data sheet.