I2C EEPROM recommendation (with software write protect to prevent corruption)

[Kevin]

Hi,

I'm designing a datalogger which contains (among other things) a PIC
and an I2C EEPROM.

I need some advice regarding the I2C EEPROM I should use.

I am trying to ensure that during the course of normal operation (i.e.
no matter what happens to the power supply voltage during
power-up/down) the EEPROM contents will not be corrupted.

The PIC runs off a regulated 5V supply and has power fail detect
circuitry so that it can detect when the regulator input voltage drops
below normal levels so it can write crucial data to EEPROM before 5V
drops below valid levels (I should have enough time to do this). I
plan to enable brownout detect for the PIC so it'll go into reset at
about 4V.

As for the EEPROM choice I was planning on using a 24C01C (Microchip)
because:

it supports page write (16 byte buffer) so I can quickly write data
when power fails
it has a fast write cycle time (1mS for either per byte or page write)
it is rated for 4.5V - 5.5V operation and disables writes when Vcc
falls below about 3.8V or so.
it comes in a DIP package (yeah, yeah, SOICs are more common but my
glasses are already thick enough
Digikey has it

The 24C01 is 128x8 (1Kbit), which is enough for my app.
Both the PIC & 24C01C EEPROM reset at approx the same levels (approx
4V). I was thinking at this point that things should be pretty
reliable.

But then I read
http://www.us.design-reuse.com/articles/article6146.html which
suggests that for greater reliability against corruption I should use
an EEPROM that features software write lock. To quote:
"Using software write-locked memories greatly enhances system-data
integrity. A software write-locked memory requires a special sequence
of writes and reads to occur before the part allows any write requests
to proceed. Another sequence should be available in the device to lock
the part after writing is complete. The longer and more unusual the
unlock sequence, the better the part is protected. Software write
protection is much more effective if the memory is automatically
forced back into the locked state at some time before system power
down, leaving the memory contents secure during both the power up and
power down intervals"

My questions:
1. For my present design (described above) is using the 24C01C (which
doesn't have the software write protection) likely to be reliable?

2. Can someone suggest an I2C EEPROM (prefer DIP) that has the
software write lock function? I have tried looking at both microchip
and atmel's sites but their parametric searches didn't mention this
function. I know some 25xxx SPI EEPROMS have the lock function but I'm
kinda low on spare I/O pins and would prefer to stick with 2 wire I2C.
(I don't need a huge storage space, 128x8 or 256x8 probably will be ok
unless I resort to software error correction or something).

3. I realise there are error correcting codes and other software
techniques that I could use to detect/recover if data has been
corrupted. Are there any simple (i.e. in terms of code size and
execution speed) suggestions that have worked well for anyone?

4. Yes, I know I could use FRAM here - but unfortunately no longer
available in DIPs (I want to try to solve this using EEPROMs
anyway).

Thanks for your advice
Kevin.

 

[gibbman]

FRAMS are available in DIPs. Newark www.newark.com has several....64K
for about 5.50 each. Using some for a data acquisition/logging project
now.
Hope it helps,
Jim

 

[Kevin]

FRAMS are available in DIPs. Newark www.newark.com has several....64K
for about 5.50 each. Using some for a data acquisition/logging project
now.
Hope it helps,
Jim

Thanks for the info. I think Ramtron no longer produces Serial FRAM
DIPs (from looking at their site), so maybe this is old stock.

However I was thinking - while I2C FRAM is much faster at storing data
internally (vs EEPROM) the potential problem of noise causing
corruption still exists. If I understand things correctly FRAM just
writes faster so noise on the SDA line, for instance, could *still*
flip the R/W bit in the control byte and change a read into a write
(or vice versa)? Seems like I2C should have a checksum/crc as part of
the protocol!

Also, unlike the 24C01C (which disables writes at 3.8V) Ramtron's
serial I2C FRAM ICs don't appear to have any sort of voltage level
write disable functionality. To quote:
"Note that the FM24C04A contains no power management circuits other
than a simple internal power-on reset. It is the user’s responsibility
to ensure that VDD is within data sheet tolerances to prevent
incorrect operation."

Based on this I am wondering whether I2C FRAM is really going to be
more reliable in the long term (at least in my app).

Kevin.

 

[Luhan]

However I was thinking - while I2C FRAM is much faster at storing data

internally (vs EEPROM) the potential problem of noise causing
corruption still exists.

Your concerns may be overblown. A properly designed circuit board with
a PIC wired to an EEPROM is unlikely to experience noise. Also, a very
specific coding pattern (8bits) is needed to initiate a write cycle. I
would worry more about the PIC doing a partial reset and vectoring to
its write access code.

Luhan