FLiP module EEPROM
Phil Pilgrim (PhiPi)
Posts: 23,514
in Propeller 1
I need to know exactly which component is used for the FLiP module's EEPROM. The reason is that I'm working on an app for a customer in which data could be saved to it, and I need to look up the number of write cycles that it can endure. It could mean the difference between a product lifetime of one year or 99 years.
Thanks,
-Phil
Thanks,
-Phil
Comments
-Phil
Let's say you have one long, such as a total or counter, which changes very frequently. Dedicate not just four bytes but a larger chunk of EEPROM to the purpose of saving it. Start by initializing the whole thing to an illegal value/blank such as $FFFFFFFF. As you change the value, instead of writing to the same four bytes, overwrite the next four bytes, then the next four after that, then the next four after that, until you reach the end of your chunk. Now write $FF to the whole thing and start over.
On recovery, start at the beginning and search for the last value that isn't $FFFFFFFF. There you are, and you've extended your EEPROM's useful life by a factor of chunk_size.
At the datasheet, there are two write modes available for that devices (three in fact, if that part number does indicates it also has ECC correction hardware inside it):
Byte Write - only single bytes are affected by each command (more on this is underway, please keep reading)
Page Write - an entire page (128 bytes) is affected by each command;
To fully understand the ECC detection and correction hardware one needs to understand that, at those parts, ECC operates on blocks of four bytes, whose address correspond to byte0, byte1, byte2 and byte3 of any given LONG, within device's addressable range.
For devices whose part numbers agree with the ones that does have internal ECC hardware, a third write mode does really exists, and it has two ways of operation;
- the first one, when a byte write is commanded, the whole long to wich it pertains is writen, along with the hardware-generated ECC bits (I've found no mention to the number of bits ECC generates/check ECC does generate enough bits to ensure the flagging and correction of up to ONE bit per writen/readen byte). Since this operation is a "commanded write", its not that difficult to account for it, as a write that has being done, in the seek of quantifying the total amount of write cycles the device experiments, before a failure is likely to occur.
-the second one is extremely subtle, because it can can only occur during read cycles, when ECC hardware currently "checks" if any bit of the addressed byte presents a value that "flags" an ECC error. In this case, when an ECC error is flagged during read, ECC hardware does correct it, executing a "someway unauditable" write at the whole long (four bytes) to wich the one that was read (and repaired by such a "ghost writer") pertains.
In short, if you write a byte, four are writen (as per ECC hardware operation). If you read a byte, perhaps, unnoticeably, a write can be taking place too, at the four bytes that pertain to the same word long, thus, if you do a write access to four bytes in sequence (within the same long), four writes are done, at the whole group. If you read four, in sequence, up to four writes "could" be also done, at the (long aligned) group.
Source:
st.com/content/ccc/resource/technical/document/datasheet/e0/4c/87/45/e8/bd/4f/11/CD00251873.pdf/files/CD00251873.pdf/jcr:content/translations/en.CD00251873.pdf
st.com/content/ccc/resource/technical/document/application_note/bd/19/70/43/6b/f2/4d/83/DM00158157.pdf/files/DM00158157.pdf/jcr:content/translations/en.DM00158157.pdf
Henrique
-Phil