Attiny1616 - 3 times higher power consumption in active mode

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

 

Hi all,

 

I'm currently working with the Attiny1616, a very nice little Microcontroller indeed! But I was surprised about the active supply current not matching the values in the datasheet.

 

On page 585 there is a diagram for power consumption depending on cpu frequency and input voltage:

 

 

It should consume about 150uA at 3V and 0.5MHz.

 

I fused BODCFG = 0b00011100, OSCCFG = 0b00000001, SYSCFG0 = 0b11000110, SYSCFG1 = 0b100

 

So I'm using 16MHz for the OSC20 and in my code a prescaler divison of CLKCTRL_PDIV_32X_gc, means the CPU is running at 0.5MHz. I could confirm the speed, as all the delays are correct if I set F_CPU to 0.5MHz.

 

These are my measurements (Otii Arc):

 

  • @3.6V, 0.5MHz: 604uA (should: 180uA) during _delay_ms
  • @3V, 0.5MHz: 497uA (should: 150uA) during _delay_ms
  • @1.8V, 0.5MHz: 311uA (should: 90uA) during _delay_ms

 

Deep sleep current is fine and according to spec (around 100nA), so nobody else is consuming the power.

 

All 20 pins are configured as OUTPUT pins.

 

Hardware wise I quickly assembled a test board, only the Attiny, 0.1uF and 10uF caps at the supply line and the following schematic:

 

PB0 ------ [4.7k resistor] ------ PC3 ------ [4.7k resistor] ------ PB1

 

In my normal setup this is the I2C connection, where I power the bus via PC3 instead of pulling it up to VCC (which reduces leakage currents for some sensors if they are powered down).

 

Apart from that everything is bulk Attiny.

 

Do you have any ideas?

 

Thanks in advance, Timm

 

 

 

 

 

Last Edited: Fri. Aug 14, 2020 - 11:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There may be something other than the CPU core that consumes power.
For example

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

MAybe am missing something...but _delay_ms doesnt mean that you are in sleep mode...its just a dealy function that blocks the processor from doing other thing, how do you know that you are in sleep mode ?...could you post a code along with an osci picture ?

 

regards,

Moe

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

kabasan wrote:

There may be something other than the CPU core that consumes power.
For example

 

Yes, I thought so, but still the numbers don't really match. In the table they tested @1MHz and 3V. If I do it, I measure 652uA average consumption.

 

It should be 300uA for the cpu (see graphic in first post) + 125uA OSCM20 (didn't see that in the table before) + 19uA BOD = 444uA. I still measure 200uA more.

 

Code is simple:

 

int main(void) {
	while (1) {
		// set cpu speed
		_PROTECTED_WRITE(CLKCTRL.MCLKCTRLB, CLKCTRL_PDIV_16X_gc | 1 << CLKCTRL_PEN_bp); // first bit = prescaler, always enabled
		_PROTECTED_WRITE(CLKCTRL.MCLKCTRLA, 0); // use internal 16/20MHz oscillator
		while(CLKCTRL.MCLKSTATUS & CLKCTRL_SOSC_bm) { ; } // wait until clock changed

		// all ports as output
		PORTA.DIR = PIN0_bm | PIN1_bm | PIN2_bm | PIN3_bm | PIN4_bm | PIN5_bm | PIN6_bm | PIN7_bm;
		PORTB.DIR = PIN0_bm | PIN1_bm | PIN2_bm | PIN3_bm | PIN4_bm | PIN5_bm;
		PORTC.DIR = PIN0_bm | PIN1_bm | PIN2_bm | PIN3_bm;

		_delay_ms(1000); // here I measure the current

		// go to sleep
		set_sleep_mode(SLEEP_MODE_PWR_DOWN); 				// deep sleep
		power_all_disable();   						// power off ADC, Timer 0 and 1, serial interface
		cli(); 								// disable interrupts for CCP = noInterrupts() function in Arduino
		sleep_enable();							// enable
		disableBODInSleep();						// disable BOD totally (if not already set by fuses)
		sei();           						// enable interrupts again = interrupts() function in Arduino
		sleep_cpu();            					// stop
		sleep_disable();        					// wake again
		power_all_enable();     					// power everything back on
	}
}

 

Last Edited: Fri. Aug 14, 2020 - 11:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Moe123 wrote:

MAybe am missing something...but _delay_ms doesnt mean that you are in sleep mode...its just a dealy function that blocks the processor from doing other thing, how do you know that you are in sleep mode ?...could you post a code along with an osci picture ?

 

regards,

Moe

 

Sorry, the text was a bit mixed up. During _delay_ms I measure the active current. See the code above.

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

Do you have a debugger connected? If the UPDI unit is enabled it will also consume power.

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

El Tangas wrote:

Do you have a debugger connected? If the UPDI unit is enabled it will also consume power.

 

Nope, physically disconnected the UPDI pin for the measurements. Strange, right?

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


That is the measurement with the code from above:

 

 

Sleep current is okay:

 

 

 

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

What happen if you move this line :

	power_all_disable();   						// power off ADC, Timer 0 and 1, serial interface 

up before the delay? (I'm not sure what is default on) 

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

Low power requires careful analysis of the complete system, please show a schematic or at least a clear picture of your setup.

It doesn't take much "leakage" to raise the consumption by a few 10's of microamps, so it's hard to answer with out seeing your setup.

0.5MHz clock, how have you proven this speed? 

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Last Edited: Fri. Aug 14, 2020 - 01:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

power_all_disable();

 

Just tested it, not a single uA difference unfortunately! As far as I understood all peripherals of the Attiny1616 are powered down by default after reset.

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


ki0bk wrote:

Low power requires careful analysis of the complete system, please show a schematic or at least a clear picture of your setup.

It doesn't take much "leakage" to raise the consumption by a few 10's of microamps, so it's hard to answer with out seeing your setup.

0.5MHz clock, how have you proven this speed? 

 

Jim

 

 

Hey Jim, true, can happen quickly. But 200uA more than the datasheet says (@1MHz) is really a lot, especially in battery powered scenarios where the MCU should stay on most of the times. As the deep sleep current is okay, nothing else but the Attiny itself can consume the energy.

 

I use a custom hardware design, as mentioned in the first post, where I only assembled the Attiny after having that issue. So I could test it in an isolated environment. The corresponding schematic looks like this:

 

 

Most of the pins are floating and the ones connected via the 4.7kOhm network seem not to leak anything. The updi pin is also floating if I do the current measurements.

 

Regarding "proving 0.5MHz": well, the delay time I see on the oscilloscope corresponds to my settings of F_CPU. Actually, I can't think about something I could do wrong here. OSCCFG is fused to use 16MHz and I use a prescaler division of 16 (CLKCTRL_PDIV_16X_gc). Do you have any idea?

 

I tested it with two Attiny1616s already, same behavior, so I guess no random hardware fault.

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

timmbo85 wrote:
So I'm using 16MHz for the OSC20 and in my code a prescaler divison of CLKCTRL_PDIV_32X_gc, means the CPU is running at 0.5MHz

timmbo85 wrote:
Regarding "proving 0.5MHz": well, the delay time I see on the oscilloscope corresponds to my settings of F_CPU. Actually, I can't think about something I could do wrong here. OSCCFG is fused to use 16MHz and I use a prescaler division of 16 (CLKCTRL_PDIV_16X_gc). Do you have any idea?

This quote and the code shown in #4 do not match, with the code shown, you would have a 1MHz clock and according to the chart a 300uA current.

So sorry if I'm confused, but details matter with low current apps.  Which code are you actually running, CLKCTRL_PDIV_32X_gc or CLKCTRL_PDIV_16X_gc, it makes a difference.

We can not see what your actually doing, we can only go on what you have told/shown us.  Also how are you measuring your current, is it accurate at uA levels?

It could be the DS is wrong, DS erros are almost legendary at MicroMel, copy/paste errors have happened in the past.

A single floating input pin can make a huge difference in current draw, your code shows ports are beings set to outputs, are there any other pins not accounted for?

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

ki0bk wrote:
A single floating input pin can make a huge difference in current draw,

I had the same initial "something is floating or leaking" as some responders.  However, OP has, to me, demonstrated that leaking and floating and measurement are taken care of, given the picture and explanation of the sleep case.

 

Now, if I was confused, I'd probably do a case with delay at the startup, along with repeating sleep/awake to address anything that may be one-time.

 

So my observation would be that the next thing is the clock source -- how do other clock sources match with datasheet numbers?

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.

Last Edited: Fri. Aug 14, 2020 - 03:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

timmbo85 wrote:
So I'm using 16MHz for the OSC20 and in my code a prescaler divison of CLKCTRL_PDIV_32X_gc, means the CPU is running at 0.5MHz

timmbo85 wrote:
Regarding "proving 0.5MHz": well, the delay time I see on the oscilloscope corresponds to my settings of F_CPU. Actually, I can't think about something I could do wrong here. OSCCFG is fused to use 16MHz and I use a prescaler division of 16 (CLKCTRL_PDIV_16X_gc). Do you have any idea?

This quote and the code shown in #4 do not match, with the code shown, you would have a 1MHz clock and according to the chart a 300uA current.

So sorry if I'm confused, but details matter with low current apps.  Which code are you actually running, CLKCTRL_PDIV_32X_gc or CLKCTRL_PDIV_16X_gc, it makes a difference.

We can not see what your actually doing, we can only go on what you have told/shown us.  Also how are you measuring your current, is it accurate at uA levels?

It could be the DS is wrong, DS erros are almost legendary at MicroMel, copy/paste errors have happened in the past.

A single floating input pin can make a huge difference in current draw, your code shows ports are beings set to outputs, are there any other pins not accounted for?

 

Jim

 

 

Thanks Jim, I appreciate your help. Initially I was talking about 0.5MHz setting, but after kabasan posted the peripheral power consumption table I tested it as well @1MHz (because the table values in the datasheet were measured @1MHz) to have a direct comparison. 

 

I tested different clock speeds at different voltage levels and compared it to the datasheet. That here is my summary:

 

OSCCFG fused to 16MHz, CLKCTRL_PDIV_32X_gc:
@3.6V, 0.5MHz: 604uA (datasheet: 180uA + 19uA BOD + 125uA OSC20M = 324uA) during _delay_ms
@3V, 0.5MHz: 497uA (datasheet: 150uA + 19uA BOD + 125uA OSC20M = 294uA) during _delay_ms
@1.8V, 0.5MHz: 311uA (datasheet: 90uA + 19uA BOD + 125uA OSC20M = 234uA) during _delay_ms

 

OSCCFG fused to 16MHz, CLKCTRL_PDIV_16X_gc
@3.6V, 1MHz: 829uA (datasheet: 360uA + 19uA BOD + 125uA OSC20M = 504uA) during _delay_ms
@3V, 1MHz: 663uA (datasheet: 300uA + 19uA BOD + 125uA OSC20M = 444uA) during _delay_ms

 

OSCCFG fused to 20MHz, CLKCTRL_PDIV_2X_gc:
@3.6V, 10MHz: 4.03mA (datasheet: 3.5mA + 19uA BOD + 125uA OSC20M) during _delay_ms
@3V, 10MHz: 3.27mA (datasheet: 2.9mA + 19uA BOD + 125uA OSC20M) during _delay_ms

 

OSCCFG fused to 20MHz, CLKCTRL_PDIV_4X_gc:
@3V, 5MHz: 2mA (datasheet table: 1.8mA -> System power consumption measured with peripherals disabled and without I/O drive)

 

The deviation is not constant, not even with different input voltage. Basically I get the impression that none of the datasheet currents are correct. Or, maybe more realistic, I'm doing something wrong ;-)

 

The Otii Arc is very high precision and my tool of choice in a lot of other projects. It is very accurate down to nA level, see the measured sleep current of the Attiny. No other pins connected, everything like drawn in the schematic above.

 

What do you mean by DS error? Never heard about it.

 

Timm

Last Edited: Fri. Aug 14, 2020 - 05:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


theusch wrote:

ki0bk wrote:
A single floating input pin can make a huge difference in current draw,

I had the same initial "something is floating or leaking" as some responders.  However, OP has, to me, demonstrated that leaking and floating and measurement are taken care of, given the picture and explanation of the sleep case.

 

Now, if I was confused, I'd probably do a case with delay at the startup, along with repeating sleep/awake to address anything that may be one-time.

 

So my observation would be that the next thing is the clock source -- how do other clock sources match with datasheet numbers?

 

Good idea, I will try out the 32kHz oscillator as main clock source (have done it before, but didn't measure the current) and compare it to the datasheet values. With the Attiny1616 my only clock options are OSC20M, 32kHz oscillator or external oscillator that I physically can't connect on my custom board.

 

 

(no worries, I don't use Atmel Start, as I heard it can sometimes do crazy stuff, picture is only for clarification of the available clock sources on the 1616)

 

I will try repeated sleep/awake as well.

 

Timm

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

timmbo85 wrote:
What do you mean by DS error? Never heard about it.

DS, Data Sheet errors, as has been documented on many occasions here, the data sheets sometimes have copy/paste and other errors, most get corrected eventually if reported to MicroChip.

At this point, it looks like your doing things correctly, so if the results do not match those of the DS, then perhaps you need to open a support ticket to find out how MC came up with the values in the DS, and see if there is something you have not duplicated in their tests conditions.

 

Jim

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

ki0bk wrote:

timmbo85 wrote:
What do you mean by DS error? Never heard about it.

DS, Data Sheet errors, as has been documented on many occasions here, the data sheets sometimes have copy/paste and other errors, most get corrected eventually if reported to MicroChip.

At this point, it looks like your doing things correctly, so if the results do not match those of the DS, then perhaps you need to open a support ticket to find out how MC came up with the values in the DS, and see if there is something you have not duplicated in their tests conditions.

 

Jim

 

 

 

Ah, datasheet, of course, now I get it ;-) Well in that case I would be quite disappointed, as the current draw at times nearly is double of what the datasheet "promised". Can't really believe that all the power consumption curves are wrong. Still thinking I'm overlooking something.

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

 

I tried out the 32kHz oscillator as main clock and I get values that nearly match the datasheet:

 

 

Using 32kHz oscillator as main clock
@2V: 31uA (datasheet: 8uA + 19uA BOD = 27uA)
@3V: 37.3uA (datasheet: 10uA + 19uA BOD = 29uA)
@3.5V: 40.4uA  (datasheet: 13uA + 19uA BOD = 32uA)

 

I fully disabled BOD in active mode by fusing it, I then measured:

@2V: 8.5uA (datasheet: 8uA)
@3V: 12.4uA (datasheet: 10uA)
@3.5V: 14.5uA  (datasheet: 13uA)

 

So, I'm happy with the 32kHz results, but the OSC20M values still are wrong.

 

Timm

 

Edit: That is the code snippet to activate the 32kHz oscillator as main clock:

 

		_PROTECTED_WRITE(CLKCTRL.MCLKCTRLB, CLKCTRL_PDIV_2X_gc | 0 << CLKCTRL_PEN_bp); // set the main clock prescaler divisor to 2X and disable the Main clock prescaler (with PEN = 0, means CLK_PER = CLK_MAIN (prescaler disabled))
		_PROTECTED_WRITE(CLKCTRL.MCLKCTRLA, CLKCTRL_CLKSEL_OSCULP32K_gc | 0 << CLKCTRL_CLKOUT_bp); // set the main clock to internal 32kHz oscillator, clock out disabled
		_PROTECTED_WRITE(CLKCTRL.OSC20MCTRLA, 0x00); // ensure 20MHz isn't forced on
		while(CLKCTRL.MCLKSTATUS & CLKCTRL_SOSC_bm) { ; } // wait until clock changed

 

 

Last Edited: Fri. Aug 14, 2020 - 05:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

timmbo85 wrote:

I tried out the 32kHz oscillator as main clock and I get values that nearly match the datasheet:

 

@3V: 37.3uA (datasheet: 10uA + 19uA BOD = 29uA)
@3V: 12.4uA (datasheet: 10uA)

You are close to breaking out all the currents.  BOD here ~ 25uA 

You could try an external 0.5 or 1MHz clock, and thus check the  OSC20M = 125uA DS value.

There may be a few uA not included in their tables for the  SysClk divider ?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
		power_all_disable();   						// power off ADC, Timer 0 and 1, serial interface

Are you sure it is really doing all of this (did you specifically look for your chip?)

 

For such an investigation, it is best to set everything yourself, so you know exactly what has been config'd & how. Then you can keep an exact verified checklist.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

avrcandies wrote:
Are you sure it is really doing all of this

Well, if it did not, then wouldn't the same problem facilities be powered when using the 32k clock source?

 

[this seems to be drifting very close to the date code and country of origin in the recent '328p thread]

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

Oh I see now, yes ,that is good news that it "matches up" at 32 KHz.   Too many times a different chip flavor comes along & some required tweak is not made to old functions and mayhem ensues.  

Yep, it does indeed seems like there might be some factory fun going on, someone tossed in an extra spoonful of phosphorous or boron.     

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Who-me wrote:

timmbo85 wrote:

 

I tried out the 32kHz oscillator as main clock and I get values that nearly match the datasheet:

 

@3V: 37.3uA (datasheet: 10uA + 19uA BOD = 29uA)
@3V: 12.4uA (datasheet: 10uA)

You are close to breaking out all the currents.  BOD here ~ 25uA 

You could try an external 0.5 or 1MHz clock, and thus check the  OSC20M = 125uA DS value.

There may be a few uA not included in their tables for the  SysClk divider ?

 

 

Deep diving into current consumption.. a lot of fun! ;-) It is important for my project though.

 

If I understood the datasheet correctly you can only use an external 32kHz oscillator. And then I guess results will be pretty similar to what I already measured with the 32kHz internal one.

 

I'm happy with a few uA more or less, no worries. But @1MHz (16MHz main clock) and 3.6V it is 829uA measured vs. 504uA "promised" in the datasheet (without BOD in active: 776uA measured vs. 485uA). That is more than 60% higher. 325uA more or less in the ultra low power world is really a lot, don't you think? Can't imagine a clock divider needs that much!

 

Timm

 

 

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

avrcandies wrote:

Oh I see now, yes ,that is good news that it "matches up" at 32 KHz.   Too many times a different chip flavor comes along & some required tweak is not made to old functions and mayhem ensues.  

Yep, it does indeed seems like there might be some factory fun going on, someone tossed in an extra spoonful of phosphorous or boron.     

 

I tested two 1616s independently (even from different suppliers) with similar results. So it seems not to be a random issue. The OSC20M is factory calibrated (fine tuned and temperature calibrated), values are stored in  OSC20MCALIBA and  OSC20MCALIBB. Maybe the calibration values are wrong?

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

One test could be to feed your chip with an external clk (just 1 MHz from an other 1616) to see if the osc. or the logic that use the extra power.

 

But the question also is how far from "typ." can a chip be (it's not max values) 

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


timmbo85 wrote:
If I understood the datasheet correctly you can only use an external 32kHz oscillator.
sparrow2 wrote:
One test could be to feed your chip with an external clk

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


Well, trying to connect the oscillators of two 1616s is quite some effort and I'm not sure if this really will help. I think it will create a bunch of side effects.

 

Anyhow, things are getting interesting right now! I was having a look at the clock control diagram:

 

 

Looking at TCD (which is NOT listed in the power consumption table above, strange enough) I figured out that this is running independently of my main clock prescaler and is by default configured to use undivided OSC20M. In case of using the 32kHz oscillator (OSC20M off) also TCD will not have an oscillator input. So I reconfigured TCD to use CLK_PER instead of OSC20M. I mean it is off by default, so I thought no power consumption, but I was wrong. I simply added that line here:

 

TCD0.CTRLA = TCD_CLKSEL_SYSCLK_gc | TCD_CNTPRES_DIV1_gc; // TCD shall use prescaled clock, not "raw OSC20M", divider is not relevant here, TCD disabled (bit 0)

And power consumption dropped! Even though TCD is disabled all way long.

 

OSCCFG fused to 16MHz, CLKCTRL_PDIV_16X_gc -> running @1MHz, BOD in active off (by fuse):

Before the line above: 776uA

After the line above: 709uA

datasheet: 360uA (from graphic) + 125uA OSC20M = 485uA

 

67uA less in active! Still more than 200uA away from specs, but I will dig deeper into it.

 

Timm

 

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

timmbo85 wrote:

Well, trying to connect the oscillators of two 1616s is quite some effort and I'm not sure if this really will help. I think it will create a bunch of side effects.

 

???  Where did that idea come from?

 

How hard is it to have another device, AVR or otherwise, output a square wave trying various frequencies?  From the datasheet, it appears that there are two choices.  You made the picture and annotated it; don't you see the EXTCLK path?  Surely that would shed light on your situation -- does the EXTCLK take less power than the internal clock? 

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

I found a way to isolate the OSC20M power consumption by putting the 1616 in standby sleep (300nA) and forcing OSC20M to keep staying on while in standby with this code:

 

_PROTECTED_WRITE(CLKCTRL.OSC20MCTRLA, 0b10); // OSC20M in standby sleep

The OSC20M alone needs 154uA (vs. 125uA in datasheet, but I think the deviation is okay). So it is not the oscillator that wants too much current, but something else while the 1616 is in active mode. 

 

Timm

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


theusch wrote:

timmbo85 wrote:

Well, trying to connect the oscillators of two 1616s is quite some effort and I'm not sure if this really will help. I think it will create a bunch of side effects.

 

???  Where did that idea come from?

 

How hard is it to have another device, AVR or otherwise, output a square wave trying various frequencies?  From the datasheet, it appears that there are two choices.  You made the picture and annotated it; don't you see the EXTCLK path?  Surely that would shed light on your situation -- does the EXTCLK take less power than the internal clock? 

 

Jap, I clearly see the EXTCLK path and you are right, it's not that much effort. And I would know how much current the OSC20M really needs. With the one line of code from the post above I got the information. And confirmed some other stuff:

 

  • Standby current (not power down) of the 1616 fits to the datasheet values
  • Internal 32kHz oscillator needs 400nA (500nA in datasheet, wow, we are better here!) 

 

Edit: Standby mode seems the way to go in order to find out which peripheral needs how much, I will continue testing:

 

Last Edited: Sat. Aug 15, 2020 - 03:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is all very interesting. So what happens in terms of power consumption if you connect TCD to EXTCLK and there is no actual AC signal there (i.e. tied to GND or VDD)?

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

timmbo85 wrote:

If I understood the datasheet correctly you can only use an external 32kHz oscillator.

It cannot use a 16Mhz Crystal, but that's why I said external clock. Feed a 1MHz sq wave into EXTCLK in your #28

 

timmbo85 wrote:

... TCD power consumption dropped!

 

OSCCFG fused to 16MHz, CLKCTRL_PDIV_16X_gc -> running @1MHz, BOD in active off (by fuse):

Before the line above: 776uA

After the line above: 709uA

datasheet: 360uA (from graphic) + 125uA OSC20M = 485uA

67uA less

A worthwhile find, shows the clock distribution costs of TCD, that disable must be 'late' ie after the clock tree.

 

timmbo85 wrote:

The OSC20M alone needs 154uA (vs. 125uA in datasheet, but I think the deviation is okay). So it is not the oscillator that wants too much current, but something else while the 1616 is in active mode. 

That's another  29uA ...

 

Leaves something else ?

 

Last Edited: Sat. Aug 15, 2020 - 10:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First I don't have the chip.

 

I looked at the datasheet, and have a question (that could have something to do with this problem).

 

How does the UPDI actually work, and which clk. does it use ?

 

If it need the higher clk, then for a test try to program the    PA0  reset  UDPI   pin to be a normal  reset or port, to see if that change anything (depending of your tool I guess that there is a risk that you can't program it back)

 

 

About 25 ago I worked on this setup: 

8051(real with mask ROM),

Atmel flash

Home made ASIC that was the master in the system (handled clk reset had XRAM etc for the the 8051) 

For a small version I was looking into a solution with a Atmel flash version of the 8051.

But ran into a problem that it used to much power at boot (in the init stage we only had about 10mA, then later all needed power).

The datasheet said that it should only use about 5mA, but it used about 40mA.

It turned out that on the Atmel chip you have to give a clk while the power went up, else it would be in a bad state. (our ASIC did not clk before the reset was released.)

 

So many strange things can happen :)  

 

 

Add:

I should add that Atmel never made an errata about the error.(they where fast to give me the newest version of the chip but it Was the same problem)

 

 

 

 

Last Edited: Sun. Aug 16, 2020 - 08:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
How does the UPDI actually work, and which clk. does it use ?

 

The UPDI unit has a dedicated oscillator, which runs @ 4MHz by default but can be set to up to 16MHz.

Probably, it's similar to the main internal oscillator and uses a comparable amount of power. Unfortunately, UPDI power consumption data is missing from the datasheet.

 

The UPDI unit gets enabled if a pulse longer than 10us appears on the UPDI pin, but if you leave the pin floating, an internal pull up will prevent random noise from accidentally enabling it.

 

So I don't think the UPDI is the issue here.

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

El Tangas wrote:

The UPDI unit gets enabled if a pulse longer than 10us appears on the UPDI pin, but if you leave the pin floating, an internal pull up will prevent random noise from accidentally enabling it.

 

So, on the t1616 the UPDI pin is also /REST and PA0.

 

/RESET functionality is enabled by a fuse and cleared with 12V.

 

But what about PA0? Can you use the pin as PA0 as well as UPDI and what happens if you have it connected to something that generates >10us pulse? Does that wake up UPDI?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Brian Fairchild wrote:
But what about PA0? Can you use the pin as PA0 as well as UPDI

 

If PA0 is configured as UPDI, it's connected to both the UPDI, and also to the CPU as read only. You can therefore monitor PA0 from software, but the UPDI unit will also react.

If PA0 is configured as I/O, it should be disconnected from the UPDI, and the CPU can use it as input/output (though I never actually used this mode). The UPDI unit can no longer be used in low voltage mode in this case.

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

But in #4 OP show that PA0 is an output, so perhaps it's the problem ?

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

sparrow2 wrote:
But in #4 OP show that PA0 is an output, so perhaps it's the problem ?

 

Well, I think that is ignored for the UPDI pin since it's in UPDI mode, but we never know...

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

I have a tiny817 xplained, which has the slight mod to measure current (remove a shorting resistor). The 3v3 values seem to be about right, accounting for the internal clock current not in the graph, and the difference is the same from top to bottom for the ext vs int. In power down and standby (no peripherals in use), in any case takes about 100nA.

 

    // code- while(1);

    // default fuses (no BOD, no WDT)

 

    // ext - 10MHz, 3V3 (from a mega4809 clkout)
    // 1.76mA   10MHz/1, 10MHz
    // 125uA    10MHz/32, 312kHz

 

    // osc20m (20MHz), 3V3
    // 1.89mA   20MHz/2, 10MHz
    // 235uA    20MHz/64, 312kHz
    
    // osc20m (20MHz), 5V
    // 5.06mA   20MHz/2, 10MHz
    // 638uA    20MHz/64, 312kHz
    

 

One thing to note, floating pins make a big difference- close to 800ua for the 24pin tiny. It also makes no difference if you either set the pins to output or enable pullups ( IF there is nothing on the pins) or disable the input. I have been just disabling all inputs on the avr0/1 in early startup code, then when they are wanted they have to be setup like always with the addition that any input will also need to remove the input disable. This way, you don't have to figure out what is hanging on all the pins which you would have to do if setting to output or using pullups.

 

I looked at the the atmel start generated code, and they go through all the ports in startup, and set all the pin pullups on. The result in the case of the tiny817 xplained board, is an extra 184ua because they now have the pullup driving the led. I'm not quite sure why they don't just disable the inputs instead, but if using their code I would change it.

Last Edited: Mon. Aug 17, 2020 - 02:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EL tangas & Sparrow,

 

UPDI pin can be used as digital input only in case if you want to use this pin beside UPDI mode..other than this configuration it will be no longer accessable through low voltage and only a 12V could reconfigure it. But in everycase, I dont think that this is the OP problem...

 

OP,

a hint for the OP, your pin confinguration can be (OFF, OUTPUT, INPUT...etc). What I have noticed is that once you set the internal pull-up resistors it will consume more power...thats why, all the unused pins try to not to activate the internal pull-up resistors.

 

regards

 

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

Moe123 wrote:
What I have noticed is that once you set the internal pull-up resistors it will consume more power
curtvm wrote:
It also makes no difference if you either set the pins to output or enable pullups ( IF there is nothing on the pins) or disable the input.

 

So, Moe, you have something on the pins?  Or the models are slightly different in operation?

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

El Tangas wrote:

This is all very interesting. So what happens in terms of power consumption if you connect TCD to EXTCLK and there is no actual AC signal there (i.e. tied to GND or VDD)?

 

Tried it out:

 

TCD0.CTRLA = TCD_CLKSEL_SYSCLK_gc | TCD_CNTPRES_DIV1_gc;
 -> 709uA
TCD0.CTRLA = TCD_CLKSEL_EXTCLK_gc | TCD_CNTPRES_DIV1_gc;
 -> EXT_CLK Floating: 712uA (+3uA)
 -> EXT_CLK Grounded: 712uA (+3uA)

 

So, it basically adds +3uA, nothing else.

 

Edit: In case you are the "jtag2updi-El Tangas": great work, thanks for sharing that with the world.

Last Edited: Mon. Aug 17, 2020 - 11:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So it consumes a bit more power with no clock. Unexpected.

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

El Tangas wrote:

sparrow2 wrote:
But in #4 OP show that PA0 is an output, so perhaps it's the problem ?

 

Well, I think that is ignored for the UPDI pin since it's in UPDI mode, but we never know...

 

I do also think that is not the problem. Especially as sleep currents are correct (where the pins keep their previous pin configuration and UPDI is still working).

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

It was just a guess, and in sleep neither the 20MHz or UPDI run. My guess was (and still is) that UPDI's clk take power when enabled (and the chip run) 

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

curtvm wrote:

I have a tiny817 xplained, which has the slight mod to measure current (remove a shorting resistor). The 3v3 values seem to be about right, accounting for the internal clock current not in the graph, and the difference is the same from top to bottom for the ext vs int. In power down and standby (no peripherals in use), in any case takes about 100nA.

 

    // code- while(1);

    // default fuses (no BOD, no WDT)

 

    // ext - 10MHz, 3V3 (from a mega4809 clkout)
    // 1.76mA   10MHz/1, 10MHz
    // 125uA    10MHz/32, 312kHz

 

    // osc20m (20MHz), 3V3
    // 1.89mA   20MHz/2, 10MHz
    // 235uA    20MHz/64, 312kHz
    
    // osc20m (20MHz), 5V
    // 5.06mA   20MHz/2, 10MHz
    // 638uA    20MHz/64, 312kHz
    

 

One thing to note, floating pins make a big difference- close to 800ua for the 24pin tiny. It also makes no difference if you either set the pins to output or enable pullups ( IF there is nothing on the pins) or disable the input. I have been just disabling all inputs on the avr0/1 in early startup code, then when they are wanted they have to be setup like always with the addition that any input will also need to remove the input disable. This way, you don't have to figure out what is hanging on all the pins which you would have to do if setting to output or using pullups.

 

I looked at the the atmel start generated code, and they go through all the ports in startup, and set all the pin pullups on. The result in the case of the tiny817 xplained board, is an extra 184ua because they now have the pullup driving the led. I'm not quite sure why they don't just disable the inputs instead, but if using their code I would change it.

 

Cool! Thanks for testing, so here the current seems to match the datasheet values, right?

 

Regarding pin setup of floating pins: I had the lowest currents, both in active and standby, with setting floating pins as INPUT, no pull-up and input buffer disabled. Setting them as OUTPUT is also okay, no difference in the sleep modes, but in active I measured additonal +1uA per floating pin.

 

Well, I did some more interesting tests, these are my results:

 

(all @1MHz, BOD fully disabled, 3.6V):

  • In ACTIVE mode (TCD0 changed to use prescaled clock): 709uA (see posts above)
  • In IDLE mode (CPU off, everything else on): 437uA -> 709 - 437 = 272uA for the CPU only (matches datasheet values)
  • In STANDBY mode (CPU off, all peripherals off): 350nA (matches datasheet values)
  • In STANDBY mode (CPU off, OSC20M on, OSC32KCTRLA on + ADC0+1, TCB0+1, RTC, CCL, AC0+1+2, DAC active in standby but off): 155uA

 

-> 155uA for the peripherals + 272uA for the CPU = 427uA, but I measure 709uA in active -> "something else" (not CPU, not OSC20M, not 32kHz oscillator, not ADC, not TCB, not RTC, not CCL, not AC, not DAC) is running in active and needs 282uA of additional current
-> Even in Idle "something else" needs 282uA more
-> I thought maybe the default USART fractional baud generators, but no, tried to alter every possible setting without any effect
-> I thought maybe some default TWI settings?!

 

Fun fact: _delay_ms() needs quite a bit more power than while(1), due to the use of timers:

 

  • _delay_ms(): 709uA
  • while(1): 682uA

 

Conclusion: with the super fast wake-up times of the Attiny it is clever to not use _delay_ms() but rather send it to Standby with an internal RTC interrupt to wake it up after x milliseconds

 

Timm

 

 

 

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

theusch wrote:

Moe123 wrote:

What I have noticed is that once you set the internal pull-up resistors it will consume more power

 

curtvm wrote:

It also makes no difference if you either set the pins to output or enable pullups ( IF there is nothing on the pins) or disable the input.

 

 

So, Moe, you have something on the pins?  Or the models are slightly different in operation?

 

Hi Lee,

 

I had nothing attached to the pins, I've noticed this in an old project, you can follow my comment here and the discussion afterwards about power consumption in 0&1 series from last year:

 

https://www.avrfreaks.net/commen...

 

IIRC, activating the internal pull-up resistors added some few uA more.

 

Regards,

Moe

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

sparrow2 wrote:

It was just a guess, and in sleep neither the 20MHz or UPDI run. My guess was (and still is) that UPDI's clk take power when enabled (and the chip run) 

 

The UPDI logic is running in all sleep modes and is capable of waking the chip up in order to flash it. It runs pretty much fully independent of power modes. Still I can think about some additional current in active due to debugging functionality or whatever..

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

>so here the current seems to match the datasheet values, right?

 

It does on my tiny817 at 3v3, but at 5v it seems ok until it gets down in the low end which seems high, but then I'm not really sure I can figure out what its supposed to be from reading the datasheet and graphs.

 

The tiny xplained board has an led and a switch, the power was from a mega4809 board for 3v3 and vbus when using 5v, the updi was still connected to the on board debugger and had no effect. The code was simple- set all pins to input disable, set the clock and prescale, then a while(1), or various sleep modes.

 

 

>Fun fact: _delay_ms() needs quite a bit more power than while(1), due to the use of timers:

 

I'm not sure what version of _delay_ms you have, but there are no timers involved with the avr-libc version-

https://godbolt.org/z/dPP9vo

 

 

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

 

Just saw an interesting vid that reminded me of this thread.

It's linked from this article  https://hackaday.com/2020/09/15/deep-sleep-problems-lead-to-forensic-investigation-of-troublesome-chip/

 

 

What is this "Aries" company? And is that Cyrillic above the "Aries" word? Where do these chips come from? So many questions, so little answers...

 

edit: oh, I see it's discussed in another thread already. Let me check.

 

Last Edited: Tue. Sep 15, 2020 - 09:01 PM