EEPROM Reliability - Bit decay?

[SherpaDoug]

Does anyone have reliability problems with flash PICs? Are there good programmers and poor programmers?

I have used Dataman 40 & 48 programmers with PIC C type EPROM chips for years without problems. I have been using my Dataman 48 with PIC16F628A chips on small R&D projects for months with no known problems. Being R&D there are lots of failures and some are still unexplained.

Now I have a pilot run of 25 boards with PIC18F2585's on them and all programmed fine initially. They even passed verification at +/- 5% VCC and ran OK for a few hours. But after sitting on the shelf for a week 6 boards won't start and one has had its serial number in data EEPROM turn to garbage.

About ten years ago I worked for a company that did development work with (Motorola) flash chips. But anything sent to a customer had to use EPROM type chips as they didn't consider flash reliable. I assumed things have improved since. Maybe they haven't?
_________________
The search for better is endless. Instead simply find very good and get the job done.

[Ttelmah]

UV EEPROM, and flash, both suffer from long term decay of the data, but not normally in the sort of time-scales you are talking about. I have some flash stuff still holding data OK, in chips programmed over ten years ago. However The only really reliable storage is forms like OTP PROM,.
Verification, should normally involve reading significantly 'outside' the normal running voltage range, since the commonest problem is with cells that are holding a a 'borderline' charge, and altering the operating voltage changes the gate threshold, and will show this. You have done this.
The commonest things that would cause mass erasures like this, would be:
1) Faulty chip batch.
2) Radiation.
Now, if your shelf, had something like a calibration radiation source sitting on it, or an X-ray machine running next door, the second possibility applies. Otherwise, I'd be looking at the first...
The fact that the EEPROM is also showing the same erasure problem (this has a slightly different structure), really does say these are the choices.
Get the actual batch number and date code off the chips, and talk directly to MicroChip.

Best Wishes

[PCM programmer]

The Microchip forum has several threads on flash corruption.
These are just a few of them. There are a lot more:
http://forum.microchip.com/tm.aspx?m=327429
http://forum.microchip.com/tm.aspx?m=342033
http://forum.microchip.com/tm.aspx?m=239440
http://forum.microchip.com/tm.aspx?m=15294
http://forum.microchip.com/tm.aspx?m=347378

To find more threads, go to the search page here:
http://forum.microchip.com/search.aspx
In the "Search Term" box (not the topmost box on the page) type in:
flash corrupted
or also try
flash corruption


Here are two threads on the CCS forum about corrupted flash:
http://www.ccsinfo.com/forum/viewtopic.php?t=34563
http://www.ccsinfo.com/forum/viewtopic.php?t=30723

[libor]

According to the datasheet the operating range of a normal, 5V 18Fxxxx series chip is 4.2 - 5.5V and 2.0 - 5.5V for the LF series. The datasheet says that programming both the Data EEPROM and the Program Flash Memory is allowed thru all the operating voltage range.

Am I right with the assumption that programming the flash (ie. putting electrons in those cells) is more reliable at the highest allowed operating voltage (when you put more electrons to have plenty to decay from) than let's say if you program your LF chip at 2.0V ?

I have some devices with normal 5V chips deliberately running at 4.3 - 4.5 V (it is well within specifications). I made this voltage drop to be able to better catch signals from 3V parts sparing the level shifting in the upwards direction. However I have some worries about my bootloader working OK in the long term and also about the lifespan of the reduced number of electrons in those cells with this operating/programming voltage nearing the lower limit.
I would worry even more with a LF series chip running at let's say 2.0V.
Theoretically, would it be the "safest" to program them at the highest allowable voltage 5.5 V ? (ie. would you program your Mars Explorer running on 2V an LF series PIC at 2V ? or would you disconnect the PIC from the rest of the board and program it at 5.5V ?)

Would it be a good idea to include an automatic "refresh program memory" function into the bootloader? It would read the flash let's say once a month or at every xth power-on or upon demand and write it back to the same location refilling the runaway electrons ?

Regarding the data EEPROM (if you write it often): I have read somewhere that writing to a cell in a flash affects physically neighbouring cells' state (charge) a little, but it is the scenario that causes the most trouble. (I don't know how physical proximity on the silicon translates to address space.) So it is advised the refresh also the neighbouring unwritten cells once in a while (ie. all the Data EEPROM even in case you keep on writing into a few locations only) ...and also use a wear-distributing algorithm in such case of course.

Any thoughts ?

[Ttelmah]

The actual programming uses a higher voltage internally. There is a charge-pump inside the chip, that generates the programming voltage. _Stability_ is far more important, than actual level.
Circuit/software things that lead to problems are:
1) The MCLR line. This (on the latter chips), feeds a reference, that turns on the charge pump. As such, it does not have any of the normal protection diodes. If this goes above Vdd, programming can become triggered.
2) Having LVP enabled. This then allows patterns on the two logic lines used to trigger this, to also enable programming.
3) Lack of protection on the programming code. just as with watchdog code, this needs to be written, so it has a 'dummy' routine in front of it, that will prevent any random execution 'walking' through memory, from reaching the program component, and the component itself, needs to have careful checks to verify that it _should_ execute, before the actual component is called.
4) Spikes on a number of lines. The LVP pins, can still trigger programming, if LVP is turned off, in some cases, when too much reliance is placed on the internal protection diodes...

Yes, refreshing, may be worthwhile, but only at very long intervals.

Now, I must admit, I based my original reply, on a number of 'premises':
First, that the data loss had occurred on 'not used' boards, that are identical to others that have not done this.
Second, that at least one of the boards was being powered up in exactly the same environment as the other boards that didn't show this.
These rather rule out the likely 'operational' causes (noise on the supply, poorly protected code, etc. etc.), making the likely problems hardware related. However if these premises are wrong, then the probability of one of the other failure modes becomes greater.

Best Wishes

[libor]

[SherpaDoug]

In my case the one board with a corrupt serial number actually had the data EEPROM change, but that is only one bad apple out if the 25. On the others I read out correct hex code so it can not be bad program EEPROM. Some boards even started working again the next day!

I am looking into hardware and VCC rise & fall times now. Please wish me luck.
_________________
The search for better is endless. Instead simply find very good and get the job done.