??? 08/13/07 00:38 Read: times |
#143134 - it's a thorny problem Responding to: ???'s previous message |
Kai Klaas said:
Richard said:
I am curious, however, why it appears that with slow decay on Vcc, 805x's (and I'm not for a moment suggesting it couldn't happen with absolutely any MCU) the content of external BBRAM frequently seems to become corrupted. This suggests that the MCU is doing something despite the fact that RESET is asserted, as I've seen this in cases where a MAX1232 was installed, as I previously stated. Yes, I understand what you mean and such frequent BBRAM content corruptions would heavily alarm me too! Some hints: 1. Is tPD, tF, tR, tPU and tREC of DS1230Y fullfilled in your application? Well, Tpd is a parameter telling us how long it takes the NVRAM to figure out that Vcc is out of specified limits and therefore disable writes. Tr, the rise time of Vcc is pretty quick, 0v-5v in about 450 microseconds. That would suggest my board still raises Vcc too slowly to meet the write-protect threshold. However, RESET falling is not even started, in this case until well after Vcc is valid and the oscillator is started. Before the oscillator starts, I'm not worried. Tpu is another information specification indicating the BBRAM behavior, so I can't really fix it. It does suggest that one must have a RESET pulse width after Vcc is stabile and the oscillator is running, of at least 2 ms to ensure no spurious writes occur. Likewise Trec simply indicates that it takes at most 125 ms of valid Vcc before one can rely on the BBRAM to protect itself against brownout. 2. Also, is tF of MAX1232 fullfilled? That's easily met, since the decay time, and, in fact, the time between when RESET occurs and when the oscillator stops is over 3 seconds. I rather wish it were on the order of 10 usecs. 3. As the write protect of DS1230Y becomes invoked, when Vcc falls under 4.25V I would heavily recommend to choose a trip point of 4.62V at MAX1232, which I do in all of my applications. Don't choose 4.37V! If the DS1230Y stops write commands, before the micro becomes reseted, then, of course, you will find BBRAM content "corruptions", or concretely spoken missing write activities. I took that into consideration. If you are not sure, whether the micro does something wrong with your BBRAM after the MAX1232 outputs a reset signal when Vcc is decaying, you could monitor the !WR or ALE/!Prog line and hunt for unallowed pulses. An edge triggered scope could do this job quite well. Then, after the total decay of Vcc, you could check the BBRAM content and, if a corruption occured without forbidden !WR pulses, then the BBRAM is faulty, but not the micro. I didn't check ALE, since I only use it for the address latches, but there is sufficient noise on nWR to trigger my 'scope in single-sweep mode. I believe the circuit would behave differently if I replaced all the CMOS logic with LSTTL, as it's a mite fussier about low Vcc. Kai RE |