Low Power "Green" Battery Operation Solutions For The Teensy 3.

Status
Not open for further replies.

t3andy

Well-known member
Low Power "Green" Battery Operation Solutions For The Teensy 3.

The ARM Teensy 3 idles at a whopping 27 ma. !!!! :(
Note: A power hungry precision "fixed" crystal is used on the Teensy 3 which makes it easy
for Paul to port all the Arduino libraries to the Teensy 3 easily. Having a PLL or variable speed internal trimmed clock would be like a "nightmare on elm street" for software development.

We looked at several of the following solutions to reduce the power consumption of the Teensy 3:

#1. RTOS (Realtime Operating Systems). Having an "easy to use" RTOS that merges the Arduino commands on
the Teensy 3 would be perfect but would be somewhat hard to implement "correctly" on the Teensy 3. The RTOS would reduce the "average" power consumed down to manageable levels by using sleep command for delays. This solution is a "work in progress" by PJRC.

http://forum.pjrc.com/threads/23438...ensyduino-code-compatible?highlight=low+power

#2. Creating Teensy 3 commands "sleep" by shutting down the CPU and "deep sleep" by allowing an external interrupt to wake up the Teensy 3. (Commands not implemented to date - part of PJRC "work in progress" above in solution #1)

http://forum.pjrc.com/threads/17285-Teensy-3-0-LowPower-examples-don-t-work!?highlight=low+power


Since neither solution #1 nor #2 has been provided to date then the only other solution would be to have a very low power microcontroller to enable supply power by using low power mosfets to the Teensy 3. A very good design reference application that uses this same design solution is provided by Sparkfun. (Wake-on-shake)

https://www.sparkfun.com/products/11447


Any comments please do chime in for a better solution.
 
Last edited:
I agree that a low power solution is vital for a lot of applications. I've used the Low Power Timer to wake up the Teensy from LLS sleep mode but still saw 6.5mA consumption which leads me to believe a. I did not go into LLS sleep mode correctly or b. other circuitry is causing the excess consumption. Probably a little of both. I have been writing a library for this but have shifted my focus to turning off modules and lowering the core,bus and flash clocks for reduce RUN mode average current. I'll post what I have once I get it cleaned up.
 
ok, so here is what i have for low power so far. its a library that can put the teensy3 into three different low power states. the three functions for this are (Low-Power)Run, DeepSleep and Hibernate. i've included examples of all these functions plus an example of using the Low Power Timer which is used as one of the wakeup sources. the library is fairly well documented i think so you can go through and see what i'm doing. this is just a beta release and IS NOT INTENDED FOR PRIME TIME! but i thought maybe this community could help find bugs if you choose to try this out. there are two major issue's thus far:

1. not being able program teensy3 automatically after going in to either sleep function. you must push the reset button on the teensy to program if you go into those modes. i really don't have clue why this is but hopefully someone can shed some light on this? its kind of annoying especially when debugging but it is what it is.

2. handling the usb while in any low power mode. if you write code that uses the serial monitor i've seen some issues with the teensy locking up with a hard fault. i'm thinking it has to do with pushing all the print data out of the usb before going to either sleep mode or low power run mode but i'm not totally sure, almost all the lockups seem to occur when using the usb print statements.

when going down this rabbit hole of low power i found myself editing core files and soon realized that this was not a very practical way to tackle this problem. i started this library for portability and tried my best to make it so no editing of the core files was necessary. i pretty much succeeded except for one edit to mk20dx128.c, you must add the following line of code: Add -> "PMC_REGSC |= 0x08;" just under "SCB_VTOR = 0;" in the "ResetHandler(void)" function. This allows the processor to release hold of the I/O when coming out of Hibernate because Hibernate wakes up through a reset. if anyone can figure out how to to add this to the library instead please let me know, i tried everything i could think of but no dice...

so you ask what about the actually power reductions, well i do see a reduction in power but i'm still seeing ~6.7mA draw while sleeping, powering Vin at 5V. after reading the mini54 data sheet it seems that this is almost the same current draw when running the min54 at 24MHZ, maybe paul can shed some light on this? one thing that would have to be done in my opinion is to leverage the mini54 sleep modes along with the teensy to get any practical long term battery powered application to be feasible.

so try it out and please let me know of any problems and solutions!

thanks,

duff
 

Attachments

  • LowPower_Teensy3_beta1.zip
    33.7 KB · Views: 464
@Duff

We commend your gallant effort on trying to reduce the power consumption on the Teensy 3!
If this was an easy task then it would have been done a long time ago!
Needless to say, due to Freescale's many, very complex, power consumption modes,
even attempting this power reduction Teensy 3 library task, we still commend you!!!!


References:

#1 K20P64M50SF0.pdf --> MK20DS128 Data sheet for Teensy 3 (electrical specs)
Under General / Nonswitching electrical Specifications /Power consumption operating behaviors.
Freescale lists 12 power modes.

#2 K20P64M50SForm.pdf --> Chapter 7: Power Management / power modes

---------------------
Questions for Duff
---------------------


Question #1

Could you clarifiy to avoid confusion, if possible, your three power modes to Freescale's terminology?
See chip power modes in chapter 7 Ref. #2 (above) "chip modes" eg "Normal Run", Normal Wait via WFI
and the power consumption operating behaviors Ref. #1 (above) "symbol" eg IDD_Run", IDD_Wait

(Low-Power)Run? DeepSleep? Hibernate?


Question #2
What is your mini54 data sheet? I don't see it on the PJRC website.

Question #3
What type of meter are you using to measure the current consumption?
 
Last edited:
hello t3andy,

here you go...

Q1: Could you clarifiy to avoid confusion, if possible, your three power modes to Freescale's terminology?
(Low-Power)Run - VLPR (Very Low Power Run)
DeepSleep - LLS (Low Leakage Stop)
Hibernate - VLLS3 (Very Low Leakage Stop3)

here is a doc that does much better job of explaining than i could here plus my figures hurt from the last post :) http://cache.freescale.com/files/32bit/doc/app_note/AN4503.pdf
also look in the library for smc.cpp in the utilities folder for detailed explanations.

did you look at the examples? they explain what modes also.


Q2: What is your mini54 data sheet? I don't see it on the PJRC website.
i didn't find it on pjrc website but its there also if search hard enough.
http://download.nuvoton.com/Nuvoton.../DocumentsInfo.aspx?tp_GUID=DA00-MINI51/52/54

Q3: What type of meter are you using to measure the current consumption?
well i don't have anything fancy, i just used my multi-meter and bench top power supply. my measurements seem to be in step with others when running at full power so i'm fairly confident you will see similar results with your tests when entering sleep and low power run modes.

i know it kind of dizzying trying to get a handle on all the low power options, so i hope this library can shed some light on a SIMPLE way to use these functionalities in peoples projects and my own!

duff
 
@Duff


\
Q2: What is your mini54 data sheet? I don't see it on the PJRC website.
i didn't find it on pjrc website but its there also if search hard enough.
http://download.nuvoton.com/NuvotonM...0-MINI51/52/54

Correct me, but the Teensy 3 Freescale Kinetis ARM Cortex M4 is different from the Nuvoton Cortex ARM M0:confused:
Does Freescale own Nuvoton:confused:

did you look at the examples? they explain what modes also.
We are still collecting and reviewing the docs and software.

Q3: What type of meter are you using to measure the current consumption?
well i don't have anything fancy, i just used my multi-meter and bench top power supply. my measurements seem to be in step with others when running at full power so i'm fairly confident you will see similar results with your tests when entering sleep and low power run modes.

The reason why I asked what type of meter you were using is that on some of the "older" Radio Shack meters, the current readings on the "low end" were faulty or read wrong.
 
Last edited:
ummm, i'm not sure if Freescale owns Nuvoton but they both use ARM Cortex chipsets. i'm going to say that they are different in the sense ARM doesn't build chips they just license the architecture to companies and they put their own instruction sets to access the functionalities of the chip. i'm in no way a expert on this but from what i've read this is my understanding of it. maybe someone could enlighten us on this?
 
both use ARM Cortex chipsets
But the main difference is M4 (more power) and M0 (less power)
All I am saying is you can't use the Nuvoton ARM M0 Mini54 doc for the Teensy 3 Freescale Kinetis ARM M4

BTW ... good job on the library, we will do some testing this weekend.
 
Last edited:
But the main difference is M4 (more power) and M0 (less power)
All I am saying is you can't use the Nuvoton ARM M0 Mini54 doc for the Teensy 3 Freescale Kinetis ARM M4

BTW ... good job on the library, we will do some testing this weekend.

He's referring to having no control over the power state of the Mini54 on the Teensy 3.0 board, and that the power consumption of the board when the K20 in a low power state corresponds to the power consumption documented on the Mini54 datasheet. Your reply is unnecessarily condescending.
 
All I am saying is you can't use the Nuvoton ARM M0 Mini54 doc for the Teensy 3 Freescale Kinetis ARM M4.

The Mini54 is the second chip on the Teensy 3 board, and is used as the bootloader/reprogrammer chip for the Kinetis chip (if I understood right): https://www.pjrc.com/teensy/schematic.html - that's what the Mini54 doc is being referenced for. The Mini54 chip isn't being sent into sleep mode by code running on the kinetis (I don't know if it's even possible for the kinetis to send code back to the Mini54 to change it's power state) - so its power draw remains unchanged when the kinetis chip goes to sleep.
 
I will work on a way for you to control the Mini54 power state. I'm currently at Maker Faire, and at least a few high priority things are queued up for next week, so I may not get to this for a couple weeks. Remind me.....
 
when going down this rabbit hole of low power i found myself editing core files and soon realized that this was not a very practical way to tackle this problem. i started this library for portability and tried my best to make it so no editing of the core files was necessary. i pretty much succeeded except for one edit to mk20dx128.c, you must add the following line of code: Add -> "PMC_REGSC |= 0x08;" just under "SCB_VTOR = 0;" in the "ResetHandler(void)" function. This allows the processor to release hold of the I/O when coming out of Hibernate because Hibernate wakes up through a reset. if anyone can figure out how to to add this to the library instead please let me know, i tried everything i could think of but no dice...

I am willing to add changes to the core library to support low power.

Version 1.14 is very close (very likely to release sometime next week), but I could consider adding small, very low-risk changes if necessay. When I get back on Tuesday, I'll look at this in more detail.

More substantial changes are possible, but likely for 1.15. I just want you to know the core library is flexible and I am willing to accept changes or make special additions to support low-power.
 
More substantial changes are possible, but likely for 1.15. I just want you to know the core library is flexible and I am willing to accept changes or make special additions to support low-power.

that would be great!!! i'm working on using the rtc as wakeup source also.
 
@Duff

-----------------------------
UUT: Teensy 3 -- Test Conditions
-----------------------------
Teensy 3 VIN BB jumper cut
VIN (pin 28) supplies input power (+5 VDc)
Micro USB supplies only USB +D -D (no input power)
Current meter used: Fluke 189 True RMS 50,000 count multimeter
Software: Beta 1.14 Arduino 1.04
Platform: PC Windows XP/SP3

-------------------------------------------------
Teensy 3 Active Mode Test:
Downloaded program: "blank.pde"
Teensy 3 active run (idle) current Is 19.29 ma. @ 24 Mhz <-------<<<<<
Teensy 3 active run (idle) current Is 25.18 ma. @ 48 Mhz <-------<<<<<
Teensy 3 active run (idle) current Is 31.68 ma. @ 96 Mhz <-------<<<<<
No connections are made to the Teensy 3
On board LED is off
Note: Higher freq = higher current consumption
-------------------------------------------------

-------------------------------------------------
Sleep Mode: Low Leakage Stop (LLS) mode - Deep Sleep
Downloaded program: DeepSleep_Simple @ 24 Mhz
Active current running : 23.31 ma.
Deep Sleep: 9.453 ma with LED pin 13 on
Deep Sleep: 6.512 ma with LED pin 13 off <---------------<<<<<
Note: Pin 13 onboard LED draws ~2-3 ma.! <-----<<<<
Note: Bootloader chip is not in deep sleep mode
-------------------------------------------------

----------------------------------------------------
Sleep Mode: Very Low Power Run Mode (VLPR)
Downloaded program: Low_Power_Run_Simple @ 24 Mhz
Setup IntervalTimer to toggle led every 50ms in Normal Run Mode = 23.13 ma
Go into Very Low Power Run Mode = 8.8 - 10 ma.
Reconfigure IntervalTimer period for 2MHZ clock = ~ 10.3 ma.
Move into Normal Run Mode. Clock now at F_CPU = 19.21 ma.
----------------------------------------------------

------------------------------------------------------
Sleep Mode: Very Low Leakage Stop (VLLS3) -- Hibernate
Downloaded program: Hibernate_Simple @ 24 Mhz
Hibernate current = 6.636 ma. <------<<<<<
Note: Installed reset handler patch
Note: Bootloader chip is not in hibernate mode
Note: Printing over USB when going into hibernate
keeps the current consumption at 12.566 ma. ???
Note: Disable USB printing will make hibernate work????
------------------------------------------------------

:cool:

BTW ... we came up with application ideas using the Sleep Library by Duff:

Between the three sleep modes Duff installed in his Sleep library, the most
useful, to us, would be the Deep Sleep or Low Leakage Stop (LLS). When the
bootloader offset (6.5 ma) is finally fixed, we believe the Teensy 3 could sleep in uamps
which would give years of battery life to the Teensy 3 at no load.

Two options to wake up the Teensy 3 from Deep Sleep would be a RTOS and an external, precision, low power, long duration timer. The first option would to use a RTOS in a event driven Teensyduino application would wake-up from Deep Sleep only when an event has occurred. This way, the "average" current is reduced by sleeping until an event happens. The other option is to used an interrupt from a long duration timer to wake-up the Teensy 3 from Deep Sleep. We found several low power timer IC's that will do this job. LTC6906, LTC6991, Max6369-Max6374 and TS3005. :cool:
 
Last edited:
------------------------------------------------------
Sleep Mode: Very Low Leakage Stop (VLLS3) -- Hibernate
Downloaded program: Hibernate_Simple @ 24 Mhz
Hibernate current = 6.636 ma. <------<<<<<
Note: Installed reset handler patch
Note: Bootloader chip is not in hibernate mode
Note: Printing over USB when going into hibernate
keeps the current consumption at 12.566 ma. ???
Note: Disable USB printing will make hibernate work????
------------------------------------------------------

i noticed this also where you see around 12mA in Hibernate, could have to with USB printing not sure, try putting in a delay after last print statement before Hibernate. i'm working on this.

Two options to wake up the Teensy 3 from Deep Sleep would be a RTOS and an external, precision, low power, long duration timer. The first option would to use a RTOS in a event driven Teensyduino application would wake-up from Deep Sleep only when an event has occurred. This way, the "average" current is reduced by sleeping until an event happens. The other option is to used an interrupt from a long duration timer to wake-up the Teensy 3 from Deep Sleep. We found several low power timer IC's that will do this job. LTC6906, LTC6991, Max6369-Max6374 and TS3005.*
i'm also working on using a rtc alarm as wakeup source for DeepSleep and Hibernate.
 
Paul -
I am willing to add changes to the core library to support low power.

Version 1.14 is very close (very likely to release sometime next week), but I could consider adding small, very low-risk changes if necessay. When I get back on Tuesday, I'll look at this in more detail.

More substantial changes are possible, but likely for 1.15. I just want you to know the core library is flexible and I am willing to accept changes or make special additions to support low-power.

one small change that i think is low risk would be to add to mk20dx128.h.
Code:
#define PMC_REGSC_ACKISO        (uint8_t)0x08
then add to mk20dx128.c.
Code:
    if (PMC_REGSC &  PMC_REGSC_ACKISO) PMC_REGSC |= PMC_REGSC_ACKISO; // release I/O hold
this what the freescale guys say
If the chip wake up from VLLS mode, it need to clear Regulator statu and control register (PMC_REGSC) [ACKISO] bit.
More detailed info, please refer below code as an reference:
// releases hold with ACKISO: Only has an effect if recovering from VLLS1, VLLS2, or VLLS3
// if ACKISO is set you must clear ackiso before calling pll_init
// or pll init hangs waiting for OSC to initialize
// if osc enabled in low power modes - enable it first before ack
// if I/O needs to be maintained without glitches enable outputs and modules first before ack.
if (PMC_REGSC & PMC_REGSC_ACKISO_MASK)
PMC_REGSC |= PMC_REGSC_ACKISO_MASK;
what do you think?
duff
 
hi paul,
looks good to me, i see that you also added in the System Mode Controller bits also, nice! i'm working on some cool low power options for the teensy and hope to be able to post it this week or next. i'm really glad i stumbled into world of teensy, congrats on such a cool product!
 
i was wondering paul if you have looked at putting the mini54 to sleep mode yet or have any ideas on how that would be accomplished? I see that teensy pin 18 and 19 are connected to the mini54 pin 7 and 8, so maybe we could use them to signal when we are going in and out of sleep mode, just a thought.

i've made some nice improvements to the library such as using the RTC, and TSI modules as wakeup sources and made it so you can configure multiple wakeup sources with multiple configurations. One vexing problem that i have still is programing the teensy without pushing the program button. I am able to do this by setting the USB voltage regulator in standby mode when going into either LLS or VLLS by setting the SIM_SOPT1 - USBSSTBY register and disabling the EZ port clock pin (PTA0) when going into sleep mode and reenabling (PTA0) when i come out. If i don't disable the EZ port clock when putting the the USB into standby mode it will go into the bootloader mode i think and reprogram the teensy instead of entering LLS or VLLS. but by disabling the EZ port clock you will not be able to reprogram either until i enable it again. If your using the library you will see what i mean if you add this to the setup function of your sketch and not disable EZ port clock. It works a few times but then wham... a reprogram event.
Code:
// allows write to SIM_SOPT1CFG USBSSTBY register
SIM_SOPT1CFG |= SIM_SOPT1CFG_USSWE_MASK;
// put usb regulator in standby mode in LLS & VLLS
SIM_SOPT1 |= SIM_SOPT1_USBSSTBY_MASK;
by putting the usb regulator into standby mode i see currents consumption of about 2.1mA which is nice improvement though.

i also recommend using the serial ports to debug when using this library so you don't have to keep opening and closing the IDE serial monitor. i'll post the update soon but wanted to see where paul was going with this before i did.

thanks,
duff
 
I can't promise a specific date. But I can tell you I have a first prototype for Teensy++ 3.0 on my desk right now. I'm going to be working on the mini54 stuff for it over the next few weeks. I haven't touched the mini54 much since Teensy3 was released, but it was originally intended to do this (and several other things.....)
 
i understand you have a lot on your plate, i'm just pushing this because my boss wants a low cost data logger to replace $1000+ campbell scientific data loggers we have at our field site. i might of bit of more than i can chew :)
 
Hi duff,
Great work on low power libraries. This is really very cool and helpful! I was looking for something like this, when I recently started with teensy 3.0 with something in minde that would be a low power but powerfull datalogger. So far, I did use the the functions to change from PEE to BLPI and back. I'm not sure if it is important, but I think in VLPR_PEE_BLPI() the divisor in line 27 on mcg.cpp <<MCG_C1 |= MCG_C1_FRDIV(3); // set FLL ref divider to 256>> should be MCG_C1 |= MCG_C1_FRDIV(4); to divide by 512 to end up with 31.25 khz?
 
Hi tba,
Thanks for looking into the code and catching this, yes it looks like I over looked that and i'll make the change on the new library that i have. I was waiting on how the mini54 will go into low power before releasing it, but maybe i could and just leave out putting the USB regulator into standby mode.

I did some reading on this and it looks like when you move to BLPI mode the FLL is disabled anyway so thats why it worked with the wrong divisor. The reference manual section 24.4.1.1 states:
Bypassed Low Power Internal (BLPI) mode is entered when all the following conditions occur:
• C1[CLKS] bits are written to 01
• C1[IREFS] bit is written to 1
• C6[PLLS] bit is written to 0
• C2[LP] bit is written to 1
In BLPI mode, MCGOUTCLK is derived from the internal reference clock. The FLL is disabled and PLL is disabled even if the C5[PLLCLKEN0] is set to 1.

The example code i was following i think just wanted to keep everything in spec but they where using a different crystal (8MHz) than the teensy (16MHz), my bad!

if your writing your own code to switch MCG modes, make sure you don't do any mode switching once in VLPR, this will lock it up. Do the the mode switching before hand. Thanks again and if you see any other glaring problems let me know.

duff
 
Status
Not open for further replies.
Back
Top