ATMega48 Power Consumption Report

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

We are doing our first "real" low-power app and chose the Mega48 based on our experience with the AVR line. [The other pick would be the TI MSP430 series, but we were under a time crunch and do not have very much experience with producing complete apps with that microcontroller.]

We were pleasantly surprised (given that the Mega48 series is brand-new) to find that the chip operates exactly as described in the datasheet, including the power consumption numbers and graphs. Full disclosure: we are targeting the PowerDown mode, and didn't do a lot of work with the other modes.

The app is normally DC powered through a regulator, and has many peripheral subsystems enabled. These include all three timers, UART, ADC, & several pin-change interrupts.

When the DC power goes away, we go to the power-down mode after shutting down all the subsystems except a couple of pin-change interrupts to service events that must be processed under battery power. The base "draw" in power-down is about 0.2uA @ ~3VDC direct from the battery with no regulator.

Of course, it takes careful attention to each component to assure no leakage when one is concerned with uA. But the analysis and testing proceeded in a straightforward manner.

We found one gotcha that required some rework. We were using a 3.6864MHz crystal as the primary clock source. We found that (just as the datasheet stated!) it takes quite some time for the crystal to be completely crystallizing when waking up from powerdown. The delay turned out to be too long to correctly service the needed events. So we switched to the internal [nominal 8MHz] oscillator, divide by 2, then tune OSCCAL to as close to 3.6864 as we can get, using a 32kHz crystal on TOSC1/TOSC2 as the fixed time base for calibration. 57600 baud UART communications seem to be working fine. (The internal oscillator has a much quicker startup from power-down.)

Summary: The Mega48 seems to be a fine candidate for battery-powered apps if the stated specs meet the design requirements.

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

Do you run the 32 KHz continuously? (All I can see is the CKSEL fuses, but maybe it's turned off in Power Down). So that must mean that you calibrate the baud rate after everything's stabilized.

How much power does it consume?

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

What do you do with the BOD ?

At least in the mega8, the BOD consumes about 15[uA]. The datasheet say that the BOD consumption is significant. However, it is known that not using the BOD is dangerous if you are using the EEPROM. Does your design have this dilema?

Regards,
Alejandro.
http://www.ocam.cl

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

mneary wrote:
Do you run the 32 KHz continuously? (All I can see is the CKSEL fuses, but maybe it's turned off in Power Down). So that must mean that you calibrate the baud rate after everything's stabilized.

How much power does it consume?

The 32k crystal goes on TOSC1 & TOSC2, which would be the same pins for an external high-speed crystal on this line.

I shut it down before PowerDown with ASSR=0x00; and re-enable with ASSR=0x20; (setting the AS2 bit). A datasheet note: the datasheet says that this mechanism is "optimized for a 32kHz crystal" but doesn't explicitly state whether there are internal capacitors (e.g., no load caps needed like for a DS1305/6 RTC). We plopped on 12pf and it seems to work OK. Like the datasheet says, it >>really does<< take nearly a second for the crystal to stabilize when it is enabled. In the long run it doesn't matter to us; I'm just doing a continuous recalibration while external power is applied.

I can't say about the power since I don't want it running during PowerDown for my app like you would for a RTC. I don't think you could use POwerDown for that--you don't wake up from a timer interrupt IIRC.

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

aweinstein wrote:
What do you do with the BOD ?
... However, it is known that not using the BOD is dangerous if you are using the EEPROM. Does your design have this dilema?

I leave the BOD off (and the watchdog, too) for power consumption reasons.

Remember that in my app power is NEVER lost or a reset done for the life of the product. (Well, that is the theory, anyway. :) ) The calculations are that the lithium battery will last as long as the shelf-life of the battery. It should have a sharp knee in the voltage curve which we will monitor and report.

No EEPROM writes will be done when on battery power. The only EEPROM writes in the whole app are reconfiguration commands via the UART, and the UART & DS485 are only powered by the external power.

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

Quote:
Remember that in my app power is NEVER lost or a reset done for the life of the product.

Heh - let me know how the NEVER works out in a few years :lol:

-Colin

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

I worked on an application that used a mega128 which was expected to never lose power. More than a few customers have sent back the unit after being confronted with a non-user friendly setup interface. I don't know if the unit actually lost power or if it reset via the watchdog timer. Either way, the program should have included a way to elegantly verify eeprom data and skip the setup process in case for some reason "NEVER" doesn't work out.

Hopefully your application handles a reset nicely?

/* John Butera */

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

Good news RE: low current and correct datasheets!
Did you find a nice solution to Battery switch over? Always undecided which way to go with that, specially in using internal RTC. Most of the time i just opt for a DS1305|6 with built in battery switchover. Its an easy solution as i already have all the code and i dont have to be concerned with possible missing RTC interrupts and loosing an extra seconds here and there. Unfortunately, I feel there will be future apps where I need battery back up of the µC anywhy.
My prevous ideas were along the lines of using chips like that used for SRAM battery backup but they are typically low current devices. (they are only backing up RAM after all!) I guess i could do it manually with either FET or relay switchover but i have a feeling there is a better way. Care to share?

Cheers
Steve

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

About MSP430:
Texas Instruments will introduce a whole new MSP430 series with mass market availability in 1Q 2005 (If TI's deadlines are more reliable than Atmel's, otherwise add 1 year :wink: ).

http://www.ti.com/corp/docs/land...

http://focus.ti.com/docs/pr/pres...


These new MSP430F2xx will have a peak performance of max. 16 MIPS vs. max. 8 MIPS for the current MSP430 devices. Power consumptoion will also be lower than for the current MSP430 devices:

Quote:
The new MSP430F2xx family features enhancements that reduce system cost and improve reliability both in low-power and general purpose applications. The new MSP430F2xx family provides twice the processing performance at half the power consumption compared to earlier MSP430F1xx devices.

It looks like MSP430 will be an even stronger competitor to AVR.

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

schtevo wrote:

Did you find a nice solution to Battery switch over? ...

It is not elegant, but it works. Diodes from the regulator and the battery pointing to the Vcc rail, so a simple "wired-OR" configuration with blocking. The non-elegant part is the diode drop from each supply. So coming out of a 5V regulator (which directly powes the DS485 & a couple of other chips) the Vcc rail is ~4.3V when powered, and ~3V off the battery.

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

theusch wrote:
schtevo wrote:

Did you find a nice solution to Battery switch over? ...

It is not elegant, but it works. Diodes from the regulator and the battery pointing to the Vcc rail, so a simple "wired-OR" configuration with blocking. The non-elegant part is the diode drop from each supply. So coming out of a 5V regulator (which directly powes the DS485 & a couple of other chips) the Vcc rail is ~4.3V when powered, and ~3V off the battery.

Lee


You can use schottky diodes instead of standard silicon diodes.
Schottky diodes only has a forward voltage drop of 0.2V-0.4V typical (depnding on the current) vs. 0.6V-0.7V for standard silicon dides.
http://www.fact-index.com/s/sc/s...

Try to read this article about power ORing too:
http://powerelectronics.com/mag/...

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

AndersAnd wrote:

You can use schottky diodes instead of standard silicon diodes.
Schottky diodes only has a forward voltage drop of 0.2V-0.4V typical (depnding on the current) vs. 0.6V-0.7V for standard silicon dides. ...

True, but the most important selection factor was leakage, and the next being availability (including second-source) and reasonable cost. The amount of the voltage drop isn't a critical factor. We didn't find a readily-available Shottky with very low leakage.

Another note on the Mega48: I found that the internal reference voltage Vint was almost exactly the nominal 1.1V as the datasheet says. The datasheet gives the usual +/-10% limits for internal Vint. I'll be checking the next batches of chips. If other batches are also real close, that will be a nice addition to the AVR line.

I put in an "auto calibration" for my Vint that is probably old hat to you veterans out there. The ARef pin is decoupled with a cap to Gnd. Then, when I am powered off a 5V regulator with a known Vcc, I set up the ADC to use AVcc as Aref and do a few conversions on the bandgap level. Since the AVcc is at a known level I can calculate the actual value of the bandgap which will be used during normal operation as VRef. The first few prototypes only varied a count or two from the "ideal" 1.1V.

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

Quote:
Then, when I am powered off a 5V regulator with a known Vcc, I set up the ADC to use AVcc as Aref and do a few conversions on the bandgap level.

How do you determine the actual value of the 5V regulator output ? Are you measuring it with a voltmeter and entering this value into your calibration rutine? I am asking because a typical regulator like a 7805 has an output voltage in the range of 4.8 to 5.2 volts. Or are you using a regulator with a better tolerance, like a LP2950 (0.5%) ?

Regards,
Alejandro.
http://www.ocam.cl

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

I understand your concerns about the +5 precision. This particular application does not have high accuracy requriements and the "auto-cal" keeps production costs down.

We usually find that our 5V regulators are no more than +/-50mV under normal conditions of room temperature and modest draw. For this particular app that is close enough, and we can save the cost of a precise voltage source and/or calibration procedures. Other apps that need more accuracy use a precision reference source and/or calibration procedures.

An interesting note on taking our Mega48 current draw measurements. We found that our measurments with a Fluke 189 in current mode and/or a 10MegOhm 'scope probe were drawing more power than the app itself. :) Isn't that the Heisenberg Uncertainty Principle?

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.