ATTiny power consumption at different voltages -- where is the power going?

[derGoldstein]

The datasheets for the ATTiny84 and ATTiny85 show a power consumption of 0.3mA at 1MHz, when the voltage is 1.8V.
I've put and arduino bootloader on an attiny84, and at 1.8V/8MHz the current drawn is 1.8mA. I assume that if I were to program it natively (and at a lower frequency) it would draw less power, but that's not the problem -- the problem is when I dial up the voltage to 3.3V it draws ~4.1mA, and at 5V it draws ~9mA... Why? The program on it is the same, it's a do-nothing sketch, and there's nothing connected to the outputs.
This document from atmel about the differences between the attiny84 and attiny84A confirms that this is the (approximate) expected difference in power draw:
http://www.atmel.com/Images/doc8187.pdf

Why would increasing the operating voltage increase current consumption? Are there on-board peripherals that turn on at different voltages and start drawing power?
I need it to operate at 5V because of the op-amps I'm using, and also it needs to drive some LEDs, so I can't just drop a 1.8V LDO in there.

Is there any functionality that I can explicitly turn off that would get it to draw less power at higher voltages? (I don't mean sleep mode, it still needs to be operating)

[MattHollands]

My thought would be that this:

When you are switching a transistor, it doesn't switch instantly because there is some capacitance. So you can imagine a capacitor charging up or down each time a transistor switches. When you're operating at 5V, the capacitor has to charge to a higher energy than when you are operating at 1.8V. This is because Q=CV where C is capacitance, V is voltage and Q is charge. Therefore increasing the voltage increases the amount of charge required. Therefore, you either need to charge for longer, or at a higher current. In this case we charge at a higher current so that the processor is fast enough to keep up with your clock.

[sleemanj]

Not to mention Ohm's law.  You know, that whole V=IR thingy.  If V across a fixed resistor increases, I also must.  What's the most first quoted specification of any MOSFET?  RdsOn, in Ohms.

As for turning stuff off, the ADC is the biggest user if you don't need it, ensure it's switched off - if using Arduino, it's switched on by default, you'll have to turn it off (check datasheet for ADC enable bit).

[JPortici]

Current consumption in a MCU depends on four things, basically.
- Supply voltage (not always)
- Operating frequency
- Enabled Peripherals and their clock speed
- Actual firmware

2 and 3 are obvious, since the current consumption in a FET gate is proportional to its switching frequency
Actual firmware may suprise... or not, because different instructions require different gates to be switched, also different number of memory access, etc.

Then, while current consumption ALSO depends on applied voltage, most if not all modern MCUs may be operated at 5V, but their internal core logic is running at a much lower voltage, tipically 3V3,1V8,1V0, ... usually using an LDO, so between some range current consumption is almost constant.
Those without internal LDOs (Like PIC16LF) have the core supply directly tied to VDD, so their current consumption IS greatly dependent on applied voltage, they can also run at lower voltages because there is no need to have a minimum VDD for the LDO to operate correctly.

[derGoldstein]

When you are switching a transistor, it doesn't switch instantly because there is some capacitance. So you can imagine a capacitor charging up or down each time a transistor switches. When you're operating at 5V, the capacitor has to charge to a higher energy than when you are operating at 1.8V. This is because Q=CV where C is capacitance, V is voltage and Q is charge. Therefore increasing the voltage increases the amount of charge required. Therefore, you either need to charge for longer, or at a higher current. In this case we charge at a higher current so that the processor is fast enough to keep up with your clock.

But the voltage increase itself, times the current, already means more power. 5V/1mA is 0.005W, and 1.8V/1mA is 0.0018W. Charging a 1uF capacitor to 2V requires half the energy needed to charge it to 4V, but the current is the same, it's the voltage that doubles.

In order to turn on a mosfet you have to "charge" its gate to a certain Q. If you're operating at 5V more power would be required to turn it on than if you're operating at 1.8V, but the current required would remain the same.

[MattHollands]

But the voltage increase itself, times the current, already means more power. 5V/1mA is 0.005W, and 1.8V/1mA is 0.0018W. Charging a 1uF capacitor to 2V requires half the energy needed to charge it to 4V, but the current is the same, it's the voltage that doubles.

I think you're getting confused between power and charge. I never said anything about power.

If we have a capacitor and we want to charge it from 1.8V to 5V, we need to push more current into the capacitor. We can either do a small current for a long time, or a large current for a short time.

[edit] I did say energy so I see where the confusion maybe came from. If you want to charge a capacitor to a higher voltage, you need to push more charge into it [/edit]

[MattHollands]

But the voltage increase itself, times the current, already means more power. 5V/1mA is 0.005W, and 1.8V/1mA is 0.0018W. Charging a 1uF capacitor to 2V requires half the energy needed to charge it to 4V, but the current is the same, it's the voltage that doubles.

Also, charging a 1uF cap to 4V required 4x the energy than charging it to 2v. E = C*V^2. If you double the voltage, the energy increased by 4x.

[Ian.M]

Another reason for increase current consumption at higher voltages is shoot-through current.

Consider a typical CMOS inverter^* with rail-to-rail input and output signals: Its composed of PMOS upper, and NMOS lower transistors with the sources to the rails, the drains linked as the output and the gates linked as the input. 

As long as the supply voltage is less than the sum of the two gate threshold voltages, during switching, one transistor will turn off before the other turns on.   However the threshold voltage must be significantly less than the supply voltage so the transistors can turn hard on, so if a MCU is specified to work down to 1.8V, the threshold voltages of the MOSFETs its made of must be significantly lower.   If you increase the supply voltage to greater than the sum of the threshold voltages, there is a short time during every transition that both transistors conduct, drawing a significant pulse of current from the supply.  Its therefore not surprising that the supply current starts increasing rapidly somewhere near 3V.

The situation is even worse if you have floating inputs to the MCU as at higher supply voltages the input pin can settle at a voltage where both the upper and lower transistors of the input gate are on.  Fortunately that's an easy fix: Make all unused I/O pins outputs and set them to logic '0' and for any inputs (that you cant set as an output) that may float occasionally, either enable the internal pullups or use external pullup or pulldown resistors, depending on whether the pin is normally high or low.

* Other types of gates have similar shoot-through problems but are more complex to analyse.

[derGoldstein]

Sounds like there isn't much I can do to get power consumption down while keeping the operating voltage at 5V...
I have a lot of parts in the circuit that couldn't go down to 1.8V -- driving LEDs, mosfets that turn on fully at ~4.1V, and op-amps that have a problem working very close to ground (maybe I can get them working at 3.3V, at lower accuracy).
I can find a low-quiescent-current LDO that outputs 1.8V, and add a LOT of level-shifters to the circuit. I have charlieplexed LEDs so I have to push AND pull current on some pins.

It's going to be battery-powered, so I need minimal power draw. Should I be looking at a different MCU altogether? Or will this likely be a scenario that I'll have to deal with when using most MCUs, so I might as well try to solve it with this one using many external parts?

[alm]

Many low power parts are limited to 3.3 V anyway, so would require the same circuit changes as running the ATTiny at 3.3 V.

Depending on the application, you can either change the software to spend more time in sleep modes and wake up from external interrupts (not sure if the ATTiny can wake up from internal timers), or lower the clock speed (e.g. CKDIV8 fuse). Do not expect miracles from low clock speeds, but it may help.

[Ian.M]

Figure 22-1. Active Supply Current vs. Low frequency (0.1 - 1.0 MHz) in the ATtiny85 datasheet indicates that if you drop the clock frequency low enough, you can get the typical power consumption below 0.2mA, even at 5V.   It looks like you may be able to get it down as low as 0.1mA with a clock of 31.25KHz (8MHz/256).  The maximum clock divisor you can set using the CLKPRE register is /256. (see section 6.3 System Clock Prescaler), which you can change it on the fly and it takes effect within two cycles of the slower clock (+ one of the faster).

If the response time with a 31.25KHz clock is excessive for your application, you can use the following strategy:
1. wait for event
2. bump speed up to 8MHz and process event as fast as possible
3. drop speed back to 31.25KHz
4. goto 1.

As long as the time spent running at 8MHz is very small in proportion to that at 31.25KHz, the average power consumption will be fairly close to the lower speed figure. 

You also may be able to use power-down sleep mode, for even lower current, but the wakeup options are very limited.

[derGoldstein]

Figure 22-1. Active Supply Current vs. Low frequency (0.1 - 1.0 MHz) in the ATtiny85 datasheet indicates that if you drop the clock frequency low enough, you can get the typical power consumption below 0.2mA, even at 5V.   It looks like you may be able to get it down as low as 0.1mA with a clock of 31.25KHz (8MHz/256).  The maximum clock divisor you can set using the CLKPRE register is /256. (see section 6.3 System Clock Prescaler), which you can change it on the fly and it takes effect within two cycles of the slower clock (+ one of the faster).

If the response time with a 31.25KHz clock is excessive for your application, you can use the following strategy:
1. wait for event
2. bump speed up to 8MHz and process event as fast as possible
3. drop speed back to 31.25KHz
4. goto 1.

As long as the time spent running at 8MHz is very small in proportion to that at 31.25KHz, the average power consumption will be fairly close to the lower speed figure. 

You also may be able to use power-down sleep mode, for even lower current, but the wakeup options are very limited.

I've been trying out "intermittent" on time -- when the ADC is turned off and the ATTiny is in "SLEEP_MODE_PWR_DOWN" it draws 6uA, which is great. The problem is that it needs to keep several LEDs on for long spans of time, which means it has to be on, even at a very low clock speed.
I didn't consider altering the clock speed while in operation... I didn't even know that was possible. I'll try it out, thanks!

[alm]

How about using something like a flip-flop to drive the LEDs without a continuous voltage from the micro? Quiescent current draw should be much lower.

[floobydust]

I believe the Atmel Icc number is for the CPU core not peripherals.
Probably the Arduino bootloader enables all peripherals?

Shut off the A/D converter and reference, that is a big current drain.
ADCSRA &= ~_BV(ADEN);

Watch for power wasted if pullups enabled but pin is low.

You can verify your hardware drain putting ATTiny in sleep mode:

#include <avr/sleep.h>

.
.
.
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
  sleep_cpu();


I ended up using  sleep mode on the ATTiny as it is not super low current like the Pico power series.
Ended up getting <0.08mA at 5V, so I just wake up on pin change.

[ebastler]

I have charlieplexed LEDs ...

Hey, I learned a new word, and a new technique! 
https://en.wikipedia.org/wiki/Charlieplexing

Thanks for the pointer; I had not come across that one yet. This looks like a nice little trick to drive multiple LEDs on the cheap. I might use it occasionally in the future!

[derGoldstein]

Thanks for the pointer; I had not come across that one yet. This looks like a nice little trick to drive multiple LEDs on the cheap. I might use it occasionally in the future!

Careful when implementing charlieplexing into anything of vital importance. Charlieplexing doesn't fail intuitively, it can be very frustrating tracking down an error in software OR hardware.
If the system in question requires the LEDs to always faithfully reflect some internal state then make sure to map them out exactly, name each LED, and program routines that are solely there to help you isolate individual LED locations (you can comment them out when you're done, but you'll be glad they're there if something goes wrong).

Still, it can allow a small MCU with very few IO pins to output more visual information than you'd normally get.

[Ian.M]

+1
Assuming you have a timer tick interrupt, its usually worth writing an ISR to handle the charlieplexing, with a simple bit-mapped interface to the main program.   You can test that thoroughly and reuse it in future projects.  From the main program's point of view, its then as simple as controlling LEDs directly connected to individual pins of a port.  If you don't have an interrupt, write the charliplexing code as a single routine called by the superloop.

Each pass of the ISR is one timeslot. In each timeslot you tristate the pins used in the previous timeslot, check the corresponding bit of the interface variable and if set, look up the pin to set high and the pin to set low, and set them, then finally increment the slot number wrapping back to 0 after the last.

One key issue is the duty cycle - if you have N LEDs but only M of them ever need to be on at the same time, to maintain good brightness levels, you should only give your charlieplexing ISR M timeslots.