I2C EEPROM recommendation (with software write protect to prevent corruption)
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
|||||||||||||
|
Posted by Kevin on March 28, 2006, 1:12 am
Please log in for more thread options 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. -- NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth | |||||||||||||
|
Posted by gibbman on March 28, 2006, 7:38 am
Please log in for more thread options 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 | |||||||||||||
|
Posted by Kevin on March 28, 2006, 9:36 am
Please log in for more thread options
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. -- NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth | |||||||||||||
|
Posted by Luhan on March 28, 2006, 10:31 am
Please log in for more thread options
> 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 | |||||||||||||
>for about 5.50 each. Using some for a data acquisition/logging project
>now.
>Hope it helps,
>Jim