How to save data when µC power is down?

[david77]

Hi guys.

I'm currently designing a real-time counter for an old reel to reel tape recorder.

Now I'd like to save the counter when the recorder is turned off. I'm not sure what the best way to do that is.

My first idea was to keep the µC powered by a 3,6V lithium battery or a NiMH battery so that the contoller
doesn't loose his memory at all.
The second idea was to somehow detect the power-down and make the controller save the counter into
the EEPROM. I'd have to supply the controller with power for a few seconds after power-down, maybe with a
Goldcap.

What do the experts think would be the way to go?

The controller I'm going to use is the ATMega32 as I need loads of I/O for a 4x4 keyboard matrix and
some other signals from the recorders logic circuit that I have to monitor. There's also a LCD connected
to the µC.
In the end I don't only want a counter, I want an autolocator - so I need the keyboard for data input.
I haven't yet built or coded anything, at the moment all I have is in my head and some preliminary circuit
diagrams.

Cheers, David.

[Zad]

I would go with the EEPROM method. If the micro doesn't already have a brownout detector then they are cheap enough to buy or build. Given the low power needs of modern micros and speed at which they work, I would imagine the existing power filtering caps would provide enough charge to perform an EE write.

[frank26080115]

Did you know the DS1307 RTC chip is also a battery backed non-volatile RAM? Maybe that's one option.

[williefleete]

stick in a routine which writes to a 8 pin eeprom regularly if its not to involved or use a battery backed SRAM

[david77]

Thanks guys.

What would be the benefit of using an external EEPROM? I don't have to store much data, only a couple of bytes.

Cheers

[Psi]

you'd need a diode feeding the mcu and capacitor. So the capacitor voltage couldnt discharge back into the supply.
You could then detect the voltage on the supply side of the diode to tell you if the power is failing and you'd have a little time to save the data.

You'd need to code it so it could work even if the data it reads from eeprom is corrupt, as that might happen.

One way to get around the corruption problem could be to use the entire eeprom space. Eg, you could save an indexID and the data into the first 1-4 bytes and then the next save would be bytes 5-8, then 9-12 etc. then wrap around and start at 1-4 when you fill it up. This way you can just scan the eeprom for the highest indexID with valid data at startup.

Or you could use an external eeprom with heaps of storage and forget saving on shutdown. Instead keep saving data every 60sec or so while the device is running.  eeproms have a lifetime of something like 100,000 writes, so if the eeprom was big enough you could save very often and it would take ages to reach 100,000 on all bytes.

You'd have to check how long it would take to read the entire eeprom though, if the eeprom was too big it might add a noticeable startup delay.

Does anyone know if eeprom writes are done per byte or if it has to erase the whole section like flash?
Im assuming its per byte

[scrat]

I've recently interested in EEPROMs, and the ones I saw (I assume this is the rule, however) require a huge time to make a write (in the order of ms), since they physically write an entire page at a time, refreshing the bytes the user has not written to.

[david77]

I've got a problem now that I don't quite understand.

The way I decided to go is to use a Goldcap to keep the AVR powered for 1-2 secs while detecting the power down using an
interrupt (INT0). Standard configuration Vcc -> x -> diode -> Goldcap -> AVR. INT0 is connected to point "x".
It does work, but there's a problem: If power fails and comes back on after a short time (up to about 30 sec) the AVR seems to seize up, it only outputs garbage on the display and stops working. Only after a longer power failure it comes back on properly.
I reckon it's got something to do with the power stored in the Goldcap, if that's at some weird level when power comes back on the AVR doesn't reset properly.
As I understand the datasheet if you connect Pin 9 RESET of the ATmega32 to Vcc it is forced to do a reset at power up. Maybe the voltage doesn't drop far enough for that to work properly?

Here's the schematic (drawn in my own version of DaveCAD ):http://dplinks.ath.cx/pics/elektro/AL12_SchaltplanV1.pdf

And another question regarding the actual code.
When INT0 is triggered the AVR jumps to the appropriate ISR where it writes data into the eeprom. Then the return command is issued.
As I expect that nothing else happens now after power is going down what would be the best command to issue after the data is written to eeprom? Do I just let it return to the main prog? Do I stop the AVR? What do you guys think?

I hope I could make myself clear 

Cheers, David

[Psi]

With a small 5.5V 1 Farad super cap it would take 10seconds to discharge from 5V to 4V under a 100mA load

Plenty of time.

[david77]

Exactly that is the problem. I need a way to reliably reset the AVR when power comes back on.
At the moment the controller locks up if the Goldcap is not discharged far enough when power comes back on.

[Psi]

sorry, i was reading other posts and never got down to reading yours.

To fix your problem you just have to enable the mcu's brownout detector. That's what its for  
The ATMega32 has two possible brownout settings 2.7V or 4V. If you set the brownout detector to 4V and enable it the mcu will automatically go into reset state when the voltage falls below 4V. You shouldn't get any low voltage crash issues with the brownout detector enabled.
(You will need to program fuse bits to enable the brownout detector, be sure you get the right bits or you might accidentally lock the chip)

And another question regarding the actual code.
When INT0 is triggered the AVR jumps to the appropriate ISR where it writes data into the eeprom. Then the return command is issued.
As I expect that nothing else happens now after power is going down what would be the best command to issue after the data is written to eeprom? Do I just let it return to the main prog? Do I stop the AVR? What do you guys think?

I'd put the mcu into a never ending loop after writing the eeprom.
You want it to be doing nothing important when the brownout detector puts it into reset state.

As I understand the datasheet if you connect Pin 9 RESET of the ATmega32 to Vcc it is forced to do a reset at power up. Maybe the voltage doesn't drop far enough for that to work properly?

na, RESET is negative logic, you connect it to GND to make the chip reset, it has an internal pullup that pulls it to vcc (run state) if you leave the pin floating.

[david77]

Thank you Psi.

I don't know where I read about the Reset connected to Vcc - it was late I must have imageined things 

I have BOD enabled, though I'm not sure if I set it to 2,7 or 4V. I'll have to recheck that again, might be set to 2,7V wich obviously isn't any good.

[Zero999]

With a small 5.5V 1 Farad super cap it would take 10seconds to discharge from 5V to 4V under a 100mA load

Beware, some memory retention capacitors have a very high ESR. The datasheet linked below shows some 1F 5.5F capacitors that have an ESR of up to 30R which at 100mA is a 3V drop before it even starts discharging.
http://docs-europe.electrocomponents.com/webdocs/0027/0900766b800274ce.pdf

[Trigger]

Don't forget that you have the WDT too.

One thing you should do is a CRC check of the data you wrote to the EEPROM to make sure it matches what's in memory.  It'll save you some headaches down the line.

If you're using one of the picopower AVRs you can sleep it and retain the RAM with a backup battery.  One of those with a battery could last for years.  Cymbet has their enerchips as well which will control power and provide a battery backup.  Their chips are not prototyping friendly but they have an evaluation kit with a 24 pin DIP module that would be easy enough to put into a design.

[tecman]

stick in a routine which writes to a 8 pin eeprom regularly if its not to involved or use a battery backed SRAM

Be very careful with this.  You can be bitten easily by exceeding the lifetime R/W cycles.  Option is to do it less frequently, but then you lose data on power down.

paul

[bilko]

It would be kind of neat if you could record the counter value onto the tape at the same time as you are recording the audio track(s).
The pro equipment uses SMPTE, google it if you need to know more.
The system would then read the code as it is playing the tape so it would always be synchronised
Which tape machine are you using ?