View previous topic :: View next topic |
Author |
Message |
nilsener
Joined: 06 Dec 2005 Posts: 59
|
I2C Serial EEPROM and to handle writes to wrong address? |
Posted: Mon Oct 15, 2007 9:39 am |
|
|
Dear,
I use external I2C serial EEPROM 24C02C (256 Byte). Now it may be that a disturbance (or whatever) on the I2C lines during a write cycle changes the address byte and the payload data will be written to this wrong address. The main problem then is, that the data at the written address are lost and can not be recovered.
I can verify the write by a read and then write again, but the data at the wrong address are still lost. This results in permanent malfunction of the unit.
I can copy the entire EEPROM to RAM before writing and write back the RAM if the problem occurs. But this may not be the prefered solution if I think about a serial EEPROM with 1 MByte. It needs a lot of time then and is a problem if power will lost = RAM will lost.
Sometimes I think I have more to trust in I2C write cycle, but one can not be 100% sure that this problem never occurs??!!
Has someone an idea how to handle this problem?
Thanks for any help!
nilsener |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Oct 15, 2007 1:33 pm |
|
|
Is this a real or a theoretical problem ?
If it's a real problem (a current one) then I would fix the underlying
electrical problem with the board.
If it's theoretical and you just want added protection, then consider
using a checksum on each block of data written to the eeprom.
Then write multiple copies of the data in different segments of the
eeprom. These will be your backup copies. Whenever you read
a block of data, verify that the checksum is correct. If not, then
read the backup copy. Verify the checksum on that one, too.
If you're really concerned, then maybe put a 2nd eeprom on the
board for your backup data. You could put it on a 2nd i2c bus as well. |
|
![](templates/subSilver/images/spacer.gif) |
Wayne_
Joined: 10 Oct 2007 Posts: 681
|
|
Posted: Wed Oct 17, 2007 2:08 am |
|
|
How do you know it is being written to the wrong address ?
You say the data is being lost, how can you then verify it ?
Have you got some code you can post ?
What is the eeprom part you are using, does it allow for writes to individual addresses or do you have to do block writes to areas of memory ? |
|
![](templates/subSilver/images/spacer.gif) |
nilsener
Joined: 06 Dec 2005 Posts: 59
|
|
Posted: Fri Aug 22, 2008 7:42 am |
|
|
Dear PCM, Dear Wayne,
thanks for help and sorry for late answer. Now I am back to the project.
> How do you know it is being written to the wrong address ?
I don't know it, but if the verify fails it may be that data was written to a wrong address.
> You say the data is being lost, how can you then verify it ?
For example: I write data to address 100 in the eeprom. Then I verify if data was written correctly to address 100. If verify fails, then it is possible that the data was written to an other random unknown address where e.g. calibration data was stored before. Those calibration data are lost then and then the whole unit is defect because it needs its calibration data. I think it can not be granted that every address-bit on the I2C Bus will be transmitted correctly over the whole livetime of the unit of approx. 15 years. So all depends on this one single address-bit that was disturbed at anytime.
What do you think? Should I be afraid of this single bit that appears at anytime or am I really paranoid?
> What is the eeprom part you are using, does it allow for writes to individual addresses or do you have to do block writes to areas of memory ?
Now I have 24LC64 from Microchip. Every address can be written individual.
At the moment I see now other way to store the data redundant in two 24LC64 that are at different I2C lines. But I think this is not the basic idea of serial eeproms and I2C bus?!
Thanks for posting any ideas.
nilsener |
|
![](templates/subSilver/images/spacer.gif) |
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Fri Aug 22, 2008 8:30 am |
|
|
As I understand it correctly you want to handle a theoretical problem?
Theoretical data error problems are handled in software. An actual data error problem is best fixed in hardware.
Using two EEPROMs and two I2C buses is expensive and not the normal way to go.
For data critical to your application you always have to implement measures to protect the data, this involves two mechanisms:
1) Error detecting
2) Error recovery
Error Detecting
Depending on the nature and amount of your data there have been published many methods for error detecting. A very popular method is the use of a checksum, this is a value calculated over the total of your data and stored together with the data. On retrieving the data you calculate the checksum again and compare this to the checksum stored with the data. If the two values don't match you know there is an error.
A simple checksum calculation method is to add all the data values but has the disadvantage that some common errors are not detected. A better method is Cyclic Redundancy Check (CRC), this is guaranteed to detect a single wrong bit and, depending on implementation, combinations of multiple bits.
Example code can be found in the code library: CRC8, CRC16
Error Correction
When an error is detected you need a method for correcting the data. Again many methods have been published, use Google.
A very simple method is to store the data multiple times, including a checksum of course. Depending on how important your data is you store the data two or more times. If reading one data block fails you read the second corresponding block. With the checksum being OK you can use the data of the second block to correct the data in the first block again. |
|
![](templates/subSilver/images/spacer.gif) |
|