Several years ago, I was playing with 8051 in a physically small on-off that was acting strangely. In the course of my investigation, I noted that the external BBRAM I was using with it was frequently corrupted. This was not an ISP-capable or even FLASH-based part. It was an AMD 8751 of 1980 or thereabouts vintage. What I had done was to wire up a circuit based on an application example, including the "classic" RC reset circuit with the 10 uF cap and 8K2 pulldown resistor. With the exception of the program store corruption, everything seemed to work properly. Consequently, I was poking around in the circuit to see whether I could find any cause.

At one point, having read the tales about flash corruption, I added that old DS1232 supervisor to the circuit, hoping that the problem would "go away" as it often had done for others. However, that was not what it did.

Now, this was a very small board, wire-wrapped with very little space for any other components, and some of the decoupling cap's were pretty sizeable eletrolytics, because I had them on the table when I built the circuit. I suspected something was peculiar in connection with the RESET during power-down. Only then did I discover that external memory was being accessed despite the presence of active RESET. That was not an ISP-capable MCU, nor was it flash-based. I had, of course, the opportunity to examine the BBRAM content in a programmer, which is how I reprogrammed the part. That's how I knew the BBRAM was, in fact, being corrupted. If it had been a FLASH-based part, I probably never would have noticed that this was happening, since I can't put 'scope probes on the internals of the MCU.

I did, however, put probes on RESET, nRD, nWR, and nPS. Once I saw activity on the three external memory controls during RESET. I substituted several other 805x's, as this was actually an 8031 circuit, since I'd not programmed the internal EPROM. The behavior with respect to the BBRAM was consistent throughout, though I did not verify that the content of the BBRAM was always modified in the same way. When I removed the 330 uF electrolytic from the Vdd rail, the problem "went away" ... almost ... and when I set the circuit up on a test fixture that repeated the set of stimuli needed to cycle power and RESET, I found that the occurrence of this post-RESET run-on occurred seldom once the swamping capacitor on Vdd was removed, but not entirely. At the time, I did not monitor Vdd during the repetitive experiment, though I did monitor those three external memory control signals during RESET. Whenever this event occurred, the system took note. Since it was already set up for 1000-hour testing, that's how long I ran it with the swamping cap removed. I don't remember how many times it occurred, though I suppose it's on a printout somewhere. It was much less frequent than with the swamping cap in place, as it occurred nearly every dozen-or-thereabouts repetitions, with that cap in place, which was based simply on the fact I had to reload the BBRAM about that often. I really don't know what I should conclude from this, as it was not a rigorous examination.

BTW, I don't dislike the ATMEL parts, as I've not used them. I do, however, dislike the ATMEL corporate culture, as demonstrated in that incident I have repeatedly described, and which I won't repeat here. That incident persuaded me that, so long as there were other manufacturers who produce suitable components, I don't have to subject myself of my clients to the ATMEL abuses. It's just a personal choice, but it did cost a lot of time and money, resulting, probably, in a lost opportunity in the market. This was caused by their culture of consistently denying their faults and lying about what was going on in their development, assuring us that things were just fine, when it was quite apparent that they were not.

If you use ATMEL products, by your own choice or someone else's, I bear you no ill will. I just won't use their products myself, nor will I ever recommend them to anyone else, unless I see a major change in their corporate culture. I admit that my experience was restricted to one with a French design team, and this sort of behavior is an established and centuries old culture in France, but it did not make me a trusting and loyal ATMEL customer.

The fact that I don't use their products doesn't prevent me from reading their datasheets and white-papers, though it does leave me somewhat suspicious of what they say.

RE