Connect with us

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

Discussion in 'Electronic Design' started by Kevin, Mar 28, 2006.

Scroll to continue with content
  1. Kevin

    Kevin Guest


    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)

    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

    But then I read 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

    Thanks for your advice
  2. gibbman

    gibbman Guest

    FRAMS are available in DIPs. Newark has several....64K
    for about 5.50 each. Using some for a data acquisition/logging project
    Hope it helps,
  3. Kevin

    Kevin Guest

    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).

  4. Luhan

    Luhan Guest

    However I was thinking - while I2C FRAM is much faster at storing data
    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.

Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day