2016-12-30 11:10 PM
Hi!
What are the possible ways in which the above mentioned EEPROM could produce corrupt data?
There are issues faced when reading the data written into the EEPROM.
The issues occur at completely random times and have no definite pattern.
Could anyone tell me the possible ways which might lead to this occurrence?
Thanks!
#failure #eeprom #m24m02-dr #read-error2016-12-30 11:56 PM
Typical mistakes are either SW or HW.
For HW:
a. EEPROM Power supply pins were not properly connected resulting in erratic behaviour
b. Wrong or missing pull-up resistors on SDA and SCL lines
c. Use an oscilloscope to monitor the signals to make sure they look clean and not too glitchy or noisy
For SW:
a. Use first a simple SW bitbanging I2C emulation to test the physical layer
https://community.st.com/0D50X00009XkW1mSAF
https://community.st.com/0D50X00009XkW1qSAF
b. Slave devices don't have a reset pin. If the MCU is individually reset (by debugger) and restarted, the I2C communication with the EEPROM might have been interrupted at the wrong time (Murphy's law) and communication after the hot reset may fail. See the example code on I2C Quick Checklist for 'error recovery'
b. When writing data to EEPROM, wait 10 msec after the last stop bit from the writing transaction.
c. The EEPROM has 256 bytes pages. Writing 16 bytes from address 0x108 to 0x118 is ok while from 0x1F8 to 0x208 if not (different pages).
d. I2C communication should be handled if possible in only one place of the source code. Don't put I2C communication software on both an interrupt handler and the main loop. One communication may interrupt one in progress.
e. Protocol is wrong, data corruption/pointer issue
These are typical mistakes, innovation lurks here so new ones are created to be discovered!
Good luck!