| ??? 04/12/12 16:52 Read: times |
#187114 - when you're wrong, you're wrong Responding to: ???'s previous message |
Erik Malund said:
I've challenged you on many occasions to show, just as one example, that the "reset problem" that you've apparently encountered more than once, was, in fact, a reset problem. All you've ever said is that your customer stopped complaining after you did whatever you did.
here we go again Richard just will not believe that a supervisor is essential, that is hios problem and I am getting darn tired of him bring it up every time he does not know what else to post here is the documentation: since there is no way of knowing what the processor does when outside its specified voltages, it is essential that when such is the case the processor is held in reset. Thus a supervisor (chip) is essential for good design. This is where you're wrong. When you believe your circuit is misbehaving, you should try to determine WHY it is misbehaving and in what way it is misbehaving. One thing you can do is to attach your logic analyzer to the parts of the circuit that you suspect, and then monitor its behavior through the perceived malfunction. That's how I discovered the MCU running on during decay of Vcc, despite the presence and apparently normal function of the supervisor and it's active RESET signal to the MCU. That was years ago, but I did write about it, though you didn't really understand what it was that I'd discovered. In the days when Richard liked how things were the effect was minimal since the brief time during power down from 'undefined behaviour' to 'no behaviour' rearely did anything long enough to show any ill effects. Now that most of us have moved forward and use flash based designs there is a possibility that a flash write/erase occur during the "power down window" and thus it is essential to grab the processor by the balls during this time. Since the circuit in which I discovered the anomalous behavior was one with external BBRAM, I was very interested in the behavior during active RESET while the Vcc was decaying, since that's where the BBRAM corruption apparently occurred. I also was able to make the problem go away by reducing the Vcc capacitance, hence, reducing the decay time. A later experiment showed that by limiting the rise and fall time of Vcc to much less than 1 ms, I could avoid the occurrence of the BBRAM corruption. Now, I used a DALLAS supervisor, since I was using a DALLAS MCU and a DALLAS BBRAM. IIRC, Kai didn't approve of the use of that Dallas supervisor. However, when I substituted a different manufacturer's MCU, including Intel, AMD, and Philips, I found the same effects. I wrote about all that back in the day. I believe the first truly acrimonious "debate" you and I had resulted from my assertion that this problem went away with the change in Vcc rise and fall time, regardless of the presence of a supervisor. I have made no investigation of the effects of power up, but the reset functionality is essential during power down
Erik I found it confusing that the supervisor, MCU, which had a built-in brownout detector, and BBRAM, all had different notions of what a brownout was, which made it hard to guess what was really going on. However, there was no doubt that the MCUs' continuing to generate nWR signal after the assertion of RESET was probably a problem. The bidirectional RESET on some MCU's can also create some confusion. Some day, perhaps I'll get the hardware that I used to experiment with this stuff back out of storage and play with it some more. the hardware I used for this experiment certainly wasn't what one would want to deploy in a commercial application. As I mentioned back when I originally played with this "problem", I find it odd that manufacturers who've got the necessary resources on hand haven't spend a few hours on this problem, preferring instead to replicate, at least in publication, the inane slow-rise-and-fall RC RESET that Intel cooked up back in the '70's when it didn't matter. I also find it odd that so many designers are simply willing to change their circuitry without pursuing the actual cause of a given malfunction. RE |
