Serial EEPROM Memory, um.... Forgets
Serial EEPROM Memory, um.... Forgets
(OP)
We have been using 93C46 serial EEPROMs (usually from Microchip, but also TI/Fairchild, Atmel, others) in our products for a number of years to maintain instrument-specific data such as serial numbers.
In the last few years we are experiencing an increasing trickle of field failures of these parts. When they return to us, their contents have been corrupted, usually only in a few cells. The most common occurrence is $FFFF at the top address; also commonly we see the bottom address corrupted, or random cells in the middle. The most common value is $FFFF, but we have seen others.
The failures appear to be quite rare, but happen often enough in the field that they are a concern. However, we have not been able to recreate them in captivity, so we're not sure how to fix them. The failures span several products and situations with very little in common in terms of surrounding logic. We're following pretty solid design practices in terms of making sure we're not attempting to talk to the parts during power cycles, keeping supplies clean, avoiding glitches, etc.
Elsewhere on this forum I noticed some references to some unreliability from Microchip parts. Is there any substance to this claim?
Any idea what might be getting us in trouble?
Thanks
lownoise
In the last few years we are experiencing an increasing trickle of field failures of these parts. When they return to us, their contents have been corrupted, usually only in a few cells. The most common occurrence is $FFFF at the top address; also commonly we see the bottom address corrupted, or random cells in the middle. The most common value is $FFFF, but we have seen others.
The failures appear to be quite rare, but happen often enough in the field that they are a concern. However, we have not been able to recreate them in captivity, so we're not sure how to fix them. The failures span several products and situations with very little in common in terms of surrounding logic. We're following pretty solid design practices in terms of making sure we're not attempting to talk to the parts during power cycles, keeping supplies clean, avoiding glitches, etc.
Elsewhere on this forum I noticed some references to some unreliability from Microchip parts. Is there any substance to this claim?
Any idea what might be getting us in trouble?
Thanks
lownoise





RE: Serial EEPROM Memory, um.... Forgets
RE: Serial EEPROM Memory, um.... Forgets
Although, I don't doubt that you've done due diligence with the design, you've left unanswered two issues:
1. Are the corrupted cells permanently damaged? It's possible to do margin testing on memory devices to determine if there is any degradation of the threshold characteristics of the memory.
2. The specificity of the locations are interesting. Are there specific reasons why those cells might be cycled more than the rest?
If there is no obvious issue with cell margins, then the pattern failure would suggest that there is some operational/initialization problem heretofore unknown that causes a hiccup in the program.
TTFN
RE: Serial EEPROM Memory, um.... Forgets
RE: Serial EEPROM Memory, um.... Forgets
The problem is not one of maximum cycles; the data is written very rarely - nominally, only when the product is produced, and perhaps another time or two if the product is ever serviced.
The data is read more often; perhaps a few times a day, maybe as many as a few hundred.
We have not been able to find any evidence of a problem in the program. Being mostly a hardware guy, I suspected this at first too, but the code is pretty simple and the situation straightforward. We can't find a weakness there, though I suppose since we can't find a weakness anywhere, it's as likely there as anywhere else...
RE: Serial EEPROM Memory, um.... Forgets
(In a few cases they are connected to configurable logic devices which take some time to 'wake up' and drive their pins. We have already identified the need to put pull resistors on these guys, but it doesn't account for all the failures).
RE: Serial EEPROM Memory, um.... Forgets
RE: Serial EEPROM Memory, um.... Forgets
You're left with either some sort of problem in the chip itself or some problem with the system that it's installed in.
TTFN
RE: Serial EEPROM Memory, um.... Forgets
Check the power and signal quality, too, especially in situ if possible. Noise and (especially) negative-going spikes in power and signals can affect the charge on the floating gate. Just using "pretty solid design practices" doesn't say that you've actually checked the signal quality. Also, does power quality vary between installations? Are you decoupling the parts properly? Have your suppliers FAEs review your design.
If the failures occur across suppliers it points to a design (or SW) problem. If it's mostly with Microchip, but your volume is mostly Microchip, then you should determine failure rates vs. supplier, too.
--
Mike Kirschner
Design Chain Associates, LLC
http://www.designchainassociates.com
RE: Serial EEPROM Memory, um.... Forgets
RE: Serial EEPROM Memory, um.... Forgets
TTFN
RE: Serial EEPROM Memory, um.... Forgets
RE: Serial EEPROM Memory, um.... Forgets
Some years ago I had the same problem, and the solution I found was the one from some Microchip's app note that avoid the memory to be corrupted. Basically it is a 10uF capacitor between memory's Vcc and GND, but the Vcc from the system comes to the memory trough a diode, which doesn't allow to tranfer the capacitor's current to the circuit when the energy turns off. Under this schema my memories seem to work apropiatly. However change the memorie's brand. Now I'm using them exclusively from Atmel