| ??? 08/11/07 20:41 Read: times |
#143115 - It can, I believe, be done simply. Responding to: ???'s previous message |
Jan Waclawek said:
...
Richard, I completely agree with Kai. The Vcc rise time spec is ONLY and ONLY to make the crappy RC reset to work, there is no, NO other reason for it. Once you accept that RC reset is unsatisfactory in the majority of application and is in the datasheet just to hide the fact that the manufacturer is unable to integrate a true reset/low power detection circuitry and that you need to spend the extra $1 or whatever to ensure its proper operation (as the majority of manufacturers admit later in form of appnotes), you will stop thinking in this way. Yes, Richard, they ARE lying. Are you really surprised? Of course not, but they're really not lying, except by omission. Their products do what they say they do. They just don't solve the problem they are credited (and I'm not sure by whom) with solving. Of course, you can work around this problem using a sophisticated power cycling controller (including essentially the same reference & comparator & timer combo as is in the reset IC, plus the required power components, just to prevent power out shorter than required to discharge the C of RC), and while I am not quite sure it will be satisfying during powerdown, I am absolutely sure it will by several orders of magnitude exceed the cost of $1 reset IC which you were protesting against initially... Well ... one COULD sinply use the reset IC to do what it does, then add the functions that solve the unsolved portions of the problem ... though that requires defining the problem first. ---
As for your experiment, can you please post a simplified schematics? It is not clear for me how did you combine the RC reset with the reset IC. Are you aware of the requirement that the teset IC has to "see" the SAME VCC as the mcu? Also, it is suspicious that the Dallas BRAM got corrupt as IIRC it has a builtin gate of CS during low VCC (I don't have access to the datasheets now to tell it for sure). Jan Yes, I found the BBRAM corruption mysterious, too. I think it simply points to the fact that little is known about what happens with MCU's, in reset or not, during the interval between legal Vcc and the low-voltage write lockout. Here's what they say ... Dallas Semiconductor said:
DATA RETENTION MODE
The DS1230AB provides full functional capability for VCC greater than 4.75 volts and write protects by 4.5 volts. The DS1230Y provides full functional capability for VCC greater than 4.5 volts and write protects by 4.25 volts. Data is maintained in the absence of VCC without any additional support circuitry. The nonvolatile static RAMs constantly monitor VCC. Should the supply voltage decay, the NV SRAMs automatically write protect themselves, all inputs become “don’t care,” and all outputs become highimpedance. As VCC falls below approximately 3.0 volts, a power switching circuit connects the lithium energy source to RAM to retain data. During power-up, when VCC rises above approximately 3.0 volts the power switching circuit connects external VCC to RAM and disconnects the lithium energy source. Normal RAM operation can resume after VCC exceeds 4.75 volts for the DS1230AB and 4.5 volts for the DS1230Y. I'm using the DS1230Y. As for the circuitry that would "finish the job" IMHO, little more than a connection of the negative going RESET from a MAX1232 to the X1 input of of the oscillator would be required to cover the brownout condition. This would have to be AC-coupled (differentiated) so that it stops the oscillator when RESET is asserted, but allows it to restart. That certainly would prevent the MCU from p*ssing on BBRAM, external FLASH, or internal FLASH, or from doing anything else, during a RESET cycle. I don't think a FET, an R, and C would cause too much cost increase. I'll have to look into that, as I seldom use the on-chip oscillator, preferring to use an external oscillator. I've concluded, preliminarily, that stopping the oscillator is the easiest way to ensure that nothing evil occurs during a power-down, yet it impacts the system much less than disconnecting power and/or pulling down Vcc at the beginning of each RESET cycle. I take exception to your characterization of the RC reset as "crappy, as it worked on tens of millions of applications before the current trend, brought on by the shift to CMOS, to use underpowered power supplies and on-chip FLASH memory. The RC reset worked just fine before that. What's crappy is the system design. If the PSU doesn't put Vcc up to where it should be within a VERY short time, but allow it to decay in a VERY short time, then it's not properly designed. Have you ever tried out a system that meets that 1 ms rise time? How about the 10 ms rise time? Have you ever tried it on a board supplied from a truly HEFTY (over 30 amperes with less than 10 mV ripple at full load) power supply? If you do, you may encounter some things you've not seen before. I'll have to find and scan the schematic. I put it on a daughterboard, the schematic of which was hand-drawn. I suspect you'll be disappointed, as it's quite simple, and as it was mainly intended to provide a RESET compatible with the bidirectional RESET of the DS89C4x0's, which, BTW, the RC reset is, while no supervisor I've encountered has open-drain or tristate output. RE |
