ATtiny1616 - lowest sleep draw with a comparator on

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

Sanity check required!

 

My system is currently at 470uA / 0.5mA, of which 26uA is a boost chip and 11uA a FET controller. I'm willing to say another 50uA in losses elsewhere. That leaves 370uA by the ATtiny.

 

Config

WDT - 1uA
RTC PIT - 1uA
CMP LP - 45uA
32KHz CPU in idle - 8.2uA
VREF 2.5V - unknown uA
Everything else - disabled

 

All pins have PORT_ISC_INPUT_DISABLE_gc, low output except CMP input pin.

 

The comparator won't trigger interrupts unless the CPU is in idle (errata bug), so I change the CPU_PER to 32KHz to shutdown the 20MHz. I use the comparator to count low frequency pulses then every half second the RTC fires and I do some basic logic to ascertain whether sleep should continue.
 

ISR(MOTION_ZEROCROSS_INT_VECT) {

    count++;
    HW_CMP_INT_RESET(MOTION_CMP);
}

inline void MOTION_Task (void) {

    if (transfer) {
        motion.hz = count;
        count = 0;
        transfer = 0;
    } else {
        transfer = 1;
    }

    if (motion.riding) {
         if (motion.hz < MOTION_MOVING_HZ) {
            myTicks++;
            if (myTicks == MOTION_DETECTED_TICKS) {
                motion.riding = 0;
                myTicks = 0;
            }
         } else {
             myTicks = 0;
         }
    } else {
         if (motion.hz > MOTION_MOVING_HZ) {
            myTicks++;
            if (myTicks == MOTION_DETECTED_TICKS) {
                motion.riding = 1;
                myTicks = 0;
            }
         } else {
             myTicks = 0;
         }
     }
}

ISR(TASKER_TIMER_INT_VECTOR) {
    
    TASKER_INT_DISABLE;
}

Within main()...

        #ifndef __DEBUG
        _delay_us(1); // allow 20MHz async peripherals to update before switching clock
        _PROTECTED_WRITE(CLKCTRL.MCLKCTRLA,CLKCTRL.MCLKCTRLA | CLKCTRL_CLKSEL_OSCULP32K_gc);
        #endif        

        while(1) {
            sleep_cpu();
            if (TASKER_TRIGGERED) {
                wdt_reset();
                TASKER_RESET;
                TASKER_INT_ENABLE;
                MOTION_Task();
                if (motion.riding) {
                    break;
                }
            }
        }

So I have about 300uA of unknown loss. Anything less obvious, like do some peripherals consume power when disabled due to having a particular clock setting?

 

Hints and tips appreciated!

 

Last Edited: Sat. Jul 23, 2022 - 07:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All pins have PORT_ISC_INPUT_DISABLE_gc, low output except CMP input pin.

That would be a good place to start- you want analog pins to have their digital inputs disabled. Check out the PORT diagram in the datasheet to how analog pins route.

 

Other than that, work you way up in code- start with a baseline power usage as low as you can get and add code/measure. All pins disconnected, all pins input disable, power down sleep, measure, you should be close to what the datasheet says for power down. Work your way up from there to get power values associated with code changes.

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

Debugger Atmel-ICE usualy takes about 300uA if connected. Didn't you forget disconnect that ?

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

11uA a FET controller

 

The fet gate switching will use a "lot" of power.

 

How much waste is in the Voltage regulator, is used.

 

try pulling out the AVR---verify how much of the total is AVR related.

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

curtvm -> PORT_ISC_INPUT_DISABLE_gc is already enabled for all
gripennn -> The debugger is disconnected
avrcandies -> it does, 5mA, but 11uA is with it in sleep mode

I've already set the clk to TCD to clksys, another thread discussed this peripheral consuming a bit of power when off.

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

Like avrcandies wrote. Verify if the current is being drawn by the mcu or surrounding circuits. 
Another hint. TCD can force internal 20M oscillator to run. Try to completly disable TCD to see if it is source of your problem.

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

Now, the below will need to be adapted for e.g. the sleep modes for your chosen model.  But my proven method over the years, which is indeed a

snoopy33 wrote:
Sanity check
, boils down to

https://www.avrfreaks.net/forum/...

theusch wrote:

1)  Let's see the complete test program.

2)  Tell all connections.  In particular, are you still connected to the programmer?  Is debugWire active?

3)  For Cliff:  IME/IMO the best/right? way to look for those last uA and perhaps nA is to have minimum connections -- bare board and CPU.  Start up and run active for some seconds, enough to get a reading on Active current draw.  Then set up for deep sleep, and go to sleep with the fishes forever.  The above will give you real baseline values as various external subsystems are added.  Add one, rinse, and repeat above tests.

4)  And the regulator is a good question.

5)  The CLKPR sequence may not be valid, depending on optimization levels and the phase of the moon.

6)  Check docs on PRR.  Are any subsystems active by default, such as analog comparator?

 

As you are finding, you are guessing as to the source of the current draw.  After fighting this a few times, pulling off subsystems, I and my outfit found it much easier to start bare with the highlighted sanity check program.  If you can't meet those datasheet numbers then any further work will cause nothing but hair-pulling.  (member js did this too many times, as the avatar shows)

 

Another thread, with links to similar prior discussions:

https://www.avrfreaks.net/forum/...

 

Once you've done the sanity check and have indeed verified that it is the FET circuit that is causing the issue(s), then the sparkies can help.  As it is, your hound dog may be concentrating on a tree with no raccoons.

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, I did just that then came back here to report findings and see you recommended that.

So apart from switching off input buffer on all pins...

 

    #ifdef TEST_CURRENT
        _PROTECTED_WRITE(CLKCTRL.MCLKCTRLB, 0);
        _PROTECTED_WRITE(CLKCTRL.MCLKCTRLA,CLKCTRL.MCLKCTRLA | CLKCTRL_CLKSEL_OSCULP32K_gc);
        PWM_TIMER.CTRLA = TCD_CLKSEL_SYSCLK_gc;
        #ifdef TEST_CURRENT_POWERDOWN
        SLPCTRL_CTRLA = SLPCTRL_SEN_bm | SLEEP_MODE_PWR_DOWN;
        #endif
        #ifdef TEST_CURRENT_IDLE
        SLPCTRL_CTRLA = SLPCTRL_SEN_bm | SLEEP_MODE_IDLE;
        #endif
        sleep_cpu();
    #endif

I get ~206uA in Idle and PowerDown

In Idle with the 32KHz RC, RTC, 1x CMP in LP and VReg running (my minimum system requirements) it's 367uA

According to the datasheet the difference should be 55uA, excluding the vReg which is an unknown. 

 

Last Edited: Tue. Jul 26, 2022 - 03:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

excluding the vReg which is an unknown. 

Turn it off, then on...then you will know approx how much it draws 

 

by Voltage regulator, do you actually mean the internal AVR voltage reference???

 

You have neglected to supply a schematic of what you have...one resistor can sink the entire ship.

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

I can't post the schematic unfortunately but I can assure it's not resistors. I do have some leakage through low value zeners to look at.

My target is 200uA and I'm there by using PORT interrupt instead of CMP. I may switch to CMP after the wakeup if there's problems but so far so good. The internal vref is a power hog.

However there appears to be undocumented errata also around vref. Once requested by a CMP shutting down the CMP keeps the vref running. 

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

Once requested by a CMP shutting down the CMP keeps the vref running. 

That makes sense, since it prob just simplistically ensures the Vref enable bit is set.  You must shut down the things you want to turn off.

 

Did you ever try just turning on only Vref and turning it off?  What readings do you get?

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

No Vref is automatically requested by the CMP. It can be forced on to reduce startup time but not forced off.

And unfortunately once it's spun up it doesn't want to power down (bug). So far a software Reset will work to do it, which is possible in my case.

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

I'm MCU complete, that Vref not 'derequesting' is definitely an undocumented bug but I'm resetting to work round it. At 200uA. Circuit optimisation now but reckon ~100uA is in sight. yes

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

Did you ever try just turning on only Vref and turning it off?  What readings do you get?

 

You have the ability to do so using the ref control bits & not turning on other stuff (which will override your on/off).

 

As an aside, maybe there is a bug in the comparator, if it does not derequest, if the datasheet indicates it should.

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

Vref can be forced on or put in auto request mode but with the comparator disabled and the vref forced it is about 80uA. The other ~50uA being the comparator current.

80uA is about standard, the LM4040 has a minimum rating of 45uA.