Power failure adviser for MCU

[daryldee]

Hi!

I'm designing a device based on an atmel xmega MCU.
This device have 3 power rails, for relative other peripherals.

The 3.3v power rail goes to the MCU and since the device have many settings, I want to save it in EEPROM just before power down (minumum MCU operating voltage 1.6v).
To do this I assume I need to design a power backup circuit that can store enough energy to keep the MCU alive for enough time to allow the NVM EEPROM page write trigger.

What I don't know to do is to design the power failure circuit.
What is clear to me is that an ISR call should be triggered on signal loss/fall, sure, from the non backed up part of the circuit, what I don't know exactly to do is how to divide the power domain.

The MCU at its maximum power consumption is about 20mA without any current draw on pins.
An EEPROM page write is 8ms.

I did this with SPICE, but I'm not sure the concept is correct, I don't know how to correctly simulate an MCU load, i tried with the Ohm law to calculate a Load based on datasheet and it came out for 0.2A (absolute maximum rating of Vcc current pin: 200mA) a resistance of 16.8 ohm.
The problem on this calculation is the hypothetical capacitor, that is not discharging, so I put in serie a 1K resistor. It works but after it I hot very low voltage (VL-MCU on plot).

This is my first SPICE simulation ever.

What would you do? What am I missing?
Thanks,
D.

[uncle_bob]

Hi

One simple answer is: do not do this. Write to eeprom every so often and use that information instead.

A more complex answer:

Isolate the external supply from the MCU with a diode. Run the MCU off of a super capacitor. Trigger the shutdown when the external supply gets to (say) 3.0V.

Some math:

Capacitor Q = CV
Diode drop = 0.5 V with a good diode

So, trigger at 3.0 in = trigger at 2.5V on the capacitor.

If the MCU is 100% guaranteed to do a valid write at 1.67V on the data sheet, you have 0.83 volts "extra" on the cap at trigger.

If the MCU pulls 10 ma, it uses 0.01 coulumbs a second.

If your super capacitor is a 1F part, a 0.83 V drop will "give" you 0.83 coulumbs.

The MCU will run for roughly 83 seconds after the trigger, running only on the super capacitor. That is how long you have to get the data into eeprom.

Bob

[Kjelt]

Supercap is Way overkill and can ruin your startup power curve unless that cap is also isolated with a diode. Simple solution is indeed isolate the power to the mcu completely, detection of powerfail, set everything un needed in the mcu off and write your data. One second should be more then enough which can be achieved by just using a couple of cheap 4.7uF or 10uF smd caps on your mcu supply.
Now simulation is great but never tells the 100% thruth so I always just built the circuit and measure. Adding capacitors as needed for the time needed. Built in a decent margin so twice the time needed, as time and temperature might have negativeveffects on the long run.

[uncle_bob]

Supercap is Way overkill and can ruin your startup power curve unless that cap is also isolated with a diode. Simple solution is indeed isolate the power to the mcu completely, detection of powerfail, set everything un needed in the mcu off and write your data. One second should be more then enough which can be achieved by just using a couple of cheap 4.7uF or 10uF smd caps on your mcu supply.
Now simulation is great but never tells the 100% thruth so I always just built the circuit and measure. Adding capacitors as needed for the time needed. Built in a decent margin so twice the time needed, as time and temperature might have negativeveffects on the long run.

Hi

Fully isolating the MCU may not be as easy as it sounds. A single line pulling "high" going off to a powered down section of the board can be a 20 ma load on your "isolated" supply. If you have a dozen or two lines running here and there, that's a lot to keep track of and supervise.

Even at 1 ma, a 10 uf cap on the 3.3V supply rail is going to keep the MCU up for *maybe* 10 ms. That's not a lot of time to get things done ....

Bob

[wraper]

I'd say, at power loss, instantly set all ports as inputs, set clock divider to reduce current consumption, then write to the eeprom. Certainly use Brown out detection to prevent EEPROM corruption. Also ensure that firmware verifies eeprom content integrity and operates properly if it turns out to be corrupted.

[uncle_bob]

Hi

One very real thing in most areas:

The power dips. Is it a power failure or is the power coming back real soon now?

If this is running on a non-rechargable battery all the time, that may not be a big deal. If it runs off of a normal power main, it can be an issue.

Next up is: I got a blip, the power came back, what do I do now? Generally the answer is wait a bit and see what happens. That may or may not work in this case. Exactly how you handle these things is highly application dependent. We don't know much about the application.

Bob

[Rerouter]

I agree with another poster saying make the first thing your interrupt does is switch off all unneeded peripherals, next up write a byte or so at a time, verifying each, (using duplicated bytes in your eeprom may prevents the risk of a brownout mid write) And finally, do a check of your power flag, if the main supply is still not available, force yourself off, otherwise jump to your setup that re-enables all your peripherals,

I'm using a sam3x8e in a similar case, but i have a backup battery, so for this stuff, when i loose main supply i drop everything but the required peripherals and do some house keeping before going to sleep,

[Ian.M]

If possible, monitor the input voltage to the regulator feeding the MCU, before an isolation diode isolating the supply source from the regulator's reservoir cap for the earliest possible warning of impending power failure.  You can generally tolerate a much greater drop upstream of the regulator before browning out the MCU, so extra bulk capacitance in front of the regulator is far more effective.   This may be problematic if other devices are powered from the same regulator, and you then have decide if its worth adding PMOS load switches to let the MCU shed high-drain loads.

[daryldee]

Hi guys, very good ideas here, thank you all!

Ok, I will shed light on the situation, w/ info expansion (:

The MCU is an xmega32e5 running at 32MHz (internal RC), it has only two power connections (4 pins), AVCC, VCC and relative GND's.
My idea of firmware behavior in this task is to set the IRQ vector on a specified pin on low lever priority (in xmega is the 1st to be executed, I guess is the same in others) and connect it to the initial non isolated stage of the power domain.
Then at power failure this will trigger the ISR that will proceed with a fast shutdown on all the  peripherals (optionally), reset a rtc value and write data to EEPROM.
I did not thought about setting all pins as input, thanks!

About this aspect I should really do just test and calculations because maybe going into a shutdown sequence will not save such enough time in respect of the time gained, I mean, if I employ 5ms to shut down things to save 5ms, well...
What is really necessary, in respect to what uncle_bob said about power dips,there will be a time checking routine, I can't risk to write thousand times in EEPROM in case of an oscillating DC if power supply failure.
For info: no battery power supply, only regulated external DC PWS. In theory shut down is controlled.
Saving settings every now and then will not be a good idea since the nature of the device, better don't put the feature then getting a complain from a potential customer saying that nothing is saved on the right config stage.

EEPROM data consistency, writing speed and BOD:
writing speed - I was thinking to use the Split Write method instead of Atomic Write, writing speed is the half.
consistency -  I may use a CRC8, but I'm worried this will be a longer process in respect to a simple page write.
BOD - In xmega a brown out detection will force the MPU reset, I may set it at for instance 2v. But why? This will not save memory corruption if reset is forced during a write cycle, or yes?

To Ian: I have only two devices running on 3.3v rail: MCU and OLED display, but I may shift the OLED display on 5v rail and change the LDO with a slightly "bigger" one.

Additional problem: I cannot use a super cap, this is big, the board is compressed in 5cm diameter circle.

Uncle_bob said that isolating a power domain maybe not easy as it seems, my solution of the simple diode and a "big" cap was all that it came into my mind.
By a mere electrical point of view, what would you suggest peeps?

PS. For luck EEPROM write is not very intense, it's a bunch of bytes

[Rerouter]

Refering to page 4 of the datasheet,

"To further reduce power consumption, the peripheral clock to each individual peripheral can optionally be stopped in active mode and idle sleep mode and low power mode of the internal 8MHz oscillator can be enabled."

Equally for your chip running at 32MHz, your burning about 8mA + 4mA for the eeprom peripheral,

It takes 4ms to program 32 bytes of eeprom space, (on an 8MHz oscillator),

so 12mA for lets say 80ms to make sure you can do what you want, so for that you would need a 470uF capacitor,

If you where running at 8Mhz, it would be a load of 6.5mA total, and could do with a 220uF capacitor,

[wraper]

BOD - In xmega a brown out detection will force the MPU reset, I may set it at for instance 2v. But why? This will not save memory corruption if reset is forced during a write cycle, or yes?

If writing eeprom at low voltage, there is a high risk of corrupting EEPROM contents, and not only what you are writing at particular moment but any of it's contents. Be sure to check the datasheet if BOD level is not lower than minimum voltage at which you are allowed to write to the EEPROM. On reset, current write cycle in AVR will be still completed.
About EEPROM verification, I mean on the next power on to be clear.

[uncle_bob]

BOD - In xmega a brown out detection will force the MPU reset, I may set it at for instance 2v. But why? This will not save memory corruption if reset is forced during a write cycle, or yes?

If writing eeprom at low voltage, there is a high risk of corrupting EEPROM contents, and not only what you are writing at particular moment but any of it's contents. Be sure to check the datasheet if BOD level is not lower than minimum voltage at which you are allowed to write to the EEPROM. On reset, current write cycle in AVR will be still completed.
About EEPROM verification, I mean on the next power on to be clear.

Hi

YES !!

You must write the EEPROM *before* you get into a low voltage situation. Using the standard brown out detect stuff simply does not give you enough notice of what is happening. To have a robust product, you need to have margin between the point it is *sure* to complete and the point that the data sheet advises you not to do any writes. You also need to have margin on the trigger point since it is not an exact voltage, but something that has a tolerance on it. As you shut down your clocks and peripherals, they will still be pulling power until you get to them. That all occurs after you get to the trip point and before you can do any writing. If you have one of the "20 ma here or there" sort of issues, you can run a lot off your cap before you get around to doing shutdown.

Back to the recommendation at the top of all this:

You are better off doing an occasional write to the eeprom to save changes than doing a panic dump at power down. So far (in 40 years of doing this) I have never seen a situation where this could not be made to work. The main exception is saving something like a run time clock. In that case our solution is to simply accept a more granular run time number and do the "occasional write".

Some math:

A good eeprom these days will run fine for over a million writes to a given section of memory. You can do better than that at an added cost. A write every second will get you to a million writes in about 12 days. If you spread the writes over 365 blocks of memory, that goes to 12 years. Double it and you are at 24 years. If it's a "not a lot of bytes" sort of thing, you probably have spent <15 cents to do it. That's less money than the great big cap will cost you ....

Bob

[matseng]

Do you actually need the eeprom for anything else than those few bytes you're storing at power failure? If not maybe an alterate solution could be to use a battery backed ram instead. Like many RTC chips got 16 bytes of backed ram in addition to the RTC circuity.

[daryldee]

Ok, I see, I really need to take care on EEPROM data safe write and Cap seleciton.

Some math:

A good eeprom these days will run fine for over a million writes to a given section of memory. You can do better than that at an added cost. A write every second will get you to a million writes in about 12 days. If you spread the writes over 365 blocks of memory, that goes to 12 years. Double it and you are at 24 years. If it's a "not a lot of bytes" sort of thing, you probably have spent <15 cents to do it. That's less money than the great big cap will cost you ....

Bob

Interesting Bob, thanks.

Doubt:
If the best thing would be spreading data in mem blocks, I should also implement an indexing algorithm... am I wrong?
When I shift data on a new mem block, I also need to tell the MCU where to locate the data chunk begin.
To make this concept work error free I should be 100% sure (again) being error free otherwise data corruption will be devastating; or, indexing should be complex enough that cannot be misunderstood by the code, but I cannot simply clean the rest of the memory otherwise it will be all vain.

I will try also this solution, it is very educational. Unluckily the xmega32e5 has only 1KB EEPROM, it's sorted as 16 pages of 64 bytes blocks.
I need to calc exactly the data amount saved so I can calculate a bit how long I can implement this concept, I hope I will have enough room for this.

[daryldee]

Do you actually need the eeprom for anything else than those few bytes you're storing at power failure? If not maybe an alterate solution could be to use a battery backed ram instead. Like many RTC chips got 16 bytes of backed ram in addition to the RTC circuity.

Hmmm, this sounds more expensive than the other solution proposed.
What type of hardware are you talking about for example? The problem of implying batteries is that the board is only about 5 cm diameter and round, I don't have enough room to fit big components...

[wraper]

Batteries? Now way, read the forum how people get screwed because of them. If going for additional expenses, just use FRAM IC. Personally would never use them unless I need RTC.

[uncle_bob]

Ok, I see, I really need to take care on EEPROM data safe write and Cap seleciton.

Some math:

A good eeprom these days will run fine for over a million writes to a given section of memory. You can do better than that at an added cost. A write every second will get you to a million writes in about 12 days. If you spread the writes over 365 blocks of memory, that goes to 12 years. Double it and you are at 24 years. If it's a "not a lot of bytes" sort of thing, you probably have spent <15 cents to do it. That's less money than the great big cap will cost you ....

Bob

Interesting Bob, thanks.

Doubt:
If the best thing would be spreading data in mem blocks, I should also implement an indexing algorithm... am I wrong?
When I shift data on a new mem block, I also need to tell the MCU where to locate the data chunk begin.
To make this concept work error free I should be 100% sure (again) being error free otherwise data corruption will be devastating; or, indexing should be complex enough that cannot be misunderstood by the code, but I cannot simply clean the rest of the memory otherwise it will be all vain.

I will try also this solution, it is very educational. Unluckily the xmega32e5 has only 1KB EEPROM, it's sorted as 16 pages of 64 bytes blocks.
I need to calc exactly the data amount saved so I can calculate a bit how long I can implement this concept, I hope I will have enough room for this.

Hi

Indexing:

With four bytes you get 4 billion indexes. With eight bytes you get the same indexes and effectively 100% certainty they are correct. That's enough to write once a second for over a century without roll over. You simply look for the highest index in the set and use it. For added fun, you can look at the other indexes and see if they all are in order (they should be).

Yes, that's only one of a few zillion ways to do it.

There is also the very basic check to see if anything has changed since the last block was written. If there is no new data, no need to write a new block.

Lots of fun !!

Bob

[Jeroen3]

since the device have many settings, I want to save it in EEPROM

Settings are generally only changed by people, and not very often. What are you saving? And why does it need to be saved at the worst possible time?
I feel an xy-problem.

[daryldee]

Batteries? Now way, read the forum how people get screwed because of them. If going for additional expenses, just use FRAM IC. Personally would never use them unless I need RTC.

FRAM! I love those! Anyway no, I'm not a fan of batteries either.

Lots of fun !!

Bob

It will be! Thanks Bob.

since the device have many settings, I want to save it in EEPROM

Settings are generally only changed by people, and not very often. What are you saving? And why does it need to be saved at the worst possible time?
I feel an xy-problem.

Sure, changes in settings are made by people, but this device will be used in specific environments that requires config backup almost in real time (broadcast / architectural lighting, it interacts with DMX RDM consoles).
Everything has been already made and tested by the mere personalities EEPROM save and only at those changes, what I want to implement is a single global call save that saves the status of the various periferials, loosing power and getting a scene set purple instead of yellow, for instance, it is not nice... better having no save!
This device really has delicate equilibrium in terms of operation priorities, the firmware is quite complex, I'm using all the modules available in the datasheet, I recently just dropped EDMA but all the rest is alive and running.

[Kjelt]

Batteries? Now way, read the forum how people get screwed because of them. If going for additional expenses, just use FRAM IC. Personally would never use them unless I need RTC.

IIRC Fram also writes when read, what happens if power fails during a read? You just bulldozer the problem from the eeprom to the fram IMO unless the fram has protection against such failures.

[wraper]

Batteries? Now way, read the forum how people get screwed because of them. If going for additional expenses, just use FRAM IC. Personally would never use them unless I need RTC.

IIRC Fram also writes when read, what happens if power fails during a read? You just bulldozer the problem from the eeprom to the fram IMO unless the fram has protection against such failures.

First of all, FRAM ICs have protection against this. Secondly, you can just write FRAM say every second all of the time (expect 10¹²+ write/read cycles endurance specified) or every time settings are changed and do not care about writing data when power lost. Thirdly FRAM writes instantly, you don't need precious milliseconds to write it if still insist to write on power loss. Fourthly, use brown out on MCU to insure that no read/write happen at low voltage happens to be safe.

[uncle_bob]

Sure, changes in settings are made by people, but this device will be used in specific environments that requires config backup almost in real time (broadcast / architectural lighting, it interacts with DMX RDM consoles).
Everything has been already made and tested by the mere personalities EEPROM save and only at those changes, what I want to implement is a single global call save that saves the status of the various periferials, loosing power and getting a scene set purple instead of yellow, for instance, it is not nice... better having no save!
This device really has delicate equilibrium in terms of operation priorities, the firmware is quite complex, I'm using all the modules available in the datasheet, I recently just dropped EDMA but all the rest is alive and running.

Hi

If everything changes infinitely quickly, while the power is out, the device will have missed commands. Thus it will be "out of sync" and in an objectionable condition. The only answer to that one is storage at a higher level and instant refresh of all devices all the time.

If things rarely change (compared to infinitely often) then store things each time they change. Do the math and size the memory so it will last long enough. Long enough might be 2 years, it might be 20 years.

Yes, I have done designs where there is a dedicated processor just to handle something this on a non-blocking basis. It would be easier to do today. Chip scale package parts are small and cheap.

Bob

[nctnico]

Batteries? Now way, read the forum how people get screwed because of them. If going for additional expenses, just use FRAM IC. Personally would never use them unless I need RTC.

I second the suggestion for going for FRAM and write that during normal operation. Writing records to the FRAM in a round robin style using incrementing sequential numbers and a CRC check safeguards against losing data during a write and performs wear levelling. At startup scan the FRAM for the newest record and start from there with writing data.

The second best way is to use a rechargable battery which can keep the power going for a while. In my experience Atmel devices crap out before you reach the lowest advertised voltage so a solution with capacitors needs to have a lot of room for the capacitor degrading over time.

[wraper]

and performs wear levelling

Wear leveling is completely unnecessary for FRAM. Even if you will read/write the same address every millisecond, it will take 300 years to wear out this IC http://uk.farnell.com/fujitsu/mb85rc04vpnf-g-jne1/fram-4kbit-i2c-sop-8/dp/2429024, or 30 000 years to wear out this one http://uk.farnell.com/cypress-semiconductor/fm24cl16b-g/fram-16k-i2c-8soic/dp/2077749.

[Kjelt]

First of all, FRAM ICs have protection against this.

Please elaborate since the datasheet you yourself quote in some post above clearly states:

Note that the FM24CL16B contains no power management
circuits other than a simple internal power-on reset. It is the
user’s responsibility to ensure that VDD is within data sheet
tolerances to prevent incorrect operation.

That in combination with a serial I2C protocol can be desastrous on an unexpected power outage if you do not monitor it and have some extra time to shut down properly, thus coming back to the original issue. I do not see a big difference. I rather have an externa spi flash than an I2C external fram for that matter, as long as the nr of write cycles is not the issue that is.

Secondly, you can just write FRAM say every second all of the time (expect 10¹²+ write/read cycles endurance specified) or every time settings are changed and do not care about writing data when power lost.

True, but broken records should be taken into account. If you update the administration (fat) after verification of the data written it would be ok

Thirdly FRAM writes instantly, you don't need precious milliseconds to write it if still insist to write on power loss.

I call the I2C hardly instantly, you first have to adress the chip then write the datablocks, go count on 100kHz bus and a coming powerfailure, you also have to buffer the chips.

Fourthly, use brown out on MCU to insure that no read/write happen at low voltage happens to be safe.

that is too late, you need a pre-warning. I still would isolate the mcu in this case and use some buffer capacitors, if the costs is an issue then so is the price of the fram.
One of our requirements for external storage was to hold two firmwares of 256kB, good luck with fram on that requirement .