Hi, Bob, well, now that's very interesting! By the way: I heart in a seminar, that MC invented a new storage cell (year= s ago) which allows making the chip smaller and cheaper. Do we have to live with unreliable PROGRAM storage space also? I'll make an analysis first before we go into deeper discussion. I want to know, from which batch the failing devices are, then I let you know. Very interesting was the hint about brown out, because my customers always use the device until battery is dead. And the 12F519 has no brown out detection... Regards Peter > Hi, all, > > I designed a small device about 2 years ago, which can be operated in=20 > two different modes. Switching to mode 2 is only done here at the=20 > factory by pressing a key in a specific pattern (Press 10 seconds,=20 > then wait until light is off, then release key between 2 and 4=20 > seconds, wait until light is on again, then press 4 times within 3=20 > seconds, someting like that). The state of mode is stored in eeprom=20 > address 00, 0x00 for mode 1, 0x80 for mode 2. > > Now during the last 3 weeks about 10 customers called to tell, that=20 > the device is suddenly operating in mode 2, even if it was shipped in mod= e 1. > The procedure to change mode was never made available to the public=20 > and futhermore there is no advantage at all for most customers to change mode. > > Question: Does anybody have information about the reliability of=20 > eeprom content? > How is it possible that eeprom content changes (electric field,=20 > magnetic fields or or or) > I spend several weeks on this, finally pinning the problem on our Blessed Microchip (sigh). First: carefully search the archives for ANY EEPROM failures before the PIC12F/16F/18Fxxxx series devices were released. I can count on less than one finger's worth. And I designed the EEPROM into everything, making configuration storage, calibration tables, everything. Second: Microchip releases many PIC12F/PIC16F/PIC18F devices, and then begins to make excuses for EEPROM failures. What happened was that when Microchip reduced the die size on the PIC12/PIC16F/PIC18F devices, the cell size was reduced to an almost unworkable size. Having gone to an unworkable cell size, they can't go back and fix it. If you search carefully, you will notice that Microchip recommends rewriting (refreshing) the EEPROM cell array periodically. But I uncovered a BETTER way: Write 5 copies of your variables into the cell array. When you read them, read all 5 copies into a buffer. (1) IF ALL ARE IDENTICAL, use the copy and you are done; (2) if 3 or more of the 5 sets are identical, use one of the = 3 same copies as "good" as data, then rewrite all 5 copies of the array. If less than 3 are identical, you are screwed... but guess what, I NEVER saw that happen. What seems to happen is that one or more bits are changed over a year's period, and this corrects them. The advantage over Microchip's method is that there is a MAX rewrite limit. My method only rewrites when there is a true error, so the limit is very unlikely to be reached. This method, that I call "Best of 5", always works for me. Otherwise, drop the internal PIC EEPROM and use an external EEPROM, which does not have super small cells. --Bob A ------------------------------------------------ -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membershi= p options at http://mailman.mit.edu/mailman/listinfo/piclist --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .