EEPROM write/power loss/startup/reset etc

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Too many design options, the cat understands electronics slightly more than the wife, so time to turn to the forum :P

I need to write 10 bytes to eeprom on power loss (user turns equipment off, rather than unexpected internal fault), so I need to detect power loss and have enough time/power to write the eeprom. I also want rock solid and clean startup and shutdown of the processor. I'm happy with the software side of it all...

...but I've two circuit options so far - A and B at http://www.milleners.eclipse.co....

INT0 would be a triggered on low level, and the ISR would write the EEPROM and the go into an infinite loop.

To save typing, I'll not explain the circuits - if you can understand them, then you're comments will be most appreciated 8)

The significant components in the rest of the circuit are a MAX232, a MAX7219 multiplexing 8x7-segment LEDs and a remote ATMegaXXXX mutiplexing 4x7segment LEDs using discrete transistors rather than another MAX7219

So a reasonable current draw...

On A (zener is 4V8 or 5V1, BTW), I could send the MAX7219 into shutdown mode pretty quickly within the ISR to stop it (and the LEDs) drawing too much current and give me more time but I can't do that for the remote ATMega and its LEDs

On B, the supply voltage at Vcc and the MC34064 is estimated at 4.8V. Will this be OK or is it too low?

Either circuit - use BODEN as well as MC34064? Or ditch MC34064 on both and just use BODEN

Is there a circuit C hiding somewhere?

Thanks in advance
Martin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A couple of comments--

-- Do you really want to shut down based solely on the INT0 edge--any little glitch cause the shutdown sequence? It is quite annoying to have false restarts.

Quote:

INT0 would be a triggered on low level, and the ISR would write the EEPROM and the go into an infinite loop.

Quote:

I also want rock solid and clean startup and shutdown of the processor.

-- Here is what I've found in my similar apps. As you described it, a power glitch would cause the save and a loop-forever. Hmmm--if power never goes away, you'll never reset & your app is hung. Here is the way that I have found that works best for me:

1) Detect the power loss. I usually do A/d on the "raw" side of the regulator, or have a device that monitors the "raw" side. That gives the most reaction time, but can't be too sensitive.
2) Shut down power-suckers, as you have mentioned.
3) Save needed stuff. ** more on this below
4) Go into a wait loop, continuing to monitor power. (As you can infer, I don't hang around in the ISR or such--rather, set a "power bad" flag and let the "routine" in the mainline take care of it.) In this wait loop, I do a WDR to stay there as long as power is bad. If the power returns, then I stop doing the WDR, and let the watchdog give me a reset. If the power goes away completely, the AVR dies and a power-on reset does the restart. So I'm covered if a long-term brown-out, returning power, or loss of power.

** the "more on this below" section: Be sure your EEPROM writing routines do a read first and don't do the re-write if the contents are the same. Example: a 32-bit cycle counter. Chances are, the top 8 or 16 or 24 bits haven't changed. If only 2 bytes need to be written, then 16 ms. are saved in the race at power-down.

As an add-on to that, using my 32-bit cycle counter: in the app code, I check for mod 256 (say) and write it out periodically during normal run time, so it is "about" up-to-date. (In some apps, I keep a "shadow" counter of this value, to help detect if the save during the power-down race gave nonsense results.) This gives me "pretty good" or at least "consistent" information snapshot if the reset occurs from other means--watchdog, external reset, etc.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice thoughts Lee - many thanks for taking the time to type them all in!

I can't do A/D on the "raw" side as the 8515 has no A/D :(

So I guess I could just put the monitor voltage into an input port and poll it in the main loop for logic zero to indicate a drop out and have the following pseudo code?

mainloop:

...all existing mainloop code

   IF monitor IS low THEN
      Shutdown power suckers
      Save stuff
      Start WD Timer
      WHILE monitor IS low
         Kick the WD
      END WHILE
   
      Stop WD Timer
      Restart power suckers
   END IF

GOTO mainloop

Potential problem is that if my mainloop takes 10ms to run and I get a power out at the top, then I might never get to the save code! What d'ya reckon?

Any preference on circuit A or B - monitoring raw side or monitoring supply side with dedicated supply to AVR - the latter should give me a (relative) lot of time to respond to power out condition? Maybe even several seconds?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not monitor the supply side with a resistor divider and the analog comparator built into the 8515?

Mike H.

EDIT: Also, you should use a LDO Reg so you should be good down to at least 5.5 V.