LM4F EEPROM reads and writes and the 'copy buffer'

At risk of your/others ire - is use of such a relatively new feature w/in this class MCU completely wise?  Realize that 5 pin sot-23-5 EEProms exist - tiny, low-cost and eliminate many/most of your listed (rightful) concerns.  And - might there be further concerns - yet to bubble up?  (i.e. does not MCU errata exist here - other vendors too?)

Sure FoMoCo, GM need to squeeze every penny.  But if your firm at all like ours - that level cost management & product detail may be outside your best interest.  Slightest issue becomes damning when profit level rings too low.

Does not the dearth of write-up detail - as you've noted - suggest that this is infant technology as used here - and may not yet have passed the test of time?  Safe-harbor alternate exists - and size/cost penalty is minimal - suggest that you at minimum add as, long "tested/proven" and eased - back-up. 

cb1_mobile,

Thanks for your thoughts.  My experience with on-chip off-chip EE is different from yours.  I once used an off-chip SPI EE chip and have never bled so much over an implementation.  In every off-chip EE implementation I have used there is a CS-active -> send cmd -> send addr -> send data -> CS-inactive sequence.  But often the read and write commands differ only by a bit.  So if your board has relays, or if you are connected to relays/solenoids, it is easy to flip a bit, messing up cmd, addr or data.  In the one implementation that I had trouble with, we actually ran a CRC algoritm and stored the CRC on chip.  So we often caught the EE scrambled, but did not have the code space to unscramble or return to defaults.

The on-chip approaches I have used have never demonstrated a clear corruption; but, I have never implemented a CRC.  On-chip EE could be corrupted as much as my off-chip experience.

If I were worried about nascent technology, I probably would not be using the LM4F at all.  We have been waiting for 'released' silicon for almost a year.  But the AVR we are using is so long in the tooth, I do not give it much hope of it surviving the next recession.  I need to jump to something. 

What I take from your comment is:  If I choose to use on-chip EE, I need to verify for my self that the LM4F EE is dependable.  We have written tests for timing on EE R/W cycles, but not for read-write-modify-verify cycles.  I will need to write those tests.

Well argued mon ami - at minimum we've established some dialogue even though our experiences/comforts diverge.

While I know of no reported weaknesses w/subject peripheral - this vendor - must question why this arrives so late - and w/so much else erupting.  Do you believe this late, add-on peripheral is being exhaustively screened - say as much as past MCU Reset implementation?

We've thus far escaped your corruption issues - perhaps w/our own version of, "parallel store/voting - critical data" and our attempt to prevent (or at least greatly limit) critical transactions to "noise-free" periods.  Devil may be in the detail, the management - not entirely an off-chip fault.

Might a review of errata - equivalent LX4F vs. matching rebrand part - signal activity/achievement during this polonged LX4 gestation?  And - should known, long past hiccups linger - is adding a "new to this device" capability without challenge - and risk? 

Hi John,

I can try to help address your questions on how the EEPROM works.

The EEPROM is capable of non-blocking writes to individual words, but it doesn't have a way to perform multiple non-blocking writes without processor intervention. The best method we have for writing to the EEPROM with minimal processor intervention is through the EEPROM interrupt vector. The way you would probably want to do this is to write a single EEPROM location somewhere in your code, set up the EEPROM registers to provide an interrupt on write, and then use the EEPROM interrupt handler to initiate the remaining 19 writes one-by-one. For each word, the interrupt would take a few cycles away from your main loop to start the EEPROM controller, but the main processor won't be tied up while each individual word is written. This is what the EEPROMProgramNonBlocking() API was originally intended to do.

The "copy buffer" is not really related to non-blocking reads. It was implemented as a way to safely update EEPROM blocks that are already full. Each block in the EEPROM has space for seven copies of a word, so you can write to the same offset offset seven times without penalty. On the eighth write, the entire block must be erased to make room for the new data. While the block is being erased, the latest copy of every word in the block is temporarily written to the non-volatile "copy buffer". Once the erase is complete, these words are written back to the original block. This way, the words are always present in at least one non-volatile location. Once the copy buffer has been used once, it must be cleared before being used again. This can either be done manually right after the copy operation, or it will be done automatically the next time the copy buffer is needed.

I agree that the documentation on these things is difficult to understand, so I'll feed this back to the documentation team. If my explanation above doesn't help, let me know and I'll try to answer any remaining questions you have.

Regards,

Christian

What does it mean for a block to be full?

What is the difference between a block and a word?  I assume a word is 32 bits on a 32 bit boundary.

So for each word there is a block of seven words?  A kind of moving two word stack that once full has to be reset for the eighth write.

What happens if you implement an interrupt routine and try to read the location while it is being written?

Is there a diagram for what is happening?

Christian,

After a six week hiatus working other higher priorities, I am back to writing faults and configuration data to EE.  I still hope to get answers to my last response to your response (which did start to explain important concepts).  I have even more questions:

If you write a value to EE (for simplicity say a 32 bit value on a 32 bit boundary) and it is the same value that was already stored at that location, is an erase-write cycle still performed?  One implementation I have used to avoid unnecessary 'wait for done' cycles, is to read the value my self, compare desired and current values, and write if necessary.  I have worked with EE that does this in silicon.

So for the TivaWare UG, it describes blocks as large portions (>>32 bit) sections of the entire EE that can be password protected.  Is this the definition of block you are using?  If so, is there one 7-word copy buffer for each word in the block, or for eacn block itself.  So for a 2K EE with three blocks, are there 512 copy buffers or 3?

I believe you have given me enough to design my EE read/write approach.  Thanks.