I agree with you, it has to do with the micro itself. Whatever fails, it fails on the micro's die!


I'm absolutely sure, that ALL manufacturers have problems with their die layout and spend enormous time and efforts to get the micro working. This can easily be seen from the numerous notes in the datasheets, that you must take care that the capacitive load on this and that line must be less than this and that level. There are application notes that discuss how to fix noise on ALE signal, how to use brown-out detectors, how to decouple properly and and and, which clearly demonstrates that there ARE problems. A very nice example can be seen in the link I gave you in an earlier post discussing the flash corruption of Cygnal's F124:

http://www.cygnal.org/ubb/Forum1/HTML/000676.html

When you carefully read this discussion you can clearly see, that Cygnal has made a mistake somewhere and misused the forum comunity as cheap testers...


I would immediately change the reset practise, but I also have to convince my boss! Look, Richard, the problem is, that the manufacturers tell, that a proper brown-out detector (reset chip) will solve any flash code memory corruption problem. If I follow this recommendation and some micro despite of that fails, I can always tell my boss: "Look, what's happened. But I'm not guilty, because I did what the manufacturers recommended. So, we must have a bad chip here."

The problem is, that EVERY serious designer fears this issue, and that we all want to cling to any manufacturer's recommendation which gives us the feeling to do the things properly and that we, because of that, too willingly want to believe the manufacturers.


It's my strong believe, that there ARE some development teams who do these tests, but that the results will never reach the publicity. No single article, application note or datasheet was ever published by the true engineers, the true developers and the true designers, but by these fucking super smart marketing assholes, who know less about electronics than a 10 year old boy.


I really appreciate your attitude! It's exactly what NASA does, when handling a problem and I like very much the way you go into the detail.


I'm heavily interested in your results, because I'm not very happy with the status quo either.

My little theory about flash memory corruption (not only the flash code memory of micros but also the naked flash memories) is, that flash corruption is more likely to happen with

- setups mounted on bread boards or using wire wrapping,
- noisy port lines
- fast spikes on Vcc
- all too fast power-ups and -downs
- improperly decoupled circuits
- improper reset signals
- ill running micros.

It's very interesting to analyze the situation of naked flash memories, like AT29C256 for instance, and to look what there leads to flash corruption:

http://www.atmel.com/dyn/resou...OC0046.PDF

This chip also has self timed automatic burning and erasing routines, which can eroneously be invoked during power failure situations. Here also a brown-out detection and power-on reset is implemented, doing the same as the MAX1232 with a flash micro, namely to block any flash erasing or burning during power failure situations. (Take note, that this reset of flash memory activities has nothing to do with the reset issue of 8052, since the flash in the flash micros was added many years later, and I trust the manufacturers that they are capable to inhibit unallowed flash activities by the help of a proper reset signal.)

What is new, is the fact, that the !CE and !WE lines appear to be a path for noise entering the micro and to cause trouble! Datasheet tells, that noise filters are internally implemented, so that noise spikes on these lines of less than 15nsec will not initiate a program cycle. That's really interesting!! So, noise on the port lines of micro, yes, even noise on ANY line of the micro also seems to be a serious problem, just what I have experienced sometimes in the past.

Interesting is the fact, that no manufacturer of flash micros mentions this, allthough it's mentioned with the naked flash memories at the same time!

Another way to invoke flash corruption of naked flash memories is an ill running micro. An ill running mirco can just accidentally jump to the routines which addresses the flash memory and by this initiate an non intended programm cycle. The best remedy against this is a brown-detection, which resets the mirco (programm counter), assuming that a brown-out condition is what led the micro to run ill, of course.

This leads to an interesting question: Are there other things that can cause the micro to run ill, beside the simple brown-out conditions?
Oh, yes, there are! Again, noise, spikes and glitches on the port lines, yes, on any lines of the micro can make the micro to run ill. Events, which standardly are not detected by the brown-out detector!!


Conclusion:
To avoid code memory corruption of flash micros keep an eye on the following points:

1. Avoid noise, spikes and glitches of all kind on all lines of the micro! Add filters if needed, especially for Vcc, of course. Add shielding if needed. What ever happens, not even one single glitch must appear on any of the micro's lines!
It's a good idea to think of the micro as being an analog chip...

2. Use multilayer boards containing a solid ground plane to keep all line inductances low and by this ground bounce and ringing.

3. Use a good reset chip providing a proper power-on reset and brown-out detection. Not only to reset the micro, but mainly to reset the ISP section of micro and by this to stop all flash activities during power failure situations.

4. Avoid too fast power-ups and -downs.

5. Pray to God, that you haven't anything overlooked...

This is what worked properly for me in the past. I think the noise issue is a bit overlooked by many designers.


Kai