Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
03/16/08 16:08
Read: times


 
#152299 - Nothing complicated ...
Responding to: ???'s previous message
Michael Karas said:
Please explain how you know that corruption has not happened. You mention a checksum process; is that a robust CRC-32 or a modulo 256 sum of bytes?

Michael Karas


It's a pretty simple, and preliminary test. I just use a mod 256 checksum, but the fact that the code survives is already a favorable indicator. All I'm looking for at this juncture is a single instance of BBRAM corruption.

In the previous instance in which I had frequent BBRAM corruption, I had a rise time of nearly one second on Vcc, and a fall time that I couldn't measure. If it hadn't happened with very high probability, I would not have been able to observe it happening during true RESET from the DS1232 supervisor. I also would not have been able to observe that it happened with the old Intel parts, as well as AMD, Signetics, Philips, and Dallas parts.

What I believe I'll do is to increase the capacitance on Vcc by a couple of orders of magnitude, by adding a couple of thousand microfarads of capacitance to the Vcc plane, and then simply disable the discharge of Vcc. Waiting for Vcc to reach < 0.7 volts, and concurrently watching nPSEN, nWR, and nRD for any activity during the active RESET, should give me some information. Additionally, the simple checksum should be adequate to tell me that the BBRAM content hasn't changed. I do have to allow for the possibility that the corruption is attributable to some factor other than a runaway MCU.

In any case, I intend to control the decay of Vcc by the choice of the resistor through which Vcc is discharged, and, later on, I'll use the rise time of Vcc as a test parameter as well.

The time I have to fuss with this is bit limited right now. I do have to perform useful work from time to time, after all, just to keep the wolf from the door. Also, I have, as I've often done, I've allowed my usual overly-generous nature to promise more than I can reasonably fit into a day. ... <sigh> ... You'd thing I'd have learned not to do that by now ...

The reason I've chosen this approach is because I'm persuaded that the "reset problem" people have repeatedly encountered is because of excessive capacitance on Vcc, which has seldom been discussed, and not because of a desperate need for additional circuitry. I don't doubt that a voltage monitor/supervisor could be very helpful, but I do have doubts about the currently available types, which simply assert RESET. I'm still thinking it's necessary to shut off Vcc to the MCU immediately each time RESET is asserted, or, at least, to stop the oscillator. The current set of tests are easy to set up and not difficult to monitor automatically. They also don't require a lot of equipment, though they do take a long time.

RE







List of 15 messages in thread
TopicAuthorDate
power on reset circuit            01/01/70 00:00      
   Save some trouble for yourself...            01/01/70 00:00      
   The Vcc supply is an important factor            01/01/70 00:00      
      experiment            01/01/70 00:00      
         all it's shown so far ...            01/01/70 00:00      
            Please do further explain...            01/01/70 00:00      
               Nothing complicated ...            01/01/70 00:00      
   There is, but...            01/01/70 00:00      
      it sounds atmel thinks it's ok            01/01/70 00:00      
         No, they don't            01/01/70 00:00      
   Aren't you frightened?            01/01/70 00:00      
      The "toy" rule just changed ...            01/01/70 00:00      
   same situation            01/01/70 00:00      
      See the Atmel doc, then            01/01/70 00:00      
         I'd guess this depends on oscillator startup            01/01/70 00:00      

Back to Subject List