TinyAvr 1 series: 0.71uA with RTC running ? But how ?

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

Hello AVR experts,

 

The datasheet of the attiny1614 claims a low power consumption of 0.71uA in standby mode with RTC running at 1.024kHz from internal ULP oscillator.

 

attiny1614 Power consumption Datasheet extract

 

But I have difficulties to get those 0.71uA. my best result are (for 5V from USB socket) :

  • 5uA with RTC running.
  • 120nA in full power down (wake on external interrupt / reset).

Even if I run it at 5V, I was expecting something closer to 1uA.

 

Update: I have similar results for 3V (3.3V from a linear voltage regulator) with 100nF decoupling caps:

  • 3.46uA  with RTC running, measured with a 100kOhm (99.1k) shunt resistor (346mV voltage drop)
  • 3.9uA measured with the uA functionality of my DDM.
  • Measuring tool: Multimetrix DMM 120 (Input resistance for DC voltage measurement > 10MOhm, datasheet www.multimetrix.fr/docs/NF/694310A01_DMM121_FR_Ed_02.pdf)
  • I also tried with several digital multimeters, measurements are the same.

 

This is my setup:

  • The bare 1614 SFR chip is directly hooked with test clips to 5V from USB.
  • I measure current with a 100kOhm shunt resistor (I short it when the chip resets to have enough power to start it).
  • The chip is configured using the atmel start configuration stated in assignment 2 from this application note: http://ww1.microchip.com/downloa... (ADC and Power Optimization with tinyAVR® 0- and 1-series, and megaAVR® 0-series) i.e:
    • Sleep controller enabled and set in standby mode,
    • RTC enabled and configured at 1.024kHz (prescale 32 + ULP 32kHz internal oscillator),
    • Global Interruption enabled + RTC interruption + flag cleared inside ISR.
    • In main, loop on sleep_cpu() : while(1){sleep_cpu();}
    • No extra user code.
    • BOD disabled (I checked the corresponding fuse, all zero).
    • Input buffer disabled on all I/Os.

 

Maybe I miss something really obvious, I am not an expert with these new avr chips.

 

If you have a similar chip (817 /1616/ 1617 etc..)  laying around, could you check if you can achieve the 0.71uA or close? (My solar project design needs such a low power consumption to run indoor, 5uA is way more consumption than the 1-2uA produced).

 

Thanks in advance for your help.

 

UPDATE: If made no mistake, I think I have the correct power consumption with this bare code example compiled with Atmel Studio:

  • 0.68uA ( 68mV voltage drop), what a perfect match for the claimed 0.71uA @ 3V, 25°C.
  • I am investigating the difference with the previous tests.

 

Test code with RTC running, MCU in eternal sleep (no interrupt, wake on reset only)

 

/*
 * LowPowerRTC.c
 *
 * Created: 07/11/2018 19:31:59
 * Author : Cedric
 */ 

#include <avr/io.h>
#include <avr/sleep.h>

#define F_CPU 3333333UL

#include <util/delay.h>

int main(void)
{
	//Configure pins: ////////////////////////////////////////

	// Set all pins to low power mode:
	for (uint8_t i = 0; i < 8; i++) {
		*((uint8_t *)&PORTA + 0x10 + i) |= 1 << PORT_PULLUPEN_bp;
	}

	for (uint8_t i = 0; i < 8; i++) {
		*((uint8_t *)&PORTB + 0x10 + i) |= 1 << PORT_PULLUPEN_bp;
	}	

	//RTC INIT: //////////////////////////////////////////////

	while (RTC.STATUS > 0) {} // Wait for all register to be synchronized

	RTC.CTRLA = RTC_PRESCALER_DIV1_gc	//NO Prescaler
	| 1 << RTC_RTCEN_bp       	//Enable RTC
	| 1 << RTC_RUNSTDBY_bp;   	//Run in standby

	RTC.CLKSEL = RTC_CLKSEL_INT1K_gc; // 32KHz divided by 32, i.e run at 1.024kHz

	_delay_ms(6000); //Consumes high power for 6secs before going into eternal sleep (to see a change in measurement on the DMM).

	//Main loop: /////////////////////////////////////////////
	while (1) {
		set_sleep_mode(SLEEP_MODE_STANDBY);
		sleep_enable();
		sleep_cpu(); //Go into eternal sleep

		//Dead code:
		_delay_ms(2000); //If MCU is awoken from any mysterous interrupt, stay still for power measurement with DMM.
	}
}

 

UPDATE: Test code with periodic wake every 10 sec using RTC:

  • Less than 0.7uA when in sleep mode
  • More than 1mA when awoken (stay still for few seconds for slow current measuring with DMM).
/*
 * LowPowerRTC.c
 *
 * Created: 07/11/2018 19:31:59
 * Author : Cedric
 */ 

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/sleep.h>

#define F_CPU 3333333UL

#include <util/delay.h>

//RTC ISR //////////////////////////////////////////////////////
ISR(RTC_CNT_vect)
{
	RTC.INTFLAGS = RTC_OVF_bm;
}

int main(void)
{
	//Configure pins: ////////////////////////////////////////
	
	// Set all pins to low power mode:
	for (uint8_t i = 0; i < 8; i++) {
		*((uint8_t *)&PORTA + 0x10 + i) |= 1 << PORT_PULLUPEN_bp;
	}

	for (uint8_t i = 0; i < 8; i++) {
		*((uint8_t *)&PORTB + 0x10 + i) |= 1 << PORT_PULLUPEN_bp;
	}	

	//RTC INIT: //////////////////////////////////////////////

	while (RTC.STATUS > 0) {} // Wait for all register to be synchronized

	RTC.PER = 1024*10; //10 secs between wakes.
	RTC.INTCTRL = 0 << RTC_CMP_bp
	| 1 << RTC_OVF_bp; //Overflow interrupt.
	
	RTC.CTRLA = RTC_PRESCALER_DIV1_gc	//NO Prescaler
	| 1 << RTC_RTCEN_bp       	//Enable RTC
	| 1 << RTC_RUNSTDBY_bp;   	//Run in standby

	RTC.CLKSEL = RTC_CLKSEL_INT1K_gc; // 32KHz divided by 32, i.e run at 1.024kHz

	_delay_ms(6000); //Consumes high power for 6secs before going into eternal sleep (to see a change in measurement on the DMM).
	
	//Enable interrupts //////////////////////////////////////
	sei();
	
	//Main loop: /////////////////////////////////////////////
	while (1) {
		set_sleep_mode(SLEEP_MODE_STANDBY);
		sleep_enable();
		sleep_cpu(); //Go into sleep
		
		//On awakening
		_delay_ms(2000); //Stay still for power measurement with DMM.
	}
}

 

 

This topic has a solution.
Last Edited: Fri. Nov 9, 2018 - 06:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you confirm directly that all peripherals are disabled?

 

i.e. show your code.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "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." - Heater's ex-boss

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

Do you have debugging active,serial interface on your prototyping board or anything connected, for example a programmer? This may affect your measurements.

extronic.pl

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

Thanks for answering so fast.

 

Brian Fairchild wrote:

Can you confirm directly that all peripherals are disabled?

 

i.e. show your code.

 

I have attached the archive of the project. As I said, it is the untouched code generated from atmel start. I only have added the sleep_cpu() in the main loop to force the CPU to go into sleep mode.

 

extronic wrote:

Do you have debugging active,serial interface on your prototyping board or anything connected, for example a programmer? This may affect your measurements.

 

The bare chip (fresh new from the reel) is only connected on pins VDD and GND using two tests hooks. No PCB, no prototype board, no debugger hooked, no programmer, no LED, etc..

 

To compile, I use the makefile in the gcc folder given by atmel start. By default, the debug flags are enabled (-DDEBUG -g3). Should I try without these flags ? I can't really see how it could reduce the power consumption.

 

I also tried powerdown mode with the PIT enabled but power consumption is still 5uA. Also, I am pretty sure that the MCU goes into sleep mode (In one test, I blinked a LED on wake up in the main.c . If the chip wasn't in sleep mode, the LEDs would have been blinking continuously).

Attachment(s): 

Last Edited: Tue. Nov 6, 2018 - 10:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah yes, START. That rabbit hole.

 

You might want to look at the datasheet on page 75 (11.3.2.1) and what it says about disabling individual peripherals.

 

As for START, I have no idea if it does that for you.

 

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "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." - Heater's ex-boss

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

Brian Fairchild wrote:

Ah yes, START. That rabbit hole.

 

You might want to look at the datasheet on page 75 (11.3.2.1) and what it says about disabling individual peripherals.

 

As for START, I have no idea if it does that for you.

 

 

On tinyAVR 1 series, it seems that peripherals are not enabled by default and consume power only if the enable bit in the corresponding register is set.

 

I have checked the code generated, enable bits are not set by atmel Start. (There is not too much hidden code, only the mcu_init() function that disable all peripherals and enable pullups on I/Os for reducing power consumption).

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

Cedric Berenger wrote:
Input buffer disabled on all I/Os.

 

Does this make any difference, if all the pins have pull-ups enabled, anyway?

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

Cedric Berenger wrote:
The bare chip (fresh new from the reel) is only connected on pins VDD and GND using two tests hooks. No PCB, no prototype board, no debugger hooked, no programmer, no LED, etc..

 

Proper bypass caps are mandatory!  Your test setup is not valid. 

The spec says 3v vcc, and your assumption that 5v would produce similar results is also invalid, to get the results listed in the data sheet takes careful attention to details and proper test conditions.

Also measuring such low currents can be difficult as just adding a test probe may change the results.  Again careful attention to detail is required.

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

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

Cedric Berenger wrote:
BOD disabled (I checked the corresponding fuse, all zero).

Hmmm--is that product line different from all other AVR8, where a not-enabled fuse has a value of 1/erased, and a programmed fuse has a value of 0?

 

Sparkies:  Could the lack of a bypass cap cause power draw fluctuations?

 

When measuring current down in those low areas, it isn't that easy.  How have you verified that the AVR is really drawing those measured amounts?  Could the measurement be off?  Could the measurement be causing a draw?

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: Tue. Nov 6, 2018 - 01:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

Cedric Berenger wrote:
The bare chip (fresh new from the reel) is only connected on pins VDD and GND using two tests hooks. No PCB, no prototype board, no debugger hooked, no programmer, no LED, etc..

 

Proper bypass caps are mandatory!  Your test setup is not valid. 

The spec says 3v vcc, and your assumption that 5v would produce similar results is also invalid, to get the results listed in the data sheet takes careful attention to details and proper test conditions.

Also measuring such low currents can be difficult as just adding a test probe may change the results.  Again careful attention to detail is required.

 

Jim

 


 

You are right, I have improved my setup and updated my results in the first post:

 

I have similar results for 3V (3.3V from a linear voltage regulator) with 100nF decoupling caps:

  • 3.46uA  with RTC running, measured with a 100kOhm (99.1k) shunt resistor (346mV voltage drop).
  • 3.9uA measured with the uA functionality of my DMM (no voltage drop).
  • Measuring tool: Multimetrix DMM 120 (Input resistance for DC voltage measurement > 10MOhm, datasheet www.multimetrix.fr/docs/NF/694310A01_DMM121_FR_Ed_02.pdf)
  • I also tried with several different digital multimeters, measurements are all the same.

 

I am pretty confident that my current measurements are Ok: Input impedance of all my tools are of at least 10MOhm, so at 3V the measurement error should be at maximum of 300nA. Also, to remove any doubts, I will triple check tomorrow with the DSO in the lab.

 

theusch wrote:

Hmmm--is that product line different from all other AVR8, where a not-enabled fuse has a value of 1/erased, and a programmed fuse has a value of 0?

 

I have read several fuse values with avrdude, the values correspond with the default values stated in the datasheet of the attiny1614.

 

To remove any doubts about the BOD fuse, I have explicitly disabled the BOD in software. Also, I will try to explicitly clear the enable bit of all peripherals, but I don't expect any improvement: the datasheet clearly state for each peripheral that the enable bit is 0 upon reset or loaded from fuses (bits in most of them are 0).

 

 

 

Last Edited: Tue. Nov 6, 2018 - 07:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It certainly looks like something odd is going on. A glance at a random xmega datasheet shows that you ought to be seeing figures at least 3 times smaller than you are.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "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." - Heater's ex-boss

Last Edited: Tue. Nov 6, 2018 - 07:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see you have interrupts enabled and a while loop for periodic wake ups, your DSO may show you achieving your sleep current, but when running the average usage is higher as shown on your DMM.

try disabling the interrupts so the cpu stays asleep.

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

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

ki0bk wrote:

I see you have interrupts enabled and a while loop for periodic wake ups, your DSO may show you achieving your sleep current, but when running the average usage is higher as shown on your DMM.

try disabling the interrupts so the cpu stays asleep.

 

I have just tried: I have disabled the global interrupt and also commented the RTC interrupt, no change in power consumption.

 

Also the periodic wake up is configured for one wake every second and the ISR does nothing (it just clear the interrupt flag).

 

With sleep mode disabled, I measure a  consumption of 9uA (900mV drop from 3.3V)

Last Edited: Tue. Nov 6, 2018 - 08:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Time to post your findings and ask for help from MC support, ask how the results were measured and the program to verify.

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

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

ki0bk wrote:

Time to post your findings and ask for help from MC support, ask how the results were measured and the program to verify.

 

Jim

 

 

I have posted the issue at the microchip support. I will update here when I have news.

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

Cedric Berenger wrote:
I have read several fuse values with avrdude, the values correspond with the default values stated in the datasheet of the attiny1614.

Then why did you say

Cedric Berenger wrote:
I checked the corresponding fuse, all zero

 

Anyway, perhaps you, or someone here, can put together a very minimal test program without the mysteries of Start.

 

 

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:

Cedric Berenger wrote:
I have read several fuse values with avrdude, the values correspond with the default values stated in the datasheet of the attiny1614.

Then why did you say

Cedric Berenger wrote:
I checked the corresponding fuse, all zero

 

 

I mean that the single fuse corresponding to BOD is 0b00000000 (all bits are zero). Other fuses (oscillator configuration for instance) contains bits that are ones.

 

theusch wrote:

Anyway, perhaps you, or someone here, can put together a very minimal test program without the mysteries of Start.

 

Ok I will try to do a minimal main.c that does the same thing.

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

Here is the minimal program (I think it should do pretty much the same thing that the code generated from atmel start):

 

#include <avr/io.h>
#include <avr/sleep.h>

int main(void)
{
	//RTC INIT: //////////////////////////////////////////////

	while (RTC.STATUS > 0) {} // Wait for all register to be synchronized

	RTC.CTRLA = RTC_PRESCALER_DIV1_gc	//NO Prescaler
	            | 1 << RTC_RTCEN_bp       	//Enable RTC
	            | 1 << RTC_RUNSTDBY_bp;   	//Run in standby

	RTC.CLKSEL = RTC_CLKSEL_INT1K_gc; // 32KHz divided by 32, i.e run at 1.024kHz

	//SLPCTRL INIT: /////////////////////////////////////////

	SLPCTRL.CTRLA = 1 << SLPCTRL_SEN_bp       // Sleep enabled
	                | SLPCTRL_SMODE_STDBY_gc; // Standby Mode

	//Main loop:
	while (1) {
		sleep_cpu(); //Go into eternal sleep
	}
}

 

To compile, I usually use the makefile from atmel start, but maybe commands like that are correct:

avr-gcc -g -Os -mmcu=attiny1614 -B dev/attiny1614 -I include/ -c demo.c
avr-gcc -g -Os -mmcu=attiny1614 -B dev/attiny1614 -I include/ -o demo.elf demo.o
avr-objcopy -j .text -j .data -O ihex demo.elf demo.hex

I will try to upload it.

 

Edit: I have uploaded it, I am not sure of what is going on (wrong measurements, hundreds of uA). (not sure if the code is compiled correctly or if I have initialized everything properly). I will debug it tomorrow.

Last Edited: Tue. Nov 6, 2018 - 11:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cedric Berenger wrote:
Edit: I have uploaded it, I am not sure of what is going on (wrong measurements, hundreds of uA).
Cedric Berenger wrote:
or if I have initialized everything properly

Indeed, Start does stuff.  What I was wondering is whether they missed a disabling bit somewhere.

 

I'm not a Tiny1 person.  But, anyway, from past experience I'd suggest the first sanity check program to not worry about that clock.  Use the simplest clock source for the AVR.  Start up and stay awake for e.g. 10 seconds to allow a reading of active current draw.  Then go to deepest sleep, with no wakeup sources enabled.  The AVR will sleep with the fishes until reset.  If you can't match active and deep sleep draws to datasheet values, it is no use going any further until that is resolved.

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

Cedric Berenger wrote:
Even if I run it at 5V, I was expecting something closer to 1uA.
typical to 2uA max (estimated) at room temperature once the tiny1614 has been characterized enough; datasheet's TBDs will be replaced with data and some of the maximums will appear after enough wafers have been evaluated for long enough (probability by sampling)

The ones at Microchip need enough margin to allow for process variability in wafer fab and margin per the business unit's goals (supply to meet demand, revenue)

tinyAVR 1-series is what would of been the 5 volt version of XMEGA D series (no DMA, non-pipelined ADC) in a small package.

XMEGA16D4, ICC, power-save, RTC 1KHz from 32KHz crystal, 3V, 25C, 0.7uA typ to 2uA max

Worst case current consumption for leakage and such is square by each 10C increase.

Very hot day in south France could reach 8uA max; more likely is 4uA max.

For your application, might need to either bin tiny1614 or sample tiny1614 from each reel or tray.

Recommend a hot plate or oven test for the bench test unit and all prototype units; sample, test, measure, and evaluate production PCBA.

Cedric Berenger wrote:
I measure current with a 100kOhm shunt resistor (I short it when the chip resets to have enough power to start it).
Alternate instruments :

  • Super-capacitor and high-Z DMM (C = Q/V leads to i = C * dv/dt, evaluate C's tolerance and leakage or self-discharge)
  • RTCM and DSO
  • SMU (Source Measure Unit)
  • Power Debugger and Atmel Studio 7 - an enhanced Atmel-ICE, SDRAM onto UC3A3, ADC by XMEGA128A1U, CSA, 1 ohm sense that's switched, 12V for RESET

SMU - Keithley 2450, 1uA range, 100uV max Burden, 0.025%+300pA

RTCM - ee-quipment, 10uA range, 70mV max Burden, 1uA error

SMU can be rented or leased.

RTCM is approximately an order of magnitude less expensive than a SMU.

Power Debugger's bandwidth is an order of magnitude greater than RTCM.

Cedric Berenger wrote:
(My solar project design needs such a low power consumption to run indoor, 5uA is way more consumption than the 1-2uA produced).
143nA for one arm Cortex-M but it's single-sourced (Ambiq Micro)

Likewise for one RTC though, IIRC, Phillips also has sub-threshold RTC.

Can switch VCC from some RTC though there's charge consumption due to power cycling VCC (Q = CV)

Most FETs are leaky especially at a hot temperature; there are a relative few FETs that have reasonable leakage.

Texas Instruments has very low current timers and low-leakage power switches to time and switch TI MSP430TM.

Some IPS from multiple manufacturers are low leakage.

Microchip has very low-Iq LDO some with very low shutdown current.

Capacitors leak, read with care a MLCC's datasheet, may one be able to acquire MLCC cheeky

 


ATTINY1614 - AVR Microcontrollers - Microcontrollers and Processors

ATxmega16D4 - 8-bit AVR Microcontrollers - Microcontrollers and Processors

The Embedded Muse 354, Tools and Tips

(last half)

Neal Somos is using supercapacitors to measure current of a circuit:

...

[university paper, ammeter tool review]

Real-Time Current Monitor with USB – ee-quipment.com (RTCM)

http://cdn.shopify.com/s/files/1/0362/5057/files/ee-203_product_overview.pdf?299 (RTCM datasheet)

Development Tools and Debuggers - Tag Connect (RTCM for non-US customers)

https://www.mouser.com/datasheet/2/403/2450-Datasheet_1KW-60904-0-257452.pdf (Keithley 2450 SMU)

Power Debugger, Analog Hardware

Apollo MCUs – Ambiq Micro

https://www.digikey.com/en/supplier-centers/a/ambiq-micro

Real-Time Clocks – Ambiq Micro

Abracon Products - Standalone Real Time Clocks (RTC) (22nA RTC tab)

Nanotimers | Products | Clock and Timing | TI.com

MCP1811 - Linear Regulators - Power Management (150mA, 250nA typ Iq, shutdown : 10nA typ and 250nA max at 85C)

via Extend Battery Life in Portable Devices with New Ultra-low Iq LDO | Microchip Technology

via https://plus.google.com/+MicrochipTech/posts/jghQTdpMMgX

Hardware and Firmware Issues in Using Ultra-Low Power MCUs

 

"Dare to be naïve." - Buckminster Fuller

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

Cedric Berenger wrote:

(My solar project design needs such a low power consumption to run indoor, 5uA is way more consumption than the 1-2uA produced).

 

You may need to revisit your total design, as the worse case numbers are what you should target, not typicals.

Do you want only most of what you make to work, most of the time ?

 

 

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

(Ambiq Micro)

Texas Instruments did compete the sub-threshold theater with a, IIRC, 1KB program space MSP430TM.

The developer's version was RAM with a ROM bootloader; production in OTP.

IIRC, VCC was 0.5V (typ? ... amazing)

I've forgotten its part number.

 

TI's primary push is low leakage and FRAM due to high temperature electronics (geophysical, avionics; MSP430F2619S-HT is operating ambient -55C .. +150C)

http://www.ti.com/lit/ds/symlink/msp430fr5858.pdf

(page 21)

VCC current

LPM3.5, 12pF 32KHz crystal, 3V, 1.2uA max at 85C [less with 4pF crystal]

MSP430 is a major competitor to AVR, PIC, PIC24, and dsPIC though MSP430 doesn't have EBI.

MSP430 was selected by FSF steering for GCC.

MSP430 has an open source interface to its proprietary debuggers (MSPDS)

 


Texas Instruments Announces Ultra-Low Power MSP430 "Wolverine" MCU Series

...

...  or a solar panel the size of a microcontroller that enables environmental intelligence in any building or a smoke detector with carbon monoxide sensing, ...

...

via https://www.cnx-software.com/tag/power-harvesting/

MSPDS MSP Debug Stack | TI.com

 

Edits: elaborate CNX article, MSPDS

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Nov 7, 2018 - 04:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

... or a smoke detector with carbon monoxide sensing, ...

That's oh so good.

2 men overcome by carbon monoxide at Texas NASCAR speedway | Fort Worth Star-Telegram

forward one day as one of the two did pass on.

 

"Dare to be naïve." - Buckminster Fuller

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

Cedric Berenger wrote:
... no prototype board ...
tiny1614 are in SOIC 150mil (3.81mm) body; 1.27mm pitch is no problem.

There's 1.27mm pitch SMT proto board.

A shop likely has in its stock 2.54mm pitch through-hole proto board; glue and Kapton tape the tiny1614 then manually pitch convert it.

A ground plane is good for most digital due to its di/dt.

tiny1614 I/O pin : tFALL = 1.3ns typ (5V and 20pF load, excellent drive and excellent for EMI generation)

Pease "air ball" is excellent for high impedance circuits' bench tests (proof-of-concept)

Cedric Berenger wrote:
... no LED ...
A logic analyzer's typical input impedance is 100K ohms and approx 10pF; a pin can be default low.

 


Surface Mount Prototyping PCBs | BusBoard Prototype Systems

https://atmelcorporation.files.wordpress.com/2014/12/bob-pease-air-ball-prototype.jpg

ELM by ChaN's an artist ... 0.4mm pitch!

http://elm-chan.org/docs/wire/rc/wcs.jpeg

via ELM - Wiring Techniques (bottom, "How to mount SMD")

 

"Dare to be naïve." - Buckminster Fuller

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

theusch wrote:
Sparkies:  Could the lack of a bypass cap cause power draw fluctuations?
Yes

USB has up to a 5m cable between a hub and a device (significant inductance)

USB VBUS of 5 volts will briefly double (10V) at the device if there's no power termination during hot plug or unplug.

Capacitance limits dv/dt

Capacitance ESR limits di/dt

Polarized capacitors will significantly leak; for USB, about 1uA though could be an order of magnitude greater.

USB devices typically have USB VBUS TVS for over-voltage and PPTC to save the hub (notebook PC) from a device short (both are combined in a USB PolyZen)

 

USB in a NutShell - Chapter 2 - Hardware, Power (VBUS)

(next to last paragraph)

Other VBUS considerations are the Inrush current which must be limited. This is outlined in the USB specification paragraph 7.2.4.1 and is commonly overlooked. Inrush current is contributed to the amount of capacitance on your device between VBUS and ground. The spec therefore specifies that the maximum decoupling capacitance you can have on your device is 10uF. When you disconnect the device after current is flowing through the inductive USB cable, a large flyback voltage can occur on the open end of the cable. To prevent this, a 1uF minimum VBUS decoupling capacitance is specified.

...

PolyZen Devices for Overvoltage-Overcurrent Protection - Littelfuse

 

"Dare to be naïve." - Buckminster Fuller

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

theusch wrote:

Cedric Berenger wrote:
Edit: I have uploaded it, I am not sure of what is going on (wrong measurements, hundreds of uA).
Cedric Berenger wrote:
or if I have initialized everything properly

Indeed, Start does stuff.  What I was wondering is whether they missed a disabling bit somewhere.

I'm not a Tiny1 person

<...>.

 

 Neither me and what makes me wonder is whether Tinies are that much different from eg 324? I mean, for 324 peripherals are on at reset and you must explicitly disable them by setting correspondent bits in PRR. Is it opposite in Tiny1?

 Another thing to consider is DMM mentioned in the first message. Correct me if I'm wrong, but it seems like Multimetrix DMM 120 shows an average over quite a long period of time, like at the order of seconds. This is normal for handheld DMMs but not enough to see what really happens. I'd suggest something like 34465A or Otii or anything else that is fast enough and shows the process in time. It may be that MCU still reaches the desired low level but something wakes it up often enough for a DMM average to be that high.

 


Qoitech AB, The Home of Otii Arc, an SMU for every developer

Check out Otii solution at www.qoitech.com

 

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

Yabusame wrote:
Qoitech AB, The Home of Otii Arc, an SMU for every developer
indeed as it's about an order of magnitude less expensive than a bench SMU, it's portable, and its accuracy and bandwidth are a match for typical systems.

It gives RTCM a go though RTCM would fit in one's tool pouch and one would likely feel OK about having a customer borrow a RTCM to evaluate a prototype.

OTII_TechSpec_Overview_AUGUST_21

via Qoitech Distributor | DigiKey Electronics

 

"Dare to be naïve." - Buckminster Fuller

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

 

Alternate instruments :

  • tiny3217 Xplained Pro - tiny3217, UC3A4, SAMD20, CSA, 100 ohm sense that's switched

ATtiny3217 Xplained Pro

...

The ATtiny3217 Xplained Pro is recommended for evaluation of the following products: ATtiny3217, ATtiny3216, ATtiny1617, ATtiny1616, ATtiny1614, ATtiny1607, ATtiny1606 and ATtiny1604.

...

 

"Dare to be naïve." - Buckminster Fuller

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

You can also buy a Silabs dev board, quite a few of which have on board power monitoring, and hack it to monitor external circuits.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "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." - Heater's ex-boss

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

Cedric Berenger wrote:
... attiny1614 ...
fyi, 16KB errata were mostly corrected in 32KB tinyAVR 1-series.

tiny3216 errata for rev C die :

  • ADC - 2 minor
  • TCB - 1 major (missing one form of restart)

tiny3216 may be sampling; it's in wide SOIC.

 

ATTINY3216 - AVR Microcontrollers - Microcontrollers and Processors

https://www.mouser.com/Search/Refine.aspx?Keyword=ATtiny3216 (ETA is 14-Jan'19, lead time is 26 weeks)

 

"Dare to be naïve." - Buckminster Fuller

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

First post updated. It seems I have good results on my last test:

  • 0.68uA ( 68mV voltage drop),

 

I am investigating the difference with the previous tests. Maybe it is because I compiled without the debug flags (how it could be possible to reduce consumption ?)

 

Edit: I have tested: no, it is not the fault of debug flags nor the fault of the makefile provided by atmel start.

Last Edited: Wed. Nov 7, 2018 - 08:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How frustrating: I have created a new project with atmel start, and now it is working perfectly fine ! Around 0.6uA @ 3.3V measured with my DMM in series.

 

I have attached the bare project.

 

For now I can't figure out what was my mistake in the previous tests.

Attachment(s): 

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

Cedric Berenger wrote:

For now I can't figure out what was my mistake in the previous tests.

 

Were some pins floating ?  Anything else connected ?  it takes very little to add a few uA 

 

Cedric Berenger wrote:

I have created a new project with atmel start, and now it is working perfectly fine ! Around 0.6uA @ 3.3V measured with my DMM in series.

 

While you have a good result, you may like to try lowering Vcc, to see how that affects current. If you hope to work from uA power sources, come creativity will be needed.

 

How do you plan to manage the high reset-time current ? - AVRs need a lot, during reset, and until you can switch them into lowest power modes.

Last Edited: Wed. Nov 7, 2018 - 09:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

Cedric Berenger wrote:

For now I can't figure out what was my mistake in the previous tests.

 

Were some pins floating ?  Anything else connected ?  it takes very little to add a few uA

 

 

I have tracked the error down to the clock controller init: The power consumption goes down when I disable those lines from my old project:


ccp_write_io((void *)&(CLKCTRL.MCLKCTRLB),
             CLKCTRL_PDIV_6X_gc /* 6 */
                 | 0 << CLKCTRL_PEN_bp /* Prescaler enable: disabled */);

ccp_write_io((void *)&(CLKCTRL.MCLKCTRLA),
             CLKCTRL_CLKSEL_OSCULP32K_gc /* 32KHz Internal Ultra Low Power Oscillator (OSCULP32K) */
                 | 0 << CLKCTRL_CLKOUT_bp /* System clock out: disabled */);

/* wait for system oscillator changing to finish */
while (CLKCTRL.MCLKSTATUS & CLKCTRL_SOSC_bm) {
}

Edit: Actually this line is the culprit:

ccp_write_io((void *)&(CLKCTRL.MCLKCTRLA), CLKCTRL_CLKSEL_OSCULP32K_gc | 0 << CLKCTRL_CLKOUT_bp);

But why ? That is really weird !! OSCULP32K is running anyway because used by the RTC.

 

Edit 2: Maybe it is the way clocks are internally multiplexed: maybe an active clock will consume more if it is selected as main clock source, even if nothing use the main clock source.

 

 

 

Who-me wrote:

How do you plan to manage the high reset-time current ? - AVRs need a lot, during reset, and until you can switch them into lowest power modes.

 

On my prototype PCB, I have a 80mF seiko super capacitor (XH414HG-IV01E) with very low leakage and low enough ESR (Capacitor designed for backup RAM retention during several days / weeks). Furthermore, there is a 10uF MLCC for decoupling, and 14 BPW34 photodiodes used as a big photovoltaic cells (easier to find than proper amorphous dim light PV cells),  plus a low leakage barrier Schottky diode. The goal is to collect enough energy during the day to pass the night. If the voltage goes bellow the 1.8V, game is over: the POR will try to enable the 20MHz oscillator and then discharge even more quickly the super cap.

Last Edited: Wed. Nov 7, 2018 - 10:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cedric Berenger wrote:
plus a low leakage barrier Schottky diode

 

A low leakage Schottky... I'll believe it when I see it. Don't trust the datasheet leakage measured at 25ºC... even a modest temperature increase will make the leakage increase exponentially.

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

El Tangas wrote:

Cedric Berenger wrote:
plus a low leakage barrier Schottky diode

 

A low leakage Schottky... I'll believe it when I see it. Don't trust the datasheet leakage measured at 25ºC... even a modest temperature increase will make the leakage increase exponentially.

What about the one I chose : BAS40-04W,115

Around 1uA reverse current @ 3V, 85°C
Around 10nA reverse current @ 3V, 25°C

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

Well, these are good specs indeed. Of course that diode can't support a lot of forward current, but I guess that's not important in your application.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cedric Berenger wrote:

Edit 2: Maybe it is the way clocks are internally multiplexed: maybe an active clock will consume more if it is selected as main clock source, even if nothing use the main clock source.

 

I can believe that, as any clock tree represents capacitance.

If that is driven, even if the CORE/Peripherals do not use it, that can easily add a few uA - you can work out what capacitance the difference maps onto, using Power Dissipation Capacitance modeling.