I am using M95512-W M95512-RM95512-DF eeprom for storing my data.
But sometimes it's not storing bytes I want. Instead of it, it's storing successive (wrong)bytes.
Can this occurs because I don't place any wait between two byte writes ?
EEPROM writes/reads wrong bytes
eeprom
Related Solutions
It's not just write cycles that's specified, but erase/write cycles. On the AVR EEPROM can be erased by byte. Erasing sets all bits to 1, writing selectively clears bits. You can't program a 1, just 0s. If you want to set at least one bit to 1 you have to erase that byte.
Erasing removes the charges from the FET's floating gate, but on each erase cycle some of the charge remains on the floating gate, which won't be removed through the quantum tunneling. This charges accumulates and after a number of cycles there's so much charge left on the floating gate that the bit still will read 0 after erasure. That's what determines EEPROM life, it's erasure rather than writing. So you can safely write additional 0s, as long as you don't erase.
As a result, if the datasheet specifies 100k erase/write cycles you can have maximum 800k write cycles, one bit at a time, for 100k erasures.
If you're using only part of the EEPROM memory space you can extend its life by distributing the data, like Matt says this is called wear leveling.
The simplest method of wear leveling when writing blocks of data is to include a counter with the data. Suppose you need to keep 14 bytes of data. Add a 17-bit counter as two bytes, you probably have a bit to spare for the 17th bit. Increment the counter before writing the block of 16 bytes. If the counter has reached 100 000 you know this block is becoming unreliable, so you move to the next 16 bytes. Use this until it is worn as well. And so on. A 4k memory consists of 256 sixteen byte blocks, so you can extend the original 100k cycles to 25 million.
It should be obvious that your gain is greater with smaller blocks of data.
further reading
data retention on a microcontroller
You're reading the data after clock is low again. You'll have to do that between making the clock high and making it low. After the clock is low the slave is allowed to change the data line, not while it's high.
So reading should be like this:
wait
SCL low
SDA high
for each bit (8 bits)
SCL high <--------
wait
check and store received bit <--------
wait
SCL low <--------
wait
wait
do a NACK or ACK depending on if it is the last byte
Related Topic
- Electronic – Unable to use compiler built-in functions to write to dsPIC EEPROM
- 25AA320A EEPROM byte write and page write
- Electronic – Why are EEPROM sizes measured in “k” or kbit and not kbyte or byte
- Writing 3 bytes data in EEPROM
- Electronic – EEPROM Write Cycle Time and Write Cycle Endurance
- Electronic – Flash and EEPROM
- EEPROM 93C66 dumthe bit problem
- Electronic – Do eeprom page writes always cost the same time as byte writes
Best Answer
I think you need to work at some more detailed unit testing of your software routines that you use to write to the EEPROM. When you do the tests make sure to keep the low level code the same as the failing case to you can keep the scenario close to what happens now.
The simplest test is to use a known data pattern in your test so it is possible to spot patterns in the result that may reveal just what may be going wrong. Try patterns such as:
Data sequence of 0x00, 0xFF, 0x00, 0xFF repeating through a large block.
Data sequence of 0x55, 0xAA, 0x55, 0xAA repeating through a large block.
Data counting sequence of 0x00, 0x01, 0x02 ... 0xFF, 0x00, 0x01 repeating in a block.
Data sequence of two bytes storing the even numbered address address of location as the data.
When you read back the results from these you can tell if bytes are simply missing in the stream, whether extra bytes are sneaking in, some bytes are simply getting wrong values and whether the values that are wrong have any resemblance to the expected value at the wrong location.
You may be having problems in several areas:
You may have a bug in your software driver
There may be signal integrity problems with your handling of the part electrically
You may have coded a protocol error in how you try to talk to the EEPROM
With the specific device that you are using you can write from one byte up to the number of bytes in a "page". When you let the Chip Select pin go high an internally timed 5 msec write cycle happens to place the new data into the array. You either need to delay the 5 msec in your software before the next write is attempted or poll the status register till you see the "Write In Progress" bit clear.
Another thing to consider is that if you are storing multiple byte sequences in one write cycle and are not comprehending "page" boundaries correctly you could be experiencing "roll over" within a page. For example if you were logging a sequential data storage of 7 bytes per write operation to address 0x0000 then 0x0007 etc you would get to the end of the "page" when the write of the next 7 bytes spans across the end of the current page into the beginning of the next page. If you are not accounting for that in your algorithm the bytes that span into the "next page" in fact get written into the beginning part of the "current page". A correct algorithm would need to break up a spanning write into two separate write commands - one to store the last bytes into the current page and the second one to write the remaining bytes into the next page.
Note that the "roll over" problem is a common error in this type of device application.