The following text from the Atmel AT24C512 data sheet:


...has NOTHING to do with the erasing of memory cells inside the EEPROM device. This is all about solving another problem that can exist with some two-wire (I²C) interface parts.

If an I²C part is put into a multi-byte read mode and the master does not send a NACK at the last byte read the slave device will get ready to output the next byte in anticipation of the next clock pulse on the SCL line. If in this case that the next byte has the MSB (first bit out on the serial bus) equal to a "0" the slave device will drive the SDA line to a low level and hold it there. This causes the slave device to be unable to recognize the STOP sequence the master would try to generate!!

If the slave I²C device does not have a timeout built in this condition can persist till the device is reset via a power cycle. The Atmel recommended initialization clocking sequence is one way to get the slave device out of this strange mode in lieu of a power cycling. It simply makes the multi-byte reading process in the two-wire device cycle through the next byte and then end via the master initializer making sure that the SDA is high thus NACKING and legitimately ending the multi-byte read sequence.

It is very important to also realize that even though a master device may not intentionally neglect to send a NACK on the the last byte in a multi-byte read this condition can accidently arise if the the master device is diverted due to a brownout reset, software interrupt bug, watch dog timeout, or even a stray noise spike. In these cases the master device may "restart" itself and yes the slave device remains in this limbo state. Do note that the problem is particularly of concern with slave devices that are designed to work correctly over a wide range of supply voltage. A brownout on a PC board could divert a microcontroller but the serial EEPROM stays waiting happy as can be!!!

Now,..........on the subject of your serial EEPROM ending up erased when you did not expect it. This is an entirely different problem. When you do not install a proper supervisor on the microcontroller and a browout condition happens there is a great likelyhood that the processor will continue to fetch instructions from its memory right on through the low VCC brownout condition. If the VCC goes below the specified legal minimum value the processor core will most certainly execute the code incorrectly. This makes the program run in an uncontrolled manner doing who knows what @^@ !!!!! If there is EEPROM writing and erasing code in the memory of the controller and the VCC bounces in and out of the brownout state the wayward program execution may very well end up in this subroutine or code sequence!! The lesson here it to NEVER build a microcontroller board of this type without installing an accurate and proper brownout detector and reset generator. I happen to be of the opinion that an external IC for this function is the best idea!!

Michael Karas