PDA

View Full Version : Low Power "Green" Battery Operation Solutions For The Teensy 3.



t3andy
05-08-2013, 12:04 AM
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-Wanted-very-easy-to-use-RTOS-Pwr-Management-Teensyduino-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.

duff
05-08-2013, 02:18 AM
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.

duff
05-16-2013, 02:24 PM
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

t3andy
05-16-2013, 07:21 PM
@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?

duff
05-16-2013, 11:20 PM
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/NuvotonMOSS/DownloadService/Member/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

t3andy
05-17-2013, 12:56 AM
@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.

duff
05-17-2013, 01:30 AM
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?

t3andy
05-17-2013, 01:38 AM
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.

adeptrc
05-17-2013, 02:49 AM
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.

Dawnmist
05-17-2013, 03:53 AM
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.

PaulStoffregen
05-17-2013, 06:21 AM
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.....

PaulStoffregen
05-17-2013, 04:40 PM
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.

duff
05-18-2013, 12:58 AM
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.

t3andy
05-19-2013, 09:56 PM
@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:

duff
05-21-2013, 02:19 AM
------------------------------------------------------
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.

linuxgeek
05-21-2013, 06:52 AM
i'm also working on using a rtc alarm as wakeup source for DeepSleep and Hibernate.

I very much hope you succeed in this. I imagine this is a commonly needed feature. I know I do.

duff
05-22-2013, 03:37 PM
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.
#define PMC_REGSC_ACKISO (uint8_t)0x08 then add to mk20dx128.c.
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

PaulStoffregen
05-22-2013, 06:03 PM
How's this look?

duff
05-22-2013, 11:10 PM
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!

duff
06-07-2013, 03:52 PM
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.


// 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

duff
06-08-2013, 04:20 PM
any ideas on how the mini54 will be put into low power?

PaulStoffregen
06-08-2013, 04:40 PM
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.....)

duff
06-08-2013, 05:59 PM
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 :)

tba
06-14-2013, 07:59 AM
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?

duff
06-14-2013, 04:56 PM
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

robostork
06-18-2013, 09:10 PM
I am working on a project using Teensy 3.0 that requires very low power consumption and the use of the RTC. When I use the library presented here, My RTC isn't keeping track of time well. Is there anything I can do?

duff
06-18-2013, 10:21 PM
i assume your using the time library? if so re-sync after sleeping "setSyncProvider(getTeensy3Time)", there is a issue with the time library and sleeping.

robostork
06-19-2013, 12:13 AM
That fixed it. I was also trying to use Arduino's RTC lib, which wasn't working well. Silly mistake. Thanks for the help.

tba
06-20-2013, 10:03 AM
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.
duff
Using the USB supply is what I'm doing at the moment...also I'm not sure if putting the mini54 into low power will work without some hardware changes?

I'm running the ADC in VLPR mode and put the results together with a timestamp (from millis()) to a SD card using the SD2Fat library. I reach sample times around 500 Hz but putting the data to the card using 512 Byte blocks takes around 24 ms each... The ADC is configured in the slowest mode, maybe this could be further optimized without the need of much more energy. I'm going to supply the teensy be batteries in a next step, also to measure the actual power consumption.

duff
06-20-2013, 03:00 PM
just remember that you are only running at 2MHz in VLPR mode, i'm not sure what you would have to do to optimize the ADC.

putting the USB regulator into standby mode doesn't effect powering the teensy through the USB.

duff
06-26-2013, 03:51 PM
i've been sitting on this for awhile so i thought i would just go ahead and post it. Added a struct so you can now have multiple wake sources for sleeping and added RTC Alarm and TSI as wake sources also. The GPIO wake pins have been defined as you will see in the examples so make sure you use them instead of just the pin number. Here is the list of changes:

ChangeLog Beta2:
1. Added struct to store sleep configurations
2. Added RTC Alarm wake
3. Added TSI wake
4. Put usb regulator in standby for VLPR
5. Got rid of stand alone LPTMR timer fucntions
6. Cleaned up the library and example codes
7. New examples added
8. Defined GPIO wake pin names

anyway hope its useful and let me know if there are any problems.

duff

627

t3andy
06-26-2013, 05:24 PM
@Duff ...
You brought the Teensy 3 power consumption, using your low power library, down from idle of 25.18 ma @ 48 Mhz to ~ 2.5 ma. or ~1000% or
~ 10 times !!!! :):):)

t3andy
07-02-2013, 12:21 AM
@Duff ...
You brought the Teensy 3 power consumption, using your low power library, down from idle of 25.18 ma @ 48 Mhz to ~ 2.5 ma. or ~1000% or
~ 10 times !!!! :):):)

Correction - sorry ... from 28.18 to 6.5 ma. There is still a Mini54 bootloader chip offset (~6.5 ma. ???) that still needs to be resolved???

Like others on this topic, I am also building a low power, high performance Teensy 3 uSD data logger. I found a AA battery powered step up
converter LTC3525-5, Adafruit's uSD breakout, Maxim-IC DS3234 +- 2 PPM precision RTC. By adding a CLI (command line interface) to the
software which executes functions with parameters, this data logger can be setup with any serial data terminal without IDE programming.

duff
07-02-2013, 03:48 PM
Like others on this topic, I am also building a low power, high performance Teensy 3 uSD data logger. I found a AA battery powered step up
converter LTC3525-5, Adafruit's uSD breakout, Maxim-IC DS3234 +- 2 PPM precision RTC. By adding a CLI (command line interface) to the
software which executes functions with parameters, this data logger can be setup with any serial data terminal without IDE programming.

sounds cool, are you building your own board for this?

PaulStoffregen
07-02-2013, 04:17 PM
There is still a Mini54 bootloader chip offset (~6.5 ma. ???) that still needs to be resolved???


I'm planning to work on this right after I fix the Mac bug.

t3andy
07-02-2013, 10:43 PM
sounds cool, are you building your own board for this? .

Yes, we are using the expensive ExpressPCB PCB board service. This is only after thoroughly bench testing the
electronic modules software with the Teensy 3.

What we found out is having two SPI devices eg SPI Adafruit uSD card and SPI RTC DS3234 don't
like to play with each other. It seems the sdFat library hogs the bus and plays havoc with the other chip
selects. <-----<<<< Look Out !!!! :(

http://forum.pjrc.com/threads/17288-Specifying-Teensy-3-0-Alternate-Pin-Functions?highlight=alternate+spi

We decided to nix the SPI DS3234 and drop back to the Maxim-Ic precision I2C DS3231 +- 2PPM or
the DS3232M+ +-5 PPM to provide a precision data logging timestamp.

The layout will include a 8 pin connector, on the bottom of the T3 "carrier board" to hold the Adafruit uSD
breakout board. Since Adafruit added a 3.3 V regulator and SPI noise reduction circuitry, we decided to keep
their breakout board as a plug-in for our data logger. Also, on the "carrier board" layout, will contain
the SCB70 SMT battery boost converter (LTC3525-5) and the precision SMT I2C RTC. The PCB size will be about
the same size as the Teensy 3, which will just plug into the carrier board.

Finding a command line interface (CLI) to run on the Teensy 3 took us a very long time to locate one.
This allows serial commands to setup the uSD and RTC without IDE programming.
http://www.freaklabs.org/index.php/Tutorials/Software/Tutorial-Using-CmdArduino.html

Any spares we make, one will always be reserved for the author of the Teensy 3 low power library. :cool:

Paul
08-07-2013, 10:20 AM
A beta version of the upcoming low power support is now ready for testing. Over the last week, duff and t3andy have already been testing this version. Things are looking pretty good so far...

Now I'm ready to open the beta test to anyone else who is interested in low power applications and has time to test over the next several days. Please email me directly: paul at pjrc dot com, if you're interested?

This new version reduces the MINI54 power consumption. Currently it draws about 6 mA in all conditions. This update reduces the MINI54's current to about 0.14 mA while not uploading code, but waiting for an auto-reboot request from the Arduino software. It also adds detection for the MK20 sleep modes. When the MK20 enters a sleep mode, so will the MINI54, reducing the MINI54's current to about 6 uA.

In this beta test, aside from verifying the power savings, the main thing we're testing is if the MINI54 always wakes back up properly. While in the 0.14 mA mode, it should be able to detect a reboot request (no need to press the button). Once it enters the deep 6 uA sleep mode, the only way to return to uploading is with a pushbutton press. In particular, this beta test is focused on attempting to discover any low power condition where the pushbutton fails to respond (in theory, no such condition is supposed to exist).

Again, please email me directly if you're able to help test over the next several days. Unless any bugs turn up, my goal is to publish this new version at Teensyduino 1.16 in about week, so please only contact me if you will have time to beta test within the next 5 days.

t3andy
08-07-2013, 08:29 PM
A major Teensy 3 development milestone has been accomplished --> low power / battery operation!
This opens up many new user low power (battery) applications for the Teensy 3.

The T3 low power "deep sleep" quiescent current consumption is now = ~ 250 uAmps <------<<<<<< (was ~ 6.5 ma.) (see notes below)

By fixing the Teensy 3 Mini54 bootloader current offset (Paul S), the "deep sleep" quiescent current depletion went from 14 days to 366 days !!!! (see notes below)
In other words, the T3 will "deep sleep" @ 250 uA quiescent current of battery power, using a booster converter, for about 1 year! (see notes below)

Using 2 2200 mAh AA battery(s) and a Teensy 3 - the "deep sleep" quiescent current depletion = 2,200 mA / 6.5 mA = ~ 14 days <--- previous current

Using 2 2200 mAh AA battery(s) and a Teensy 3 - the "deep sleep" quiescent current depletion = 2,200,000 uA / 250 uA = ~ 366 days <--- current now with fix


Note 1 - Using "Duff's" low power library beta 2
Note 2 - Very rough and crude AA battery depletion calculation - used only as rough estimate!!!! Expect very much lower depletion times due to battery(s) chemistry!
Note 3 - A standard AA Akaline battery(s) discharges at very non-linear rate - see manufacturer battery specs.
Note 4 - Does not take into account for the AA self discharge rate.
Note 5 - AA Alkaline battery discharge (depletion) voltage: 0.80 - 1.00 volts
Note 6 - AA battery total discharge voltage does not produce 100% current depletion!
Note 7 - Does not account for the AA booster converter quiescent current of ~ 20 uA.
Note 8 - T3 "deep sleep" has all pins as inputs or analog in, onboard status LED is off and all GPIO are NOT connected to anything.
Note 9 - Anything we forgot for current draw/consumption goes here. <----<<<< ????

Beta testing is still ongoing ....

PaulStoffregen
08-07-2013, 08:53 PM
Please understand this low power improvement is still in beta testing.

The beta test is now open to pretty much anyone with a Teensy3 and willingness to help test this week. Email me directly, paul at pjrc dot com if you'd like to participate.

I want to stress again, this is still "beta". Proper release is at least a week or two away, and obviously it may be farther if the beta tester discover any problems.

linuxgeek
08-08-2013, 04:25 AM
Sorry I don't have the time to get up to speed and test, but this is great news!

froeber
08-08-2013, 02:04 PM
Wow, What timely great news. I have a project that needs to use the T3 in a battery application and need it to be able to run in low power mode. In our case this was not only to preserve the battery but also because we run the T3 off the battery even when plugged into USB power with the battery being recharged by a LIPO battery charger IC. That charger IC never indicated "full charge" on the battery because of the residual current draw by the T3. Just thought I would mention this in case someone else runs into this.

Also, I typically do current measurements using my multimeter. But I recently bought a EEVblog uCurrent box to help do more accurate current measurements. I first heard about it in article by great author Jack Ganssle:
http://www.embedded.com/electronics-blogs/break-points/4406380/The--Current
There is a good article on why this device is useful, or more importantly some things to be careful of just using your mutlimeter for current measurement, at:
http://www.alternatezone.com/electronics/ucurrent/uCurrentArticle.pdf
In particular it tells how just measuring current wrong can cause your HW to act up due to voltage drops.

So, just wanted to pass along those notes. I'm going to go ahead and try to get into this beta test as the timing is perfect. This Teensy stuff is great.

t3andy
08-08-2013, 06:29 PM
@froeber
To confirm my numbers, please publish, on this board, your test measurements taken from your precision uCurrent box. :D

onoki
08-08-2013, 09:06 PM
I got the following measurements with the Mini54 update (116) and Duff's library (beta 2). My multimeter is not a top of the line, so the measurements may be off slightly.




Before the update (mA)
With the update (mA)


Normal run (RUN)
25
19


Low power run (VLPR)
9
2


Hibernate (VLLS3)
6
0.13


DeepSLeep (LLS)
6
0.13



According to the datasheet, there seems to be even lower power modes and the utility directory in the Duff's library seems to have the required functions to use them, but these Hibernate (VLLS3) and DeepSleep (LLS) modes are more than enough for me. Great work Paul and anyone else who made the Mini54 update.


During the next couple of days I will be testing out the "DeepSleep" or LLS mode with ChibiOS RTOS with a more complicated project.

froeber
08-09-2013, 11:46 AM
I have Paul's beta version and will be looking to test it. But I'm trying to set up code for the power mode I want/need to use (VLPS) based on Duff's excellent work. One thing I did note from the Errata sheet for the 1N86B revision of the MK20DX128VLH5 the T3 uses is that there are some errata that pertain to low power. One is "e4590 MCG: Transitioning from VLPS to VLPR low power modes while in BLPI clock mode is not supported." There are workarounds listed to go into RUN mode on exit from VLPS. Also, it anyone is using a debugger, there is errata "e3964 When debug is active a wakeup from STOP or VLPS with interrupt causes a hard fault interrupt." I'm not using debugger so no problem. Finally, errata "e4481: PMC: STOP mode recovery unstable" says to be careful using STOP mode for more than 50msec. They suggest using VLPS which is what I was planning anyways.

Along with Duff's note on there being a useful App Note 4503 for low power operation, I also found App Note 4470 on low power that has more of a focus just on the Kinetis processors we are using. What's nice is that there is a ZIP file with a LOTof support code for the low power demos they do. I found the App notes and other documentation at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=K20_50&fpsp=1&tab=Documentation_Tab. The link to get the ZIP file with the SW didn't work directly for me but trimming the link to http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4470SW.zip did work.

I'll post numbers on what I get for VLPS when I get it going (and as t3andy requested I'll indicate differences between measurements with straight multimeter vs the uCurrent product I got specialized for power measurements.

t3andy
08-09-2013, 01:05 PM
@Onoki

Normal run (RUN) 25 19 <--- Taken only at 48 mhz ? Other CPU speeds will vary --> higher speed = higher power consumption
Also deep sleep and hibernate seemed "switched" (250 uA for deep sleep)

PaulStoffregen
08-09-2013, 02:34 PM
The achieve the lowest power, one thing to consider is the configuration of pins 18 and 19. These 2 pins should be configured as INPUT_PULLUP or OUTPUT mode, or have a logic high or low externally applied.

By default, Teensy3 pins are disabled until you use pinMode() or they're configured for a peripheral. That's great for low power, since they can't draw current if the voltage on the pin is undefined.

However, pins 18 and 19 also connect to the Mini54 chip. Random floating voltage on those 2 pins can cause extra current consumption in the Mini54.

Just using pinMode(18, INPUT_PULLUP) and pinMode(19, INPUT_PULLUP), if those pins aren't connected to anything, will prevent any issue.

froeber
08-09-2013, 03:36 PM
@duff
I'm looking at the code in mcg.c for VLPR_PEE_BLPI(). At the end it "fixes" the SYSTICK rate. I think there is a problem with that code. In Paul's ResetHandler initialization code he set up SYST_RVR = (F_CPU / 1000) - 1 so that it generates 1 msec interrupts. I think all you need to do in your code is change it to SYST_RVR = (2000000 / 1000) - 1 since in BLPI mode you are running at 2 MHz.

t3andy
08-09-2013, 06:55 PM
@Paul S
Speaking of low power ...
Using the Teensy 3 SPI with low power is OK but could you put a solder-bridge jumper on the Teensy's 3 on-board LED so it could be configured to be enabled or disabled? It draws a whooping 2-3 ma. of un-necessary power when using SPI (uSD / sdFat) I hate to remove this LED everytime for low power.

onoki
08-09-2013, 07:08 PM
Taken only at 48 mhz ? Other CPU speeds will vary ... Also deep sleep and hibernate seemed "switched"
Yes, at 48 MHz. I probably should have mentioned that. I also measured the currents again. There must have been a mistake yesterday. Now it seems to be the same on both modes.

t3andy
08-09-2013, 07:24 PM
@onoki
This is what I got from our logger project ..
.

Low power
Teensy 3 Active Mode Test:

Before software bootloader change ...
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

After software bootloader change ...
Downloaded program: "blank.pde"
Teensy 3 active run (idle) current Is 13.07 ma. @ 24 Mhz <-------<<<<<
Teensy 3 active run (idle) current Is 18.8 ma. @ 48 Mhz <-------<<<<<
Teensy 3 active run (idle) current Is 25.4 ma. @ 96 Mhz <-------<<<<<
No connections are made to the Teensy 3
On board LED is off
Note: Higher freq = higher current consumption

The T3 low power "deep sleep" quiescent current consumption = ~ 250 uAmps <------<<<<<< (was ~ 6.5 ma.)

The Teensy 3 "only" current consumption dropped by ~ 6.5 - 0.25 in all speed modes. See above blank idle current readings.

PaulStoffregen
08-09-2013, 09:02 PM
could you put a solder-bridge jumper on the Teensy's 3 on-board LED so it could be configured to be enabled or disabled?

That's a great idea, but I don't see where it could possibly fit?

There's a tiny bit of space between the resistor and the RESET pad, but it's just barely the size of a 0402 resistor, without even the required clearance to the nearby stuff. If a pair of pads were crammed in there, they'd end up bring far too small for any reasonable trace cut and resolder with reasonable tools. There's also a via in that area which connects pin 14 through to layer 3, where it routes horizontally under the pushbutton, avoiding the unrouteable region on the bottom side with the 14 SMT pads and vertical traces.

onoki
08-10-2013, 08:08 PM
In particular, this beta test is focused on attempting to discover any low power condition where the pushbutton fails to respond (in theory, no such condition is supposed to exist).

I have now developed my current project with the beta version for two days (probably total of 12 hours or so). The pushbutton (and Teensy 3.0 overall) has worked without any problems.


The achieve the lowest power, one thing to consider is the configuration of pins 18 and 19. ... using pinMode(18, INPUT_PULLUP) and pinMode(19, INPUT_PULLUP), will prevent any issue

Just for fun, I tried the VLLS0 low power mode, which is supposed to be the lowest one. I also configured the pins 18 and 19 as instructed. The result according to my multimeter (again, not a top quality one) was:



Settings
Current (uA)


VLLS3 (Duff's Hibernate), no changes to pins 18 & 19
132


VLLS0, pins 18 & 19 configured as INPUT_PULLUP
130



The difference is so small that it could be just the multimeter. But then again, this is actually what the datasheet suggests (1 uA of difference when using VLLS0 instead of VLLS3).

In any case, I had no problems with the beta.

froeber
08-10-2013, 11:56 PM
So, I've been having a problem today with trying to get VLPS mode running. And, in the process I got things into a state where I couldn't easily get a new program to load. Note, I have not yet switched to the 1.16 beta Paul provided with the MIN54 power changes. But, I am pretty sure my problem would happen regardless. (I want to get my low power code working before I switch so I can check the before and after power draw.)

The issue is that when the processor is in VLPS mode (as well as most other low power modes) the internal regulator that drives the 3.3V output is in a low power mode. In that mode it can only supply 3mA vs the normal 100mA. The MIN54 is powered off that 3.3V line. With our SW the processor stays in VLPS mode even when USB is plugged in. But probably the biggest thing is that we have cut the Vusb trace and run Vusb to a battery charger chip that feeds a Lithium battery. The lithium battery is fed in as Vin to the T3 board. Thus, even when the USB is plugged in, the Vin voltage can be low (and certainly always lower than the USB 5V level).

What is happening is that the MIN54 current draw is dropping the V3.3 voltage low enough that the MIN54 can't run and therefor can't boot. If I wake the processor back up so the regulator can supply full current then it seems to work.

So, I'm not saying this is a T3 problem or a bug in Paul's code at all. I'm just noting that it is possible to write user SW supporting low power operation for the T3 and modify the use of the power connections in such a way that booting can be hard. This is just a word of warning to others messing with the use of the T3 and low power modes to be aware that there is a potential problem area.

I still am having trouble with VLPS mode but at least I now understand why I was having a rebooting problem ;-).

duff
08-11-2013, 08:33 AM
@duff
I'm looking at the code in mcg.c for VLPR_PEE_BLPI(). At the end it "fixes" the SYSTICK rate. I think there is a problem with that code. In Paul's ResetHandler initialization code he set up SYST_RVR = (F_CPU / 1000) - 1 so that it generates 1 msec interrupts. I think all you need to do in your code is change it to SYST_RVR = (2000000 / 1000) - 1 since in BLPI mode you are running at 2 MHz.

if you look at the code thats what it comes out too also, i guess you mean just replace the the ifdef's with what you have would work also.


So, I've been having a problem today with trying to get VLPS mode running.

can you post the code for how you are going into and out of VLPS, i have not got any "STOP" modes working yet.

duff
08-11-2013, 08:38 AM
During the next couple of days I will be testing out the "DeepSleep" or LLS mode with ChibiOS RTOS with a more complicated project.


if you get this working please post!!!

froeber
08-11-2013, 09:43 AM
@duff
I guess I've been spending too much time poring over tech manuals. When I looked at your code to set SYST_RVR it just didn't look right. But, as you say, it yields the same results as if you just used one set of simple "no ifdef" code that set SYST_RVR = (2000000 / 1000) - 1 in your mcg.c utility code. There is one "bug" in your code though. You include an "#elif F_CPU == 2000000" case that uses the wrong divider. Not that I'm sure why that case is there since F_CPU of 2MHz isn't supported elsewhere. But that one case doesn't give the right result. Anyways, just think it would have been simpler to skip the ifdefs. But you did a lot of code and it's pretty nice.

As to STOP mode. Yes, when I get it working I'll certainly post it. Just fighting the fact that after going in and out of STOP once works I end up with the stopping process getting aborted (ie PMCTRL STOPA set) on later attempts. Gotta figure out how interrupt acknowledges work with the AWICS used in place of NVIC in STOP mode.

PaulStoffregen
08-11-2013, 02:39 PM
Yes, using the USB regulator standby mode is risky. I saw a board here go to about 2.5 volts, which was just barely enough to run.

With the 1.16-beta1 upgrade, the Mini54 should be consuming about 0.13 mA when not uploading, and about 2.5 mA during upload. At the beginning of an upload, it should reset the MK20. Can anyone verify if that reset always causes the MK20's regulator to go back into normal mode where it can provide 120 mA?

PaulStoffregen
08-11-2013, 02:43 PM
One other power consumption to consider is the USB attach resistor (inside the chip). It's supposed to be about 1.5k to 3.3 volts. On the host side, there are 15k pulldown resistors on both USB signals. The result is about 0.2 mA of current flowing through those resistors.

Of course, if the USB is disconnects, as it probably will be for most battery powered projects, then this current can't flow. But if you're measuring the current when connected to a USB port, this extra current might be included in measurement.

duff
08-11-2013, 02:51 PM
@duff
You include an "#elif F_CPU == 2000000" case that uses the wrong divider. Not that I'm sure why that case is there since F_CPU of 2MHz isn't supported elsewhere. But that one case doesn't give the right result. Anyways, just think it would have been simpler to skip the ifdefs. But you did a lot of code and it's pretty nice.
That was from some edits to the arduino IDE Arduino-IDE-mod (http://forum.pjrc.com/threads/23941-Arduino-IDE-mod?highlight=duff) i did to add 2MHz to the "CPU Speed". That code should not affect normal operation. You can just delete that line of code if you want.




As to STOP mode. Yes, when I get it working I'll certainly post it. Just fighting the fact that after going in and out of STOP once works I end up with the stopping process getting aborted (ie PMCTRL STOPA set) on later attempts. Gotta figure out how interrupt acknowledges work with the AWICS used in place of NVIC in STOP mode.
ok cool, had trouble with the normal stop modes. Sounds like you might be on the right track, I was only able to get it in stop mode while still in the setup function with no delay and was not able to use any awic interrupts to get it out of stop mode. I'll look at this again also.

duff

duff
08-11-2013, 03:02 PM
Yes, using the USB regulator standby mode is risky. I saw a board here go to about 2.5 volts, which was just barely enough to run.

With the 1.16-beta1 upgrade, the Mini54 should be consuming about 0.13 mA when not uploading, and about 2.5 mA during upload. At the beginning of an upload, it should reset the MK20. Can anyone verify if that reset always causes the MK20's regulator to go back into normal mode where it can provide 120 mA?
does this affect the operation of the min54 while the USB regulator is in standby mode? maybe i should just delete any reference to this so folks don't do anything catastrophic?

PaulStoffregen
08-11-2013, 03:37 PM
I would recommend making the regulator standby a special and "advanced" option in the library, if it's available at all. Standby mode is probably not ever a good idea with the original Mini54 that runs at 6 mA all the time. How well it works with the new code is still something we need to investigate....

duff
08-11-2013, 05:53 PM
i agree, i'll just remove the regulator stuff that until its better understood.

kam42
08-11-2013, 10:42 PM
Do you have an idea of how long it takes to wake up from low power modes, using an internal wakeup source? The MK20 ref has a statement saying that external wakeup sources take around 5 cycles of the LPO (1kHz) clock (3 for glitch filtering, 2 for sync), but don't mention that same time requirement for internal wakeups, say, from a timer.

Reason being, I'd be interested in playing around with very short sleep cycles in between data acquisition timesteps (~75 uS between). However, I'm doubtful it's possible as the time period is so short.

In any event, this is really a huge advancement for those of us running battery powered applications!

t3andy
08-11-2013, 11:03 PM
In any event, this is really a huge advancement for those of us running battery powered applications!

Now you see the light ... I totally agree 100%:cool:

froeber
08-11-2013, 11:51 PM
Do you have an idea of how long it takes to wake up from low power modes, using an internal wakeup source? The MK20 ref has a statement saying that external wakeup sources take around 5 cycles of the LPO (1kHz) clock (3 for glitch filtering, 2 for sync), but don't mention that same time requirement for internal wakeups, say, from a timer.

Reason being, I'd be interested in playing around with very short sleep cycles in between data acquisition timesteps (~75 uS between). However, I'm doubtful it's possible as the time period is so short.

Hi, App note 4503 section 9.1 and the associated table 1 show the latency getting out of different low power modes. Usually it's the interrupt latency (which they state is 12 cycles for a K device like we are using). Some modes add an extra 2 to 4 usec. So I still think it would be a win to go into low power mode for 75 usec. Depending on how long you stay awake (ie your duty cycle) you could see a big power savings.

On my last project a lot of what I was doing was data acquisition and I was able to use the DMA engine coupled to the ADC to grab the data with very little power impact. It was a different ARM Cortex processor but this one might have something similar. Just throwing out the suggestion because I was pretty amazed on that project by how smart these processors have become (if you can figure out how to make them work). I was able to stay in a "non run" state for grabbing the data with the ADC and DMA coordinating and then drop to even lower power mode in between.

froeber
08-13-2013, 01:11 PM
Paul, I am working on trying to get VLPS low power mode to work. I tried using code from Freescale MQX RTOS but it wasn't reliable. Now I'm using code from the App Note 4470. But I have run into one potential problem based on the Teensy 3 board design. The issue has to do with errata e4473 for the processor rev being used on the board. That errata says that you can't reliably run in low power mode with a 1 MHz Flash clock rate for processor chips produced before the 2nd week on 2012. Normally (ie with newer chips and according to processor documentation) a 1MHz Flash clock rate is the correct maximum rate for low power mode.

The Teensy 3 uses a 16MHz oscillator. All the Freescale boards using this chip have an 8 MHz oscillator. When their code sets up for low power operation they have code:
/* Reduce Flash clock to 1MHz- Currently commented out due to errata KINETIS50MHZ_1N86B-4473*/
//SIM_CLKDIV1 = SIM_CLKDIV1_OUTDIV1(1)|SIM_CLKDIV1_OUTDIV2(1)|SIM_ CLKDIV1_OUTDIV4(0x7);
/*Reduce Flash clock to 500KHz*/
SIM_CLKDIV1 = SIM_CLKDIV1_OUTDIV1(1)|SIM_CLKDIV1_OUTDIV2(1)|SIM_ CLKDIV1_OUTDIV4(0xF);

So, instead of using a "divide by 8" setting to get 1MHz Flash rate they use a "divide by 16" setting to get 500KHz. However, since we have a 16 MHz clock we need to use the "divide by 16" setting just to get the recommended 1MHz maximum. And there is no higher divider. So, if any of your boards are built with older processor chips they can't be set up to run reliably in low power mode. Only you know what dates are on the processors you have used. My board has a 1226 (2012 26th week) date code so is ok.

Since I can't do anything different, I'm writing code to use the 1MHz Flash rate and assume it will work on all the boards we use.

AverageGuy
08-13-2013, 07:12 PM
I don't have a 3 yet (on order) but is there enough room to install a 2 pin female header in place of the LED? That way you could unplug it.

PaulStoffregen
08-13-2013, 08:25 PM
is there enough room to install a 2 pin female header in place of the LED?

Probably not, unless it's a very tiny pair of pins!!

onoki
08-15-2013, 03:43 PM
@duff

Sorry for the wait. I wasn't looking at the forum for few days.


i have not got any "STOP" modes working yet.


"I will be testing out the "DeepSleep" or LLS mode with ChibiOS RTOS"

if you get this working please post!!!

What do you mean? I used the example code in your DeepSleep_Simple project and it works for me. The current consumption is as I mentioned earlier on this thread (page 2).

For the ChibiOS, I didn't check if there are some related "good practices" for low power sleep, but I just used DeepSleep from your example in the main (lowest priority) thread of my project. More precisely:

LP.DeepSleep(RTCA_WAKE, 5);

where LP is TEENSY3_LP and the RTC crystal is added to Teensy 3.0.

froeber
08-28-2013, 03:50 PM
Hi, has anyone gotten the Very Low Power Stop (VLPS) mode to work? I've been messing with this for about a week and having real trouble. Sometimes the code works and I can stop the processor with reduced power and then wake up due to an interrupt coming in. But much of the time I get a hard fault when the interrupt that should wake up the processor occurs. I can provide more details and expect to post the code when I get it working. But these problems are driving me crazy. Almost thinking there might be some bug in the processor. There are some processor errata related to stop mode (e4590, e4473, e4481, and e3964) but I didn't think I should be running into any of those the way my SW is set up.

duff
08-28-2013, 07:36 PM
Hi, has anyone gotten the Very Low Power Stop (VLPS) mode to work?

I too have been trying to get VLPS and Regular Stop modes working with limited success. I also noticed the current consumption is much higher ~3.5mA when i enter Stop or VLPS. Are you going into BLPE before going into Stop? The example code you posted has the mcu configured to BLPE before STOP or VLPS and the FLL at 16MHZ so I set the SIM_CLKDIV1 to run the FLL at 2MHZ core, 2MHZ bus, 1MHZ flash. This allowed me to enter Stop or VLPS and use a interrupt to come out of it but as soon as I go back into PEE mode it will not come out of Stop with the same interrupt it just hangs not sure if its in hard fault or not. Below is how I go into BLPE.



void pee_blpe(void) {
if (mcg_mode() != PEE) return;
// first move from PEE to PBE
MCG_C1 |= MCG_C1_CLKS(2); // select external reference clock as MCG_OUT

// Wait for clock status bits to update indicating clock has switched
while ((MCG_S & MCG_S_CLKST_MASK) != MCG_S_CLKST(2)) ;
MCG_C2 |= MCG_C2_LP; // set the LP bit to enter BLPI
SIM_CLKDIV1 = SIM_CLKDIV1_OUTDIV1(7)|SIM_CLKDIV1_OUTDIV2(7)|SIM_ CLKDIV1_OUTDIV4(0xF);
}


I'm thinking that VLPS is not very well supported on this processor also, plus the current is way to high to be useful.

froeber
08-28-2013, 08:36 PM
@duff said

I too have been trying to get VLPS and Regular Stop modes working with limited success. I also noticed the current consumption is much higher ~3.5mA when i enter Stop or VLPS. Are you going into BLPE before going into Stop? The example code you posted has the mcu configured to BLPE before STOP or VLPS and the FLL at 16MHZ so I set the SIM_CLKDIV1 to run the FLL at 2MHZ core, 2MHZ bus, 1MHZ flash. This allowed me to enter Stop or VLPS and use a interrupt to come out of it but as soon as I go back into PEE mode it will not come out of Stop with the same interrupt it just hangs not sure if its in hard fault or not. Below is how I go into BLPE.

So, I saw that processor errata e4481 said:

PMC: STOP mode recovery unstable
Description: Recovery from STOP mode is not guaranteed if STOP mode is used for a period of time longer
than 50ms.

They say use VLPS instead of STOP mode. Besides, the power use for STOP mode is supposed to be higher by a fair bit. So, I had been going into BLPE power mode first before going into VLPS but when that didn't work I switched to trying to just go from RUN into VLPS. It's supposed to work and seems to work about the same (ie works some of the time but then crashes). I haven't sorted out the power usage yet because I'm running the processor in a system with a lot of other stuff hooked up and until I get things running reliably I don't want to mess with the circuit. VLPS is supposed to only use about 500uA which I could tolerate. I did find that you have to turn off the SYSTICK clock before going low power or else the attempt to go into low power mode was almost always aborted by tick interrupts getting generated. Since the counter gets powered down in stop mode anyways, stopping it early didn't seem like a problem. I'm using the RTC for most of my timing and it keeps running in VLPS.

Using the lower power stop modes than VLPS means the processor goes through a reset when it starts back up. I didn't get a sense that people were doing all the special stuff to check for such a reset so they could preserve all their data and IO states to allow seamless operation across the power down periods. Maybe they are but having been through that stuff on other projects I thought I would try VLPS first since it avoids that issue. Then again, if VLPS doesn't work it isn't much good. I'm going to try checking things out a bit more. I'll post back details if I get it working.

duff
08-28-2013, 09:09 PM
I didn't think about the systick interrupt, good point.



Using the lower power stop modes than VLPS means the processor goes through a reset when it starts back up.


LLS mode is not from reset, for the measurement's I've taken it seems to put the Teensy into lowest current consumption state.

duff
08-28-2013, 09:51 PM
Hear is what I consider a stable release of the library. Look at readme file to see what has been fixed but everything will work the same. Let me know if anyone runs into any problems

Thx

froeber
08-29-2013, 02:00 PM
@duff, I think I am going to give up on VLPS mode and just use LLS. Like you reminded me, it exits via an interrupt so no big recovery effort. It's missing 1 or 2 wakeup sources I would have liked that VLPS has (like serial and USB input) but I think I can deal with that. Thanks for the advice.

I started mapping out my use of LLS and realized I had to change some of my pinouts to get the right connections to the limited set of wakeup pins that are usable. Then I checked your PIN definitions in Lowpower_Teensy3.h. They all looked good but I noticed you left out a few. There was the LED pin 13 (value 0x200) and then the "back side" pins 26 (0x1), 30 (0x800) and 33 (0x8). I'll be checking out the rest of the LLS code as I go to use it. Good effort!

djsz
08-30-2013, 12:26 PM
This library really is quite wonderful for simple low power mode switching--nice work!

One question: on my project I'd like to use low power run, but only when the device is being powered by an external battery (with 3v3 applied directly to the T3's 3v3 pin and not Vin) and not when powered on and connected to USB as a keyboard. Are there any API methods for detecting whether the device is connected via an active USB connection in setup{} before setting the appropriate power mode for that session? Or whether the T3 is being powered by external battery power vs VUSB (from either a computer or a USB power adapter)?

Thanks!

froeber
09-02-2013, 01:02 AM
One question: on my project I'd like to use low power run, but only when the device is being powered by an external battery (with 3v3 applied directly to the T3's 3v3 pin and not Vin) and not when powered on and connected to USB as a keyboard. Are there any API methods for detecting whether the device is connected via an active USB connection in setup{} before setting the appropriate power mode for that session? Or whether the T3 is being powered by external battery power vs VUSB (from either a computer or a USB power adapter)?


Since nobody else has replied I'll take a shot at mentioning some things. First, you can't hook a battery to the 3.3V pin. It's an output from the internal regulator. We too have a battery operated application that can be hooked up or not to USB. The way we have hooked it up (and the way I think it sort of has to be hooked up) is to cut the jumper on the T3 board between the Vusb and Vin pins. We then ran Vusb to a charger chip hooked to our battery. The battery output feeds into Vin. The 3.3V output drives a few 3.3 chips we have in our design.

To detect when the USB is connected we ran the Vusb also to a 33k ohm/56K ohm resistor divider and then hooked up the mid point to a digital input pin on the T3. When USB is connected that input will read as a digital high signal. When it isn't it will read low. We picked one of the digital inputs that can be used with the LLWU for this connection so plugging in the USB can wake up the processor, allowing us to change operation in that case.

There is a "USB Device Charger Detection" module built into the processor that is supposed to help detect a USB connection. But the reference manual says you have to know USB is hooked up before using that module. That seems sort of weird since one would think that, by its name, such a module would let you detect the act of the USB being plugged in. I'll investigate that module further once I get other things working but adding the Vusb hookup via a divider network was an easy enough addition.

djsz
09-02-2013, 01:13 PM
Thanks for this helpful response--I had a feeling that physically connecting VUSB to a pin and reading that was the way to go but wasn't sure if there was a software-only method I was missing.

I'm applying 3.3V in to the Teensy's 3.3V pin since I'm using an external step-up regulator (https://www.sparkfun.com/products/10967) (from 1x AA) that performs the same role as the LDO regulator from Vin to 3.3. So what I'm thinking is that, given this, I can monitor either Vin or VUSB using your method because any voltage that comes in from the 3.3V pin won't make it upstream to the inputs on the Teensy's on-board LDO regulator.

These should all be pretty straightforward things to verify with the multimeter, so I'll work on that sometime this week. Thanks again for the pointers!

t3andy
09-13-2013, 12:52 PM
Teensyduino 1.16 has been officially released.

http://www.pjrc.com/teensy/td_download.html

This version will update your Teensy 3.0 bootloader. The update lowers power consumption while not uploading, fixes problems with upload on Macintosh, and preserves the EEPROM data during uploads.


The update lowers power consumption while not uploading

:):):)

Roger Parkinson
09-25-2013, 06:49 AM
@froeber

I started mapping out my use of LLS and realized I had to change some of my pinouts to get the right connections to the limited set of wakeup pins that are usable. Then I checked your PIN definitions in Lowpower_Teensy3.h. They all looked good but I noticed you left out a few. There was the LED pin 13 (value 0x200) and then the "back side" pins 26 (0x1), 30 (0x800) and 33 (0x8). I'll be checking out the rest of the LLS code as I go to use it. Good effort!
Did you verify these? I'm interested in using pin 26 but it isn't working for me. I copied one of duff's deepsleep examples and it uses pin 22 and that works just fine. But shifting it to pin26 (0x1) makes it stop working.
And let me add thanks to @duff for the library.

froeber
09-25-2013, 11:53 AM
@Roger

Did you verify these? I'm interested in using pin 26 but it isn't working for me. I copied one of duff's deepsleep examples and it uses pin 22 and that works just fine. But shifting it to pin26 (0x1) makes it stop working.

Roger, You asked about checking out pin 26. I didn't check it out explicitly because we don't use any of those pins you have to solder to the bottom pads for. But I have no reason not to think it would work just like the others. I'm using LLS mode for low power in our app and it works great. I based my stuff of Duff's code but made some changes to get things to operate more the way I wanted. I have to say I was having trouble with getting the right wakeup behavior using the LLWU unit in the processor. Looking through lots of code including the App Note 4503 and 4470 that Duff based his stuff on as well as some other Freescale examples and their MQX RTOS low power code I realized that there wasn't a real clean way to set things up to get interrupts to work reliably with the wakeup code being used. And there were various Freescale forum posts on the issues. So I wrote up some code to do the setup a bit differently to allow easier configuration of different types of wakeup and to get interrupts working.

I'll attach a Zip file with the LLWU code I did. If using the LLS or VLLSx power down modes, you can use this code to configure wakeups. And you can set it up to do interrupts by passing the same interrupt handler to the llwu_configure_pin function as you use with attachInterrupt. I'm busy wrapping up our application code but the LLWU stuff has been working great and seems totally reliable now. Plus, we use 2 module and 6 pin wakeup sources with the pins having to trigger on different edges so having incremental setup works well.

I haven't put together any sort of example code but the code is heavily commented and so I hope can be figured out easily enough if someone wants to use it. An example of one of our pin configurations is:


/* We want to be able to wake up on an interrupt from the top button. The
* top button is "active low" so trigger on falling edge. Make sure we set
* up LLWU for correct digital pin.
*/
assert(SL_HW_PIN_TOP_BUTTON == 9);
attachInterrupt(SL_HW_PIN_TOP_BUTTON,
top_button_interrupt_handler, FALLING);
llwu_configure_pin(LLWU_PIN_9, LLWU_WAKEUP_FALLING,
top_button_interrupt_handler);

froeber
09-25-2013, 01:08 PM
In case anyone wanted to use the llwu code I posted earlier I thought I would provide the code we use for entering LLS mode as a sample of using the LLWU code. I should also mention that we only use LLS low power mode and not any of the VLLSx low power modes. So I haven't tested that code I posted with anything other than LLS operation. But since LLS mode seems like a nice low power mode to use in terms of getting pretty good power savings and easy wakeup and recovery, I thought it would still be worth posting in case it could help anyone else.

The code below shows where we enable the LLWU. The code has a "power_users" variable. That's a bit mask where each bit indicates a different reason that the code has to stay out of low power mode (for instance doing USB transfers or having an LCD backlight on that needs higher power than the regulator supplies in sleep mode). It was important to mask interrupts when going to sleep to avoid cases where some interrupt came in that indicated a need for high power operation right before we went to sleep and stayed asleep till something else woke us up.


/**
* This function enters LLS mode from run mode.
*
* This function causes the processor to go into a "low leakage stopped" state
* until some wakeup source monitored by the processor's LLWU module triggers
* and wakes up the processor. Upon wakeup, the processor returns to the normal
* "run" mode of operation.
*
* This code is loosely based on the Freescale App Note 4470 code that
* supports "low power" operation.
*/
static void
enter_lls_mode(void)
{
volatile uint8_t dummy_read __attribute__ ((unused));

ELOG(7, 1, "power enter_lls", ELOG_ALWAYS);

/* Always expect to be in PEE power mode when we start this function */
assert(mcg_mode_check() == MCG_MODE_PEE);

/* Make sure clock monitor is off so we don't get spurious reset */
MCG_C6 &= ~MCG_C6_CME0;

/* We want to finish all serial output and shut it down before stopping
* the processor since the UART is disabled in LLS mode.
*/
#ifdef SL_OPT_DEBUG
SL_DEBUG_PRINT("Z");
Serial1.end();
#endif

/* Disable JTAG TDO pin since it can cause problems entering LLS mode.
* This code is from the code for App Note 4470.
*/
PORTA_PCR2 = PORT_PCR_PE | PORT_PCR_PS;

/* Turn off the SYSTICK timer while we are stopped so that elapsed time
* interrupts don't happen. We had problems that these interrupts caused
* aborts from stop mode.
*/
SYST_CSR &= ~SYST_CSR_ENABLE;

/* Set the power mode control register (PMCTRL) STOPM field to select the
* LLS mode.
*/
SMC_PMCTRL = SMC_PMCTRL_STOPM(0x3);

/* Wait for write to complete to SMC before stopping core */
dummy_read = SMC_PMCTRL;

/* Set the SLEEPDEEP bit to enable deep sleep mode (STOP). We don't want
* other bits in register (eg SLEEPONEXIT) set.
*/
SCB_SCR = SCB_SCR_SLEEPDEEP;

/* We don't want to go to sleep if, since our last check, we have gotten
* an interrupt indicating that we shouldn't sleep. We do this check in a
* critical section coupled with going to sleep so we don't miss any
* interrupts.
*/
__disable_irq();
if (power_users == 0) {
llwu_enable();
/* WFI instruction will start entry into LLS mode */
ELOG(7, 2, "power WFI", ELOG_ALWAYS);
asm("WFI");
ELOG(7, 3, "power WFI done", ELOG_ALWAYS);
} else {
ELOG(7, 4, "power WFI skipped", ELOG_ALWAYS);
}
__enable_irq();

/* Start back up the serial port if needed. Note, output may not actually
* work right if we have to restore the clock settings until we get that
* done.
*/
#ifdef SL_OPT_DEBUG
Serial1.begin(SL_DEBUG_BAUD);
ELOG(7, 7, "power serial started back up", ELOG_ALWAYS);
#endif

/* When an interrupt occurs we wake up from LLS and come back to this
* point in Run mode. If we did got into LLS mode, we came back out of that
* mode via an interrupt to the LLWU that was handled by the wakeup_isr
* code in llwu.c. That code put us back to PEE power mode if we had gone
* into PBE mode while stopped. If we didn't successfully go into LLS mode
* then we should still be in PEE power mode but will have an "abort"
* signaled by the STOPA bit in the PMCTRL register.
*/
assert(mcg_mode_check() == MCG_MODE_PEE);

/* Turn back on external clock monitor */
MCG_C6 |= MCG_C6_CME0;

/* Reset the SysTick counter and enable it to start a new countdown cycle.
* We stopped it before going into LLS mode.
*/
// TODO we lose all sense of elapsed time doing this. Could do different
SYST_CVR = 0;
SYST_CSR |= SYST_CSR_ENABLE;

/* We should have gone into LLS mode and woken up on an interrupt.
* However, there could have been some issue starting LLS in which case
* an "abort" will be signaled by the STOPA bit in the PMCTRL register.
* For now we just display a different letter on the debug output to
* indicate the problem.
*/
SL_DEBUG_PRINTLN((SMC_PMCTRL & SMC_PMCTRL_STOPA) ? "A" : "N");
}

I figure I should mention that when I was first trying to get low power operation working using the nice code Duff supplied as a jumping off point I was running into issues where I wasn't properly going into low power operation but instead getting the WFI abort signal. This was with the large set of wakeup sources we are using and the many different processor HW modules we have active. That was what was making proper operation harder to get working. The code we use now doesn't have that problem with aborts. We have the debug printout on the last line above that shows whether the wakeup was a normal one or any immediate one due to aborts. We get reliable normal wakeups. I mention this because I found that all the Freescale code examples ignored whether the low power transition worked or was aborted. When the transition aborts you don't get the power savings you would expect but otherwise don't really notice any issues.

Roger Parkinson
09-26-2013, 05:05 AM
Heh. I need something a bit simpler, but thanks for coming back so fast. :)
My particular case only needs one pin for the wakeup, I don't need RTC or Touch or any of the other options. I figured I'd use one of the underneath pads 'cos I have something connected to all the others.
However, I found I was okay using pin 11. I only have one of the SD lines connected to that and it seems to share just fine. When I ground pin 11 I get the wakeup.
The requirement here is that my hand held (actually wrist mounted) device will go to sleep when there's no activity and wake up on a button press. So that's looking good using LLS
Worst case if I find the SD card doesn't work now (still checking that) I can move its connection to underneath.
Thanks again.

duff
09-26-2013, 02:43 PM
Heh. I need something a bit simpler, but thanks for coming back so fast. :)
My particular case only needs one pin for the wakeup, I don't need RTC or Touch or any of the other options. I figured I'd use one of the underneath pads 'cos I have something connected to all the others.
However, I found I was okay using pin 11. I only have one of the SD lines connected to that and it seems to share just fine. When I ground pin 11 I get the wakeup.
The requirement here is that my hand held (actually wrist mounted) device will go to sleep when there's no activity and wake up on a button press. So that's looking good using LLS
Worst case if I find the SD card doesn't work now (still checking that) I can move its connection to underneath.
Thanks again.

I'm planning on adding the rest of the digital pin wake ups when i get some time.

Roger Parkinson
09-26-2013, 08:38 PM
@duff: cool. Thanks again.

alexs
10-07-2013, 12:29 PM
I am having some problems using LLS mode and USB.
I want to operate from an external power source (battery), sample data at a rather slow rate (4-10Hz), and then save data to SD. In the time between samples, i want to put the mcu in LLS mode. As soon the usb cable is plugged in, the board is powerded by USB, woken up if sleeping and the data from SD is transfered to the connected PC. So far, sampling data, writing to SD, going to LLS mode, wakeup by LPTMR, and usb connection seem to work reliable. My problem right now is the USB data transfer. Once the T3 has gone to LLS mode and woken up again, my PC doesn't recognize the T3 ( it sees a device has been attached, but can't recognize it). I tried calling usb_init() after wakeup, but it doesn't help. I am bit lost here. I'd be gratefull for any hints.

duff
10-09-2013, 09:37 PM
I am having some problems using LLS mode and USB.
I want to operate from an external power source (battery), sample data at a rather slow rate (4-10Hz), and then save data to SD. In the time between samples, i want to put the mcu in LLS mode. As soon the usb cable is plugged in, the board is powerded by USB, woken up if sleeping and the data from SD is transfered to the connected PC.


So are you powering the teensy with a power supply and usb at the same time? If so, did you put in the diodes so current does not back flow to your computer? Not sure of your setup here.



Once the T3 has gone to LLS mode and woken up again, my PC doesn't recognize the T3 ( it sees a device has been attached, but can't recognize it). I tried calling usb_init() after wakeup, but it doesn't help. I am bit lost here.


Is this a windows computer, i use mac and have not noticed this problem before. You need to post more details like what device does it say it is when plugged back in preferably screen shots. Since i mostly use mac and linux I really don't know off hand what the problem would be if you use windows.

alexs
10-09-2013, 10:48 PM
I have diodes to separate external power source and usb power. When running from usb power, i don't switch into LLS mode, to be able to comunicate over usb. When usb is disconnected, i switch into LLS mode, wait for a timer interrupt from lptmr, do some adc reading, and switch back to LLS mode. When first started with a usb connection, the device is recognized by windows, and i am able to comunicate. Once i unplug usb and plug it in again, windows doesn't recognize the device. Error is something similar to "Unable to recognize USB device" (translated from memory, so this might not be accurate). There is no device listed in windows. I am not sure if this is really connected to the LLS mode, because i think, i saw similar behaviour with the blink sketch running (i will check that tomorrow).

alexs
10-14-2013, 10:22 PM
After having fixed my previously mentioned problems, LLS mode works fine. Now i am facing a new problem. I still see a offset of about 7 ma . I assume, this is the Mini54 as mentioned earlier. I am using software version 116. How can i check if the update was correct or if it is still running an earlier version ? Is this update without user interaction, or might i have missed something ?

froeber
10-16-2013, 01:17 AM
After having fixed my previously mentioned problems, LLS mode works fine. Now i am facing a new problem. I still see a offset of about 7 ma . I assume, this is the Mini54 as mentioned earlier. I am using software version 116. How can i check if the update was correct or if it is still running an earlier version ? Is this update without user interaction, or might i have missed something ?

Paul talked about how to check loader version in http://forum.pjrc.com/threads/23880-Teensyduino-1-15-Released. The 7ma certainly sounds like the Min54 is still running. I get .5mA in LLS mode but have other peripherals like an LCD screen running too.

You said you were doing analog sampling after coming out of LLS. So I assume you reinitialize the ADC each time you wake up? I found that code that saves the calibration data and restores it rather than running a whole new calibration cycle runs much faster in case you are worried about speed.

alexs
10-16-2013, 09:37 AM
I go my power consumption down to 1.2 mA. Source of power consumption wasn't the Mini54 as suspected, but the SD-Card adapter. I was supplying the adpater with 3.3V, and had the power regulator brigded. After taking the power regulator of the board, power consumption dropped by 5mA. I am still a bit of target, but for the prototypes, this will do. Once i have new boards (allready ordered), i'll do further tests.


You said you were doing analog sampling after coming out of LLS. So I assume you reinitialize the ADC each time you wake up? I found that code that saves the calibration data and restores it rather than running a whole new calibration cycle runs much faster in case you are worried about speed.
Speed is of no concern for me, as i only sample 4 times a second, most of the time, the board is sleeping. When exactly is recalibration needed ? During measurement, i have to switch between external and internal reference voltage. From the code i can see, adc gets recalibrated every time i switch reference.

PaulStoffregen
10-16-2013, 10:22 AM
Yes, switching the reference causes the analogRead code to recalibrate.

duff
02-25-2014, 03:44 PM
If any one wants to check out my latest beta code for the low power library you can view it on github here (https://github.com/duff2013/LowPower_Teensy3). I'm updating it currently so things might change but core functionality will remain the same. Some new features:

1. user callback function when waking from DeepSleep and Hibernate.
2. All DeepSleep and Hibernate pins now defined.
3. New Sleep function, users can now use any interrupt to exit from this mode. This function currently has no parameters but will probably change in the future.
4. Added Compare wakeup, this still needs configuration help so if anyone has experience with this help me out.
5. replaced Run function with CPU function, now users can choose from 2, 4, 8, 16 MHz. 2, 4 MHz are in VLPR mode and 8, 16 are not.
6. Added support for using HardwareSerial at 2,4,8,16 cpu MHz.
7. IntervalTimer to work at 2,4,8,16 with a edit to that library. Change private members to protected then un commit that class in LowPower library. If not must recalibrate manually the interval.

Since most of the core is configured for F_CPU, F_BUS, F_MEM i'm slowly trying to port over functions to work at slower clock speeds. Things like SPI, ADC and such are not trivial so these might be some time until they work as expected in slower clock speed so if you have any ideas to help let me know.

neilh20
03-18-2014, 06:08 PM
Hey duff, great to see the lib and thanks for publishing it.
I'm working through your methods and looking at the manual. I'd like to integrate low power into a simple event tasking system I'm creating -
https://github.com/neilh10/arduino/tree/master/teensy3/taskingSimple
https://github.com/neilh10/arduino/tree/master/libraries/sondeLib
http://forum.pjrc.com/threads/25278-Low-Power-with-Event-based-software-architecture-brainstorm

One thing I'm running into a problem with is how to pull your tree into an Arduino library.
https://github.com/duff2013/LowPower_Teensy3
Is it possible to describe how the above github should be pulled into an Arduino 1.x that has been updated for building Teensy31
The way I'm trying it isn't working.

I'm actually building in an Eclipse/CDT environment based on the Arduino 1.x/Teensy31 release 1.18. Eclipse is way more productive than the fast-to-install but simple Arduino. I've organized so that I can push it into the Arduino format easyly to be able to share it.

One of the issues in the MK20 architecture is that all the subsystems are tied into the SYS_CLK and it appears the first recommended way of dealing with low power is to change the clock to 2MHz, and then disable SYS_CLK, which impacts peripherals timings.
I had the same issues with the ATmega2560 when I implemented low power, and I solved that with a system wide advertisement of going into low power mode.
So I'm enjoying looking at what you've done and experimenting with integrating it into a larger model.
Have you any thoughts on being able to manage all the peripheral dependencies on the SYS_CLK?
thanks
Neil

duff
03-18-2014, 08:41 PM
One thing I'm running into a problem with is how to pull your tree into an Arduino library.
https://github.com/duff2013/LowPower_Teensy3
Is it possible to describe how the above github should be pulled into an Arduino 1.x that has been updated for building Teensy31
The way I'm trying it isn't working.

I just download the zip file and deleted the master part in the name, then install it in the libraries folder in arduino. As far as eclipse I don't know but maybe someone who reads this can help you with that.



One of the issues in the MK20 architecture is that all the subsystems are tied into the SYS_CLK and it appears the first recommended way of dealing with low power is to change the clock to 2MHz, and then disable SYS_CLK, which impacts peripherals timings.

What do you mean by the SYS_CLK? -->F_CPU clock.

I don't disable any clocks just reconfigure them for the reduced freq. You can disable peripheral's that you don't use though. This will help with overall current consumption.



Have you any thoughts on being able to manage all the peripheral dependencies on the SYS_CLK?

If you mean F_CPU, the real sticking point here is the teensy core is tied to F_CPU, F_BUS, F_MEM so peripheral's will not work right if you dynamically change the core's clock speeds. For an example look at how I reimplemented the Hardware Serial classes in the library for whatever cpu and bus speeds you are currently running. That is how I'm trying to solve this issue without editing the core.

Hope this helps,
duff

neilh20
03-18-2014, 09:42 PM
Thanks for the response. On the install I can't see what you mean by delete the Master.
So I've probably not got something set up right or doing a procedure wrong so I'll run through it, and any insights appreciated.

I have a Arduino 1.05-r2 updated Teensyduino 1.18.
That is downloaded and installed http://www.pjrc.com/teensy/td_download.html - teensyduino.exe that I renamed as teensyduinoV118.exe
On the Tools I have set - Tools -->Board-->Teensy3.1
And it works and I can download programs to the Teensy31 board and flash the LED etc.

I download your http://duff2013.github.io/LowPower_Teensy3/ as .zip
I unzip it into a directory (deleteing duff2013- as the library manager doesn't like the '-')
Arduino\libraries\LowPower_Teensy3
I start the Arduino IDE


and I open
File->Sketchbook->Libraries->LowPower_Teensy3-->LowPower_Simple-->Sleep_Simple
Then I press verify button and get the following errors: (and also for all T3LP examples)

Arduino: 1.0.5-r2 (Windows NT (unknown)), Board: "Teensy 3.1"
C:\Program Files\Arduino\hardware\tools\arm-none-eabi\bin\arm-none-eabi-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mcpu=cortex-m4 -DF_CPU=96000000 -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -mthumb -nostdlib -D__MK20DX256__ -DTEENSYDUINO=118 -fno-rtti -felide-constructors -std=gnu++0x -DUSB_SERIAL -DLAYOUT_US_ENGLISH -IC:\Program Files\Arduino\hardware\teensy\cores\teensy3 -IC:\Users\neilh77\Documents\Arduino\libraries\LowP ower_Teensy3 C:\Users\neilh77\AppData\Local\Temp\build761217234 4359111544.tmp\Sleep_Simple.cpp -o C:\Users\neilh77\AppData\Local\Temp\build761217234 4359111544.tmp\Sleep_Simple.cpp.o

In file included from Sleep_Simple.ino:13:0:
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h: In static member function 'static uint32_t TEENSY3_LP::micros()':
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:155:49: warning: no return statement in function returning non-void [-Wreturn-type]
In file included from C:\Program Files\Arduino\hardware\teensy\cores\teensy3/WProgram.h:35:0,
from C:\Program Files\Arduino\hardware\teensy\cores\teensy3/Arduino.h:1,
from C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:32,
from Sleep_Simple.ino:13:
C:\Program Files\Arduino\hardware\teensy\cores\teensy3/IntervalTimer.h: At global scope:
C:\Program Files\Arduino\hardware\teensy\cores\teensy3/IntervalTimer.h:33:25: error: 'typedef void (* IntervalTimer::ISR)()' is private
In file included from Sleep_Simple.ino:13:0:
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:165:16: error: within this context
In file included from C:\Program Files\Arduino\hardware\teensy\cores\teensy3/WProgram.h:35:0,
from C:\Program Files\Arduino\hardware\teensy\cores\teensy3/Arduino.h:1,
from C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:32,
from Sleep_Simple.ino:13:
C:\Program Files\Arduino\hardware\teensy\cores\teensy3/IntervalTimer.h: In member function 'bool IntervalTimer_LP::begin(IntervalTimer::ISR, unsigned int)':
C:\Program Files\Arduino\hardware\teensy\cores\teensy3/IntervalTimer.h:37:71: error: 'const uint32_t IntervalTimer::MAX_PERIOD' is private
In file included from Sleep_Simple.ino:13:0:
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:166:43: error: within this context
In file included from C:\Program Files\Arduino\hardware\teensy\cores\teensy3/WProgram.h:35:0,
from C:\Program Files\Arduino\hardware\teensy\cores\teensy3/Arduino.h:1,
from C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:32,
from Sleep_Simple.ino:13:
C:\Program Files\Arduino\hardware\teensy\cores\teensy3/IntervalTimer.h:37:71: error: 'const uint32_t IntervalTimer::MAX_PERIOD' is private
In file included from Sleep_Simple.ino:13:0:
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:166:43: error: within this context
In file included from C:\Program Files\Arduino\hardware\teensy\cores\teensy3/WProgram.h:35:0,
from C:\Program Files\Arduino\hardware\teensy\cores\teensy3/Arduino.h:1,
from C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:32,
from Sleep_Simple.ino:13:
C:\Program Files\Arduino\hardware\teensy\cores\teensy3/IntervalTimer.h:51:10: error: 'bool IntervalTimer::beginCycles(IntervalTimer::ISR, uint32_t)' is private
In file included from Sleep_Simple.ino:13:0:
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:168:16: error: within this context
In file included from C:\Program Files\Arduino\hardware\teensy\cores\teensy3/WProgram.h:35:0,
from C:\Program Files\Arduino\hardware\teensy\cores\teensy3/Arduino.h:1,
from C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:32,
from Sleep_Simple.ino:13:
C:\Program Files\Arduino\hardware\teensy\cores\teensy3/IntervalTimer.h:51:10: error: 'bool IntervalTimer::beginCycles(IntervalTimer::ISR, uint32_t)' is private
In file included from Sleep_Simple.ino:13:0:
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:168:44: error: within this context

duff
03-18-2014, 10:47 PM
Sorry i guess the version on github doesn't have the IntervalTimer_LP class commented out in the LowPower_Teensy3.h. Just delete or comment it out like so:



/*
class IntervalTimer_LP : public IntervalTimer {
private:
public:
bool begin(ISR newISR, unsigned int newPeriod) {
if (newPeriod == 0 || newPeriod > MAX_PERIOD) return false;
uint32_t newValue = (TEENSY3_LP::_cpu / 1000000) * newPeriod - 1;
return beginCycles(newISR, newValue);
}
};
*/


I'll fix this tonight!

neilh20
03-18-2014, 11:20 PM
Great - thats got it working.
I can get the DeepSleep_simple compiling/downloaded/working
Also compiles Sleep_Advanced,
and working through those examples.

However Hibernate_Simple throws
Arduino: 1.0.5-r2 (Windows NT (unknown)), Board: "Teensy 3.1"
C:\Program Files\Arduino\hardware\tools\arm-none-eabi\bin\arm-none-eabi-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mcpu=cortex-m4 -DF_CPU=96000000 -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -mthumb -nostdlib -D__MK20DX256__ -DTEENSYDUINO=118 -fno-rtti -felide-constructors -std=gnu++0x -DUSB_SERIAL -DLAYOUT_US_ENGLISH -IC:\Program Files\Arduino\hardware\teensy\cores\teensy3 -IC:\Users\neilh77\Documents\Arduino\libraries\LowP ower_Teensy3 C:\Users\neilh77\AppData\Local\Temp\build530413024 5006401437.tmp\Hibernate_Simple.cpp -o C:\Users\neilh77\AppData\Local\Temp\build530413024 5006401437.tmp\Hibernate_Simple.cpp.o

In file included from Hibernate_Simple.ino:15:0:
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h: In static member function 'static uint32_t TEENSY3_LP::micros()':
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:155:49: warning: no return statement in function returning non-void [-Wreturn-type]
Hibernate_Simple.ino: In function 'void setup()':
Hibernate_Simple:33: error: no matching function for call to 'TEENSY3_LP::PrintSRS()'
Hibernate_Simple.ino:33:15: note: candidate is:
In file included from Hibernate_Simple.ino:15:0:
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:152:10: note: void TEENSY3_LP::PrintSRS(Stream*)
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:152:10: note: candidate expects 1 argument, 0 provided

Hibernate_Advanced
Arduino: 1.0.5-r2 (Windows NT (unknown)), Board: "Teensy 3.1"
C:\Program Files\Arduino\hardware\tools\arm-none-eabi\bin\arm-none-eabi-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mcpu=cortex-m4 -DF_CPU=96000000 -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -mthumb -nostdlib -D__MK20DX256__ -DTEENSYDUINO=118 -fno-rtti -felide-constructors -std=gnu++0x -DUSB_SERIAL -DLAYOUT_US_ENGLISH -IC:\Program Files\Arduino\hardware\teensy\cores\teensy3 -IC:\Users\neilh77\Documents\Arduino\libraries\LowP ower_Teensy3 -IC:\Program Files\Arduino\libraries\Time -IC:\Program Files\Arduino\libraries\EEPROM C:\Users\neilh77\AppData\Local\Temp\build530413024 5006401437.tmp\Hibernate_Advanced.cpp -o C:\Users\neilh77\AppData\Local\Temp\build530413024 5006401437.tmp\Hibernate_Advanced.cpp.o

In file included from Hibernate_Advanced.ino:15:0:
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h: In static member function 'static uint32_t TEENSY3_LP::micros()':
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:155:49: warning: no return statement in function returning non-void [-Wreturn-type]
Hibernate_Advanced.ino: In function 'void sleep_config_1()':
Hibernate_Advanced:86: error: 'struct configSleep' has no member named 'callbackfunc'
Hibernate_Advanced.ino: In function 'void sleep_config_2()':
Hibernate_Advanced:110: error: 'struct configSleep' has no member named 'callbackfunc'
Hibernate_Advanced.ino: In function 'void sleep_config_3()':
Hibernate_Advanced:135: error: 'struct configSleep' has no member named 'callbackfunc'

DeepSleep_Advanced
Arduino: 1.0.5-r2 (Windows NT (unknown)), Board: "Teensy 3.1"
C:\Program Files\Arduino\hardware\tools\arm-none-eabi\bin\arm-none-eabi-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mcpu=cortex-m4 -DF_CPU=96000000 -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -mthumb -nostdlib -D__MK20DX256__ -DTEENSYDUINO=118 -fno-rtti -felide-constructors -std=gnu++0x -DUSB_SERIAL -DLAYOUT_US_ENGLISH -IC:\Program Files\Arduino\hardware\teensy\cores\teensy3 -IC:\Users\neilh77\Documents\Arduino\libraries\LowP ower_Teensy3 -IC:\Program Files\Arduino\libraries\Time C:\Users\neilh77\AppData\Local\Temp\build530413024 5006401437.tmp\DeepSleep_Advanced.cpp -o C:\Users\neilh77\AppData\Local\Temp\build530413024 5006401437.tmp\DeepSleep_Advanced.cpp.o

In file included from DeepSleep_Advanced.ino:12:0:
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h: In static member function 'static uint32_t TEENSY3_LP::micros()':
C:\Users\neilh77\Documents\Arduino\libraries\LowPo wer_Teensy3/LowPower_Teensy3.h:155:49: warning: no return statement in function returning non-void [-Wreturn-type]
DeepSleep_Advanced.ino: In function 'void sleep_config_1()':
DeepSleep_Advanced:59: error: 'struct configSleep' has no member named 'callbackfunc'
DeepSleep_Advanced.ino: In function 'void sleep_config_2()':
DeepSleep_Advanced:97: error: 'struct configSleep' has no member named 'callbackfunc'

duff
03-18-2014, 11:39 PM
Ya those examples are from an old version, I'll update them on github so they work but prolly will not happen until tomorrow. DeepSleep and Hibernate function exactly the same except Hibernate comes out of sleep mode through a reset where DeepSleep continues program flow after the call to DeepSleep.

or you could just download the last stable release here (http://forum.pjrc.com/threads/23660-Low-Power-quot-Green-quot-Battery-Operation-Solutions-For-The-Teensy-3?p=34871&viewfull=1#post34871).

doesitmatter
03-19-2014, 06:52 AM
Ya those examples are from an old version, I'll update them on github so they work but prolly will not happen until tomorrow. DeepSleep and Hibernate function exactly the same except Hibernate comes out of sleep mode through a reset where DeepSleep continues program flow after the call to DeepSleep.

or you could just download the last stable release here (http://forum.pjrc.com/threads/23660-Low-Power-quot-Green-quot-Battery-Operation-Solutions-For-The-Teensy-3?p=34871&viewfull=1#post34871).

Might be a good idea to tag your releases on github, so people can easily grab the stable or HEAD version as they prefer. Happy to help organize if I can, or work on additional features if a roadmap is documented so I know where to direct my efforts.

Thanks much for all your work on this I've been using the stable version in a couple of prototypes for the last few weeks and it's been exceptionally helpful.

duff
03-19-2014, 02:13 PM
Might be a good idea to tag your releases on github, so people can easily grab the stable or HEAD version as they prefer. Happy to help organize if I can, or work on additional features if a roadmap is documented so I know where to direct my efforts.

Thanks much for all your work on this I've been using the stable version in a couple of prototypes for the last few weeks and it's been exceptionally helpful.


Ya I know, I'm GitHub noob, so do you think I should have two versions on github? Not really sure what the protocol is for having different versions? I would still like to have the "bleeding edge" version along with a stable and proven version.

As far as a roadmap for future releases, I want to port over as many of the functionalities the teensy has to offer for reduced CPU, BUS and MEM speeds. I have got IntervalTimer (w/small mod to the core) and Hardware Serial's ported over and would like to get native SPI to work at reduced freq next. Also I'm working on speeding up going into and out of the various sleep modes and making them thread safe, I've been talking to kam42 (http://forum.pjrc.com/members/35613-kam42) about this, he helped me out with LowPower Timer also.:cool:

thanks,
duff

neilh20
03-19-2014, 04:09 PM
duff, really appreciate the postings on github.
Github is the magic place to share - and has made it so easy for sharing code like you are doing.
Usually its great to keep the "trunk" on the latest stable release - whatever that means to you - but it would be nice to have it mean its got some description about what is working.
For working/sharing in teams a branch is a really nice mechanism - usually something that compiles and some basic testing and the submission notes indicate what the push was about.
There is some discussion about a personal sandbox were all updates are pushed online, however personally, I work in stages - and when I'm satisfied with a specific stage I snapshot it locally with a zip. I only push it to the source control (github) when I'm happy with the code stability and comments.

I've had a look at your 2013/Aug reference and differenced it (I use WinMerge) with the latest on github and I like the latest on github as its referencing the latest teensy3 1.18 release.

In trying a modified DeepSleep_Simple / LLS mode I'm going from Vin=3.2V @31mA
with LPTMR_WAKE to somewhere between 1.2mA & 0.87mA when sleeping.
GPIO_WAKE --> stable 0.49mA
with RTCA_WAKE --> stable 0.57mA (but no 32KHz xtal)
Are these the type of readings you are getting?

I'm going to dig deeper into the peripherals turned on next.
In a past project before powering down I advertised to subsystems there was going to be a powerdown and they turned the peripheral off
I captured the state of the GPIOS
went to sleep
on wake up - restored the GPIOS, corrected for any clock issues
advertised the powerup to subsystems and they reinitialized the peripherals

cheers

duff
03-19-2014, 10:06 PM
In trying a modified DeepSleep_Simple / LLS mode I'm going from Vin=3.2V @31mA
with LPTMR_WAKE to somewhere between 1.2mA & 0.87mA when sleeping.
GPIO_WAKE --> stable 0.49mA
with RTCA_WAKE --> stable 0.57mA (but no 32KHz xtal)
Are these the type of readings you are getting?


Those are a little high, do you have anything connected to the Teensy that could be adding the extra power consumption? It should sleep at around 250uA. Also how are powering it? I see you are powering Vin at 3.2V, that is below the rated 5V that the Teensy regulator expects maybe this could be a problem, not sure. Also pin logic levels will only be as high as you power the Teensy, if you power it below 3.3V.

One thing I would be really interested in is if anyone that builds their own pcbs has measured the current consumption in sleep mode of the MK20 chip by itself or just minimal setup. The data sheets say it should sleep at something like 6uA in LLS sleep mode.

froeber
03-20-2014, 05:12 PM
Hi @duff, I've been away from power issues with my app for a while and doing things like adding Bluetooth LE. I'm still currently using LLS low power mode. But I found the watchdog wasn't working. I found a bug with Teensy code for the watchdog but those are covered over in http://forum.pjrc.com/threads/25370-Teensy-3-0-Watchdog-Timer. The problem I have is that watchdog just doesn't/won't work in LLS mode and I'd like the protection it provides. So I'm thinking of going back to looking at VLPS mode. That's what a Freescale engineer I've been working with suggested.

Back last fall when I was working on this you and I seemed to be having similar issues with not being able to get VLPS mode working well. I was just wondering if anything has changed for you with that mode?

Thanks for any thoughts. Fred

neilh20
03-20-2014, 05:38 PM
Well that is interesting.
The Teensy3.1 Vin says 3.7V to 5.5V and when I use the DeepSleep_simple and sleep setting on GPIO_WAKE and set the voltage (+/- 0.1V)
3.8V -->stable 0.17mA
3.6V -->stable 0.17mA
3.4V --> 0.17 -->0.522mA

So interesting. Current usage is hard to track, but looking at the specs,
Teensy 3.1 Vin is to MK20 USB regulator VREGIN rated 2.7 to 5.5V and the
MK20 VDD is rated for 1.71 to 3.6V
so it would look like other circuitry is contributing to the jump.
The Mini54Tan (as available on Digikey which references Nuvoton NuMicro Mini51) specifies its LDO Vcc 2.7- 5.5V and seems to operate on internal 1.8V
The device has a selectable BOD (brown-out-detect) at 3.8/2.7/2.0V(default 2.0V)
and Operating Current at 10KHz Internal reference ~100uA, however powerdown can go to ~10uA
So perhaps there is something with its BOD setting.

duff
03-20-2014, 06:59 PM
The problem I have is that watchdog just doesn't/won't work in LLS mode and I'd like the protection it provides. So I'm thinking of going back to looking at VLPS mode. That's what a Freescale engineer I've been working with suggested.

Back last fall when I was working on this you and I seemed to be having similar issues with not being able to get VLPS mode working well. I was just wondering if anything has changed for you with that mode?


No VLPS but how about VLPW? Look at my Sleep function, though it will disable the systick if that matters for the watchdog? I think you gave me that idea about the systick actually :D. I'm seeing current consumption around 800uA if I don't disable any peripherals.

Julien.bresciani
04-02-2014, 04:25 PM
Well that is interesting.
The Teensy3.1 Vin says 3.7V to 5.5V and when I use the DeepSleep_simple and sleep setting on GPIO_WAKE and set the voltage (+/- 0.1V)
3.8V -->stable 0.17mA
3.6V -->stable 0.17mA
3.4V --> 0.17 -->0.522mA

So interesting. Current usage is hard to track, but looking at the specs,
Teensy 3.1 Vin is to MK20 USB regulator VREGIN rated 2.7 to 5.5V and the
MK20 VDD is rated for 1.71 to 3.6V
so it would look like other circuitry is contributing to the jump.
The Mini54Tan (as available on Digikey which references Nuvoton NuMicro Mini51) specifies its LDO Vcc 2.7- 5.5V and seems to operate on internal 1.8V
The device has a selectable BOD (brown-out-detect) at 3.8/2.7/2.0V(default 2.0V)
and Operating Current at 10KHz Internal reference ~100uA, however powerdown can go to ~10uA
So perhaps there is something with its BOD setting.

Hi,

I m also trying to get the best from teensy3 low power,
I was able to get 0.130ma on LLS mode (deep sleep). the VLPS doesnt seem very helpful, with 0.280ma avg.
I ask myself why are we so far from what is specced in the datasheets :
Low leakage stop mode current at 3.0 V : @ –40 to 25C : 2.6 to 8.6 a.
there is at least a 10x factor.
I know some components might drain current on the board + maybe the design of the board itself leads to "electrons leaks :) " but I also suspect the mini54 to consume a lot of power.
Paul, Is there a method like a modified bootloader we could use to point out if the mini 54 is the guilty part ?
Is there any software way to communicate with the mini54 from the MK20 ?
Depending the average consumption of the mini54 but it might be a good idea on later designs to reserve an output on the MK20 to shutdown completely the Mini54 (through a transistor that will leak 10 times more than the mini54 consumes ?? :-D).

Do you think there is any chance to get closer to datasheet , lets say between 10 to 30 a in LLS mode with improving the software side or doing minor modification in the hardware ?

anyway, the teensy 3.1 coupled with hoperf RF22 is already a winners deal for low power mesh operations.

Massel
04-10-2014, 03:28 PM
Hi,
I 'm having troubles getting the Teensy 3.1 in LLS mode.
Shouldn't this small piece of code do the trick?

void loop() {
pinMode(2, INPUT_PULLUP);
LP.DeepSleep(GPIO_WAKE, PIN_2);
}

This line of code works:
LP.DeepSleep(LPTMR_WAKE, 5000);

But the GPIO_WAKE method doesn't work.
Am I missing something ?! Is there anything to do except setting the input as INPUT_PULLUP?
There is nothing connected to the PIN 2.

Thx

froeber
04-10-2014, 05:28 PM
@duff, I was going crazy trying to chase that low power issue I was having and posted about earlier. I tried your suggestion to use your VLPW code and found that it sometimes ran at about .8mA like you said right after download but if I unplugged and replugged in USB it went up to 3.5mA. After redoing my SW and HW to have just a Teensy 3.0 board with nothing connected but a serial=>USB board connected on UART0 for debug I found out that the problem was due to "back power" flowing in when in low power mode. The UART=>USB board propped up the voltage some on the GPIO pins and that ended up confusing the MIN54 to not go into a total low power mode.

Now, that was using TeensyDuino relelase 1.16 because I never upgraded to release 1.18 since I didn't see a reason to. Well I upgraded to 1.18 just to make sure I had the latest before reporting my findings and I found that the newer version of the MIN54 code that got loaded with that release made things work the way you suggested. I was sort of amazed (and also relieved). So that got me thinking about the connection to the MIN54 and what might be happening in low power. So I added code to make sure all the pins to the MIN54 were switched to Mux selection 0 (ie TSI input channels) vs their defaults (which for 4 of the pins are EZPORT connections). Amazingly I saw power drop by a factor of about 2. So my VLPW code dropped down to .4mA and my LLS code from .3mA to .15mA. All for just adding the code:

PORTA_PCR0 = PORT_PCR_MUX(0);
PORTA_PCR1 = PORT_PCR_MUX(0);
PORTA_PCR2 = PORT_PCR_MUX(0);
PORTA_PCR3 = PORT_PCR_MUX(0);

PORTB_PCR2 = PORT_PCR_MUX(0);
PORTB_PCR3 = PORT_PCR_MUX(0);
to my startup code.

So I just thought I would pass that along since I found your SW useful to give me ideas of different things to try in my hunt for my power problems.

Just for information I have found various interesting things along the way. So, one thing is that the Teensy board uses a 16MHz external crystal. All the Freescale boards use an 8MHz crystal. And if you look at the processor data sheet Table 14 you see that the faster crystal sucks 3x the power when it's running (.9mA vs .3mA). Doesn't affect things much in low power but it does when running. So, I'm not sure what advantage we get with a 16MHz crystal since it's divided down for almost every use. But it's what we have.

To see how power use was related to that crystal I tried changing my code to use a 32KHz crystal I have since I need the RTC and then ran in FEE mode (ie using the FLL vs PLL clock generator). That did cut a few mA out of my running power. Plus, since I only run F_CPU at 48MHz vs the 96MHz max I dropped the PLL/FLL output to 48MHz vs 96MHz to save some more power. I'm thinking I may take the time to change my code over to using FEE mode most of the time. The only time you need the PLL and PEE clock mode is if you want to use the USB interface since it needs the higher accuracy clock the PLL can generate. But if you are using USB then you have to be plugged in so power use isn't that big an issue.

Well, I mainly just wanted to thank you for your suggestion to try VLPW since that led me to find a solution to my problems after many other dead ends (I never even thought about the MIN54). Thanks. Fred

duff
04-11-2014, 07:30 AM
@froeber

Thats great, thanks for sharing!

duff

duff
04-11-2014, 07:33 AM
@Massel
that should work fine, are you driving PIN_2 to ground?

Massel
04-12-2014, 08:56 AM
Thx for the reply duff,

PIN 2 is not connected to anything.
Driving it to ground isn't working, too. (As I understand driving PIN 2 to ground will wake the Teensy up again!?)

I downloaded the lib 2 days ago. Any changes in this version regarding GPIO_WAKE?

One more thing.
I just saw that my Teensy 3.1 (the black version ;) ) is drawing 24.8mA in idle at 48 MHz.
In this thread I saw it should draw like 18.8mA idle at 48MHz, LED off. ?

Sry for these "simple" questions, I would use google, but this is the only thread about this topic ;)

tim_ui
04-22-2014, 06:57 PM
@duff or froeber, I am in need of a low power data logging option for temperature sensing using DS18B20 sensors in a streambed. This approach seems as though it would be ideal for me. Though, after so many posts, I am confused as to which files and parts to use. Could you please summarize for me the parts and method to getting the data logger operating?

duff
04-22-2014, 07:01 PM
@duff or froeber, I am in need of a low power data logging option for temperature sensing using DS18B20 sensors in a streambed. This approach seems as though it would be ideal for me. Though, after so many posts, I am confused as to which files and parts to use. Could you please summarize for me the parts and method to getting the data logger operating?

not sure what you are talking about in so far as "getting the data logger operating"? Do you mean how to put the teensy3 into low power?

tim_ui
04-22-2014, 11:13 PM
Sorry for being too vague. Yes, the part I need help with is getting the teensy3 into low power mode. What parts do I need and which program file is the best to use?

duff
04-22-2014, 11:59 PM
Sorry for being too vague. Yes, the part I need help with is getting the teensy3 into low power mode. What parts do I need and which program file is the best to use?


you can download my library and check out the examples: https://github.com/duff2013/LowPower_Teensy3

Or you can implement the various sleep modes yourself by looking at the library but if you just want something that works out of the box use the library. I'm assuming you know how to add libraries to arduino?

regards,
duff

christopherlarsen
04-28-2014, 02:07 AM
Duff,

Impressive work on this library!
I am trying to maintain USB communication with a Teensy 3.0, with reduced power consumption. My intent is to add diodes (when they arrive) to allow power from the USB, but for now the Teensy is battery powered by 3 AA cells. In the future, the meter will rarely be used with USB, so I desire to greatly improve the battery life, while maintaining the ability to connect via USB. The Teensy interfaces with a pulse output, once every few seconds from a flow meter - on pin 9. When the input pulse is received, I intend to use the real time clock to provide a time. I have a program that provides this functionality, but desire to reduce power consumption. I recently downloaded your library, and modified the basic sleep to accept an interrupt on pin 9. The program also produces text to confirm the operation. Serial printed text during setup is received, and is also received once, the first time that the interrupt occurs. After this first time, one can hear the computer confirmation that the port attaches and detaches. Even though serial communication is set up in this example program, it seems that USB cannot be used with sleep. Is this correct?

I have also tried the same using the Sleep_advanced program as a starting point. In this case, after uploading the program, the USB port is not accessible through serial monitor, the windows computer suggests there are no USB devices attached. Code to blink the onboard led indicates that the Teensy is operating, and accepting interrupt inputs as programmed . Is there some minor detail that I have missed in the code attached below? Is it possible to maintain a USB connection after sleep?

Arduino 1.05-r2, Teensy 1.18, Win 8.




************************************************** ********/
#include*<LowPower_Teensy3.h>



TEENSY3_LP LP = TEENSY3_LP();
//*allows*use*of*the*serial*port*at*speeds*below*24M Hz
HardwareSerial_LP Uart_lp = HardwareSerial_LP();



void setup() {
**pinMode(LED_BUILTIN, OUTPUT);
**digitalWrite(LED_BUILTIN, HIGH);
**delay(1000);
**digitalWrite(LED_BUILTIN, LOW);
**delay(500);
***digitalWrite(LED_BUILTIN, HIGH);
***delay(1000);
***digitalWrite(LED_BUILTIN, LOW);
****delay(500);
*******
*
****/************************************************** ***
*******Start*off*at*2MHz*so*the*IntervalTimer_LP*c lass*
*******BUS*clock*configuration*is*initialized*at*t he*same
*******BUS*frequency*as*Sleep*BUS*clock.
************************************************** ********/
****LP.CPU(TWO_MHZ);
****/************************************************** ***
*******Start*serial*port*using*2MHz*CPU*speed.
************************************************** ********/
****Uart_lp.begin(57600);
*****
****delay (5000);
****Uart_lp.print("Sleep Advanced \n");
****Uart_lp.flush();
****
****pinMode(9, INPUT);
****attachInterrupt(9, callbackhandler, RISING);
}

void loop() {
****/************************************************** ***
*******Sleep*for*5*secs,*thanks*to*the*IntervalTim er_LP*class
************************************************** ********/
****LP.Sleep();
****Uart_lp.println("Wakey Wakey");
****Uart_lp.flush();
}

void callbackhandler() {
****digitalWrite(LED_BUILTIN, HIGH);
****delay(100);
****digitalWrite(LED_BUILTIN, LOW);
*****delay(100);
****digitalWrite(LED_BUILTIN, HIGH);
****delay(100);
****digitalWrite(LED_BUILTIN, LOW);
****
****Uart_lp.print ("CallBack");
****Uart_lp.flush();
}

duff
04-28-2014, 04:27 AM
Is it possible to maintain a USB connection after sleep?



Hi Christopher,

Try not running at 2 MHZ, and put a delay in after sleep. You will have to reopen the serial monitor also.



#include <LowPower_Teensy3.h>

TEENSY3_LP LP = TEENSY3_LP();
// allows use of the serial port at speeds below 24MHz
HardwareSerial_LP Uart_lp = HardwareSerial_LP();

elapsedMillis time;

void callbackhandler() {
digitalWrite(LED_BUILTIN, HIGH);
delay(100);
digitalWrite(LED_BUILTIN, LOW);
}

void setup() {
pinMode(LED_BUILTIN, OUTPUT);
pinMode(9, INPUT);
attachInterrupt(9, callbackhandler, RISING);

//LP.CPU(TWO_MHZ);/***** this will disable USB *****/

Uart_lp.begin(9600);
Uart_lp.print("Sleep Advanced \n");
Uart_lp.flush();
delay(500);
}

void loop() {
/************************************************** ***
* Sleep
************************************************** ***/
LP.Sleep();/***** this will disable USB until waken*****/
Uart_lp.println("Wakey Wakey");
Uart_lp.flush();
time = 0;
while(time < 10000) {
Serial.println("USB enabled");
delay(100);
}
}


If you want to run your teensy at speeds lower than F_CPU the USB will be disabled using this library. Also any sleep mode will disable it also. While writing this library the USB has been one of the biggest issue i've dealt with. Keep in mind that all the teensy's different functionalities are configured for using the cpu, bus and mem at F_CPU, F_BUS and F_MEM. Care needs to be taken when running at these reduced speeds. Thats what the HardwareSerial_LP classes or the IntervalTimer_LP Class in the library try to resolve.

Also i should mention some things about the "Sleep" function. Part of the entry routine is to put the processor into VLPR (2MHZ) mode before going to sleep or more specifically "VLPW" mode. You must take this into account in that the processor is running at a slower speed so all the things I've stated above apply to this sleep mode also.

My recommendation for anyone trying to use these low power features would be, get your application running how you want first then add in the low power routines after. You must consider the performance you need to accomplish your task then tailor your power considerations accordingly because they can greatly reduce the performance you might need.

solardude
04-28-2014, 05:09 PM
1904

I ended up finding the Teensy 3.1 for my application that is using Sharp's Ultra Low Power LCD Screens that require large amounts of SRAM since each pixel on the LCD screen requires 1 bit of memory. I'm using their 2.7 inch 400x240 pixel display which requires about 12000 bytes of SRAM for screen buffering.

This 2.7 inch screen only consumes 50 μW when displaying a static image. Hence power consumption is approximately only 1% of that of conventional transmissive TFT LCDs of the same size and even compared to conventional reflective displays the Memory LCD needs only a tenth of the power. . http://www.sharpmemorylcd.com/2-7-inch-memory-lcd.html

Here is a video showing the screens and how they operate. https://www.youtube.com/watch?v=eAoC818Mxy4

I'm using the Teensy 3.1 + Sharp LCD + Battery fuel gauge.

I want to put the Teensy 3.1 into deep sleep modes when the battery is not being used but I want to keep the Sharp LCD powered on while the Teensy 3.1 is in deep sleep so the battery status info is always being displayed and maybe have the Teensy 3.1 wake ever 24 hours to update the screen.

The plan is to have the Teensy 3 wake up via a button based interrupt and maybe a change in input our output current if that is possible.

My real question is what do you guys think is the best way to use the low power mode on the Teensy 3 while keep the Sharp Memory LCD powered up displaying static battery status info while the battery is in deep sleep mode. Do I need an external chip for refreshing the LCD while the Teensy is in deep sleep?

Below is some data on how the sharp display needs to be refreshed.

sharp also has an appnote on this display:
http://www.sharpmemorylcd.com/resources ... n_Info.pdf


on page 10:
This polarity-inversion flag enables a periodic polarity inversion
on the panel to keep a latent charge from building up within the
Liquid Crystal cells.


on page 12:
as long as the panel has power and VCOM is toggled periodically.
Sharp recommends keeping maximum time between VCOM toggles to no more
than one second, and refreshing data every two hours, to prevent stuck
pixels.


and on page 13:
In either implementation, the positive and negative inversion
intervals should be kept as equal as possible, and intervals should
not exceed one second.



my interpretation is that the data (12000 bytes) should be resent
at least every few hours, but that the display polarity needs to
be inverted at least one per second.

MichaelMeissner
04-28-2014, 05:33 PM
Have you thought about using RePaper lcds that keep their display with no power? They are evidently slow to update, but if your display only changes every so often, you might come out ahead power wise: https://www.adafruit.com/products/1346

solardude
04-28-2014, 05:38 PM
Thanks Michael, but when the screen is not in deep sleep mode showing static images it will be showing real time battery status info that will be refreshed every .5 or 1 seconds. so the RePaper LCD's would not work in that situation due to their low refresh rates.

christopherlarsen
04-29-2014, 01:05 AM
. You will have to reopen the serial monitor also.

Duff,

I greatly appreciate your quick response. The code that you posted worked, and I was able to re-open serial monitor during the delay, and observe the re-opened connection.
In my original program, I was using the serial monitor to collect and store the data file. For my case, re-opening the serial monitor every few seconds probably will not work. I will probably use the dual power concept with two diodes, where an analog pin attached to VUsb through a voltage divider is used to determine if the processor can enter sleep. While connected to USB and collecting data, I will let the processor run full speed. When on battery the information will be sent to a LCD, then allow the processor to sleep.

Thanks !

duff
04-29-2014, 02:24 AM
my interpretation is that the data (12000 bytes) should be resent
at least every few hours, but that the display polarity needs to
be inverted at least one per second.


hi solardude,

you could use the either RTC or Low Power Timer (LPTMR) to wake up every second, toggle that pin and go back to deep sleep. Also if you are using the "time" library you need to resync it every time you wake from sleep since the systick is disabled during deep sleep, not sure if you are displaying current time also.

Thats a pretty cool little display i must say.

duff

solardude
04-29-2014, 03:06 AM
hi solardude,

you could use the either RTC or Low Power Timer (LPTMR) to wake up every second, toggle that pin and go back to deep sleep. Also if you are using the "time" library you need to resync it every time you wake from sleep since the systick is disabled during deep sleep, not sure if you are displaying current time also.

That's a pretty cool little display i must say.

duff

Duff thank you so much for writing back. I see that you have dove deep into the low power modes for the Teensy 3.1 chip so your the man I should be talking to about this.

So no I'm not displaying time on the screen and I have no plans on doing that in the future also so hopefully that makes things a little more simple.

Can you tell me more about the Low Power Timer (LPTMR) feature. Does that allow the main Micro to stay in Deep Sleep while the LPTMR does the toggling of the pin every second? If so that sounds like the perfect solution.

Any ideas on what kind of deep sleep power consumption we would be looking at for just the Teensy 3.1 board if it were in Deep Sleep and the LPTMR was doing the toggling every second?

The Sharp Displays are very cool and efficient indeed. I mainly wanted them because they were easily to see in direct sunlight and they have super low power consumption which is great for battery powered applications. This is the same type of screens they are using the Pebble Watch and a few others that have not make it to market yet but have been successfully Kickstarted.

The screens come in a few different sizes:

19071908

duff
04-29-2014, 04:24 AM
Can you tell me more about the Low Power Timer (LPTMR) feature. Does that allow the main Micro to stay in Deep Sleep while the LPTMR does the toggling of the pin every second? If so that sounds like the perfect solution.

No none of the sleep modes currently support this, definitely not any deep sleep mode. What you will have to do is wakeup, toggle the pin then go back to sleep. The LPTMR timer just wakes the teensy, toggling is up to you.




Any ideas on what kind of deep sleep power consumption we would be looking at for just the Teensy 3.1 board if it were in Deep Sleep and the LPTMR was doing the toggling every second?

If you just toggle a pin every second the power consumption should be pretty low, probably around the stated .250mA + whatever else you have connected, your fuel gauge should give you all that meta data? The only thing i can think of now that would consume extra power is when the toggle pin is high, it all depends what it is connected to it, you will have to do some tests. Maybe if it works like this, make your transistions LOW->HIGH->LOW?

To save power try to make any processing in between sleeps as fast as possible, so optimize your code the best you can. I'm assuming your using my library(beta)?, the "DeepSleep" routine has callback function that would be perfect for your pin toggling. The deep sleep examples will show you this.

duff

solardude
04-29-2014, 04:44 AM
No none of the sleep modes currently support this, definitely not any deep sleep mode. What you will have to do is wakeup, toggle the pin then go back to sleep. The LPTMR timer just wakes the teensy, toggling is up to you.



If you just toggle a pin every second the power consumption should be pretty low, probably around the stated .250mA + whatever else you have connected, your fuel gauge should give you all that meta data? The only thing i can think of now that would consume extra power is when the toggle pin is high, it all depends what it is connected to it, you will have to do some tests. Maybe if it works like this, make your transistions LOW->HIGH->LOW?

To save power try to make any processing in between sleeps as fast as possible, so optimize your code the best you can. I'm assuming your using my library(beta)?, the "DeepSleep" routine has callback function that would be perfect for your pin toggling. The deep sleep examples will show you this.

duff

Ok, so a power consumption guesstimate of .250mA is low but not as low as I would like to go.

How about if while the battery is in the standby state I put the Teensy 3.1 into Deep Sleep only calling it wake up every 24 hours and update the battery fuel gauge data and refresh the LCD. It will continue doing this until triggered to go into active mode. So every 24 hours the Sharp Memory LCD gets it pixel data updated and then we could use a CMOS 555 Timer that consumes .144 uA @ 5v to generate a square wave at .5Hz to send the Vcom refresh pulse to the Sharp Memory LCD.

Would that allow the Teensy 3.1 to stay in a deep sleep state for all but a second every 24 hours?

If so then that would bring the stand by current down to a few hundred uA for the Teensy 3.1 in deep sleep + the memory LCD + battery fuel gauge.

Is there any reason that type of setup would not work based on the info I have provided so far? The 555 timer can generate a pulse every .5 - 1 seconds right?

Here is a video showing the low power consumption of the new CMOS 555 Timers https://www.youtube.com/watch?v=T2WXy2wW_LI

duff
04-29-2014, 05:19 AM
Ok, so a power consumption guesstimate of .250mA is low but not as low as I would like to go.


.250mA is what my current library supports, i can say that I have achieved much lower than that but I can't show it now since it has the possiblity of locking up the teensy. Until i can figure that out .250mA is what you will have to live with:D.

solardude
04-29-2014, 06:21 AM
.250mA is what my current library supports, i can say that I have achieved much lower than that but I can't show it now since it has the possibility of locking up the teensy. Until i can figure that out .250mA is what you will have to live with:D.

Does the Deep Sleep mode disable the USB chip? Eventually the chip will be installed in finished product and the USB chip would not really be needed in the final design so would eliminating that reduce power consumption below the .250mA or is it already take care of?

Also what frequency would the chip be running at with that .250mA power consumption guesstimate? 24 mhz or something slower?

Massel
04-29-2014, 03:39 PM
Hi,
once again a short question.


After software bootloader change ...
Downloaded program: "blank.pde"
Teensy 3 active run (idle) current Is 13.07 ma. @ 24 Mhz <-------<<<<<
Teensy 3 active run (idle) current Is 18.8 ma. @ 48 Mhz <-------<<<<<
Teensy 3 active run (idle) current Is 25.4 ma. @ 96 Mhz <-------<<<<<
No connections are made to the Teensy 3

Is this the same with Teensy 3.1?
If so, why is my Teensy 3.1 using like 25ma @ 48 Mhz (LED off, nothing connected to it)?

Thx in advance

duff
04-29-2014, 04:25 PM
Does the Deep Sleep mode disable the USB chip? Eventually the chip will be installed in finished product and the USB chip would not really be needed in the final design so would eliminating that reduce power consumption below the .250mA or is it already take care of?

yes it does disable USB in any sleep mode.



Also what frequency would the chip be running at with that .250mA power consumption guesstimate? 24 mhz or something slower?

The clocks will be stopped in DeepSleep or Hibernate so nothing is being clocked at 24/48/96MHz.

duff
04-29-2014, 04:27 PM
Hi,
once again a short question.



Is this the same with Teensy 3.1?
If so, why is my Teensy 3.1 using like 25ma @ 48 Mhz (LED off, nothing connected to it)?

Thx in advance

I'm not sure, how are you measuring this? I haven't looked at the current consumption of the Teensy3.1 while running at full speed.

solardude
04-29-2014, 04:36 PM
yes it does disable USB in any sleep mode.


The clocks will be stopped in DeepSleep or Hibernate so nothing is being clocked at 24/48/96MHz.

Thank you very much for the answers.

I think I can live with the .250mA power consumption. That gives me about 166 days of run time per amp hour of battery storage. I can program it turn the screen refreshing off and stay in deep sleep mode once the battery state of charge hits 10%.

So with this new method your still working on that provides a much lower seep current, if you do get it working how much lower could the deep sleep power consumption go?

Massel
04-29-2014, 04:38 PM
I just took a multimeter in the Vin-line between battery+ and Vin.

Do I have to change the bootloader? Tried it, no change...

duff
04-29-2014, 04:46 PM
this new method your still working on that provides a much lower seep current, if you do get it working how much lower could the deep sleep power consumption go?

ummm... on the order of 10uA maybe lower, haven't measured it with a bare teensy yet, i'm measuring it with a board I made that has some stuff sucking up power also. Probably won't be for a while until I get this worked out, many other things to do also. Plus i need to talk to paul about this to see what he thinks the best route is.

duff
04-29-2014, 04:52 PM
I just took a multimeter in the Vin-line between battery+ and Vin.

Do I have to change the bootloader? Tried it, no change...

No sure why this is, like i said I haven't measured a teensy3.1 running at F_CPU. Maybe someone could confirm your numbers, I'm using my 3.1's on different project right now and can't measure this.

solardude
04-29-2014, 05:00 PM
ummm... on the order of 10uA maybe lower, haven't measured it with a bare teensy yet, i'm measuring it with a board I made that has some stuff sucking up power also. Probably won't be for a while until I get this worked out, many other things to do also. Plus i need to talk to paul about this to see what he thinks the best route is.

No problem, I just wanted to get an idea of what may be possible sometime in the future.

And what is the latest power consumption in Deep Sleep?

jassing
05-22-2014, 02:35 PM
Is there a way to have the teensy sleep, but have a pin remain in it's state (HIGH/LOW) while sleeping? or am I better off using a latching relay for something like this? (or is there another way to do it?)

What I'm after is to have a pin high or low which in turn signals an led to be on or off. I want to sleep the cpu for 30 seconds to save battery power but keep the led on or off during the sleep cycle.

duff
05-22-2014, 09:14 PM
yes, the pin state is retained when sleeping.

jassing
05-24-2014, 12:56 PM
Awesome; thank you!
The "low power"guide seems to have a lot of place holders, so I'm trying various libraries... so far one didn't work as it relied on files that I didn't have; and another actually drew slightly more when in it's "low power" mode... the really odd part was that I had a blinking led that worked; but the pin I Need to stay up was not being brought up to high at all... sadly, when using that library, serial output was disabled. I'll keep at it now that I know the pin will stay high/low during sleep. thank you!

duff
05-24-2014, 01:14 PM
Awesome; thank you!
The "low power"guide seems to have a lot of place holders, so I'm trying various libraries... so far one didn't work as it relied on files that I didn't have; and another actually drew slightly more when in it's "low power" mode... the really odd part was that I had a blinking led that worked; but the pin I Need to stay up was not being brought up to high at all... sadly, when using that library, serial output was disabled. I'll keep at it now that I know the pin will stay high/low during sleep. thank you!

The AVR Sleep Library won't work, did you try this low power library (https://github.com/duff2013/LowPower_Teensy3)? I don't think there is any others for the teensy3.0/3.1 yet.

jassing
05-24-2014, 01:30 PM
Right; the avr doesn't work, of course.
Yes, that's the library I tried; when put into 'deep sleep' and then out of sleep; it drew more power than when I left it alone. Perhaps the time/power it takes to recover back to full speed negates the time in sleep, just not 'slept' long enough; and the pin did not stay high... I'll keep at it. It is possible(read:likely) I have something wired less than optimally.

solardude
06-26-2014, 07:34 PM
ummm... on the order of 10uA maybe lower, haven't measured it with a bare teensy yet, i'm measuring it with a board I made that has some stuff sucking up power also. Probably won't be for a while until I get this worked out, many other things to do also. Plus i need to talk to paul about this to see what he thinks the best route is.

Hey Duff, any progress on this lower 10uA low power mode on the Teensy 3.1?

duff
06-27-2014, 02:30 AM
prolly not for a while, the teensy core is pretty fluid right now, I'm waiting for 1.20 or 1.21 depending on what changes their might be. Some of the low power functionality is already in the core currently and suspect some of the sleep modes will be in core at some point also. But for now I need to focus on my wireless teensy SDI-12 (http://www.sdi-12.org/current%20specification/SDI-12_version1_3%20January%2026,%202013.pdf) data logger!

solardude
08-11-2014, 03:54 AM
prolly not for a while, the teensy core is pretty fluid right now, I'm waiting for 1.20 or 1.21 depending on what changes their might be. Some of the low power functionality is already in the core currently and suspect some of the sleep modes will be in core at some point also. But for now I need to focus on my wireless teensy SDI-12 (http://www.sdi-12.org/current%20specification/SDI-12_version1_3%20January%2026,%202013.pdf) data logger!

Duff can you give me any advice on how to best try to accomplish the 10 uA sleep current consumption with the Teensy 3.1 microchip? I'm building out a custom board for a product and its going to be the same processor as the Teensy 3.1. I can live with the .250 mA deep sleep that is up and working now but the LCD screen and timer I'm using is only consuming about 20 uA which is really good so I can really benefit if I could get the micro to sleep closer to your 10 uA deep sleep setup.

Just curious as to how you went about getting that.

froeber
08-22-2014, 02:07 AM
Hey @duff, I'm sort of wondering how you get 10uA too. I want to throw my board into real lower power state when battery voltage drops and leave it there until USB charger plugged in so that I don't overdischarge the LiON battery we're using and wreck it. I've put the processor into VLLS0 power state with everything off that I can figure out and can't get power below about 250uA. Thing is that I have a lot of stuff hooked up to the Teensy and I know (and have measured) how driving even one GPIO pullup/down while sleeping can cost 100uA extra power. I've tried things like switching to BLPI clock mode running at low speed before going into VLLS0 but that didn't make any difference (which makes sense since all the clocks will be shut down in VLLS0 anyways).

I guess I was just wondering if there was some magic you did that you found made a difference. I wasn't sure, for instance, if the external 16MHz crystal oscillator goes off in VLLS0. Or if something has to be done with the USB regulator (even though of course USB is off). I'm driving my display and BLE chips off the Teensy 3.3V output and I've measured them pulling just 3uA in the sleep states they are in. So I think it's something internal. I have the RTC running off the external 32KHz crystal but that should only pull a couple of uA.

For what it's worth, I know it's not current draw from the MIN54. I've got two versions of the circuit one with the Teensy and all the peripherals and a version on a PCB with no MIN54 using JTAG loader and both pull the same current when "shut down" to within a few uA.

I'm just hoping you did something tricky I didn't think of to get the power that low. If not, then there must still be some external power draw I'm missing.
Fred

solardude
08-22-2014, 03:01 AM
@froeber nice to know that driving one GPIO pin in sleep raises sleep current 100uA.

I'm hoping @Duff does stop by to drop some knowledge on us about this 10uA standby current consumption he has accomplished.

@froeber please do make sure to comeback and let us know if you do make any progress on getting the sleep current below .250uA.

duff
08-22-2014, 05:24 AM
I haven't really been looking at the low power stuff lately been working on my SDI-12 logger library (https://github.com/duff2013/SDI12_T3), but I have just got some equipment to make accurate measurements at very low power. Once I can confirm my low power library compatible with all the new changes to the teensyduino core i'll be releasing what i've found concerning getting the teensy down to much lower power consumption. Sorry for being so terse, these are actually really advanced topics that I can't be responsible for beginners possibly thinking they bricked their teensy trying these things I've found.

froeber, i know you have really looked at this low power stuff in detail, so once I get rolling on this again i'll pm you if you would be willing to help me get these real low power settings figured out for the Teensy Arduino community so things work solidly.

froeber
08-29-2014, 11:29 PM
Just an update. So, I was trying to come up with a super low power state that I could put the Teensy 3.0 processor into when our LiON battery got too low so that it would stop discharging until plugged into a charger. After much fiddling around and searching the Freescale Kinetis forums and trying to get power usage real low in VLLS0 power mode I changed my mind. I couldn't get power below 200 uA with all the peripheral connections we had to our Teensy 3.0. So I decided to use a HW battery disable circuit with a couple of FETs that allows power to be shut down by the MCU such that it doesn't power back up until USB is plugged in and Vusb powers the circuit back up. Problem solved. The power draw when shut down is only a few uA (we leave the Vbat connection to power the RTC). Of course, a down side that we don't care about is that about the only possible wakeup source for this is Vusb coming back.

I have to say that I have read with great interest all the postings by a Freescale engineer Phillip Drake. He posts a lot in the Freescale Kinetis forum. He indicates his main job is testing and documenting low power operations of the Kinetis processors. He wrote App Note 4503 which is useful for low power work. And he indicates that he still learns new stuff every day about getting things to work right. And he can talk to the chip designers which I can't. I've found low power work fairly frustrating because, for all the documentation there is, there are still lots of details missing. And with SW the devil is in the details.

For normal reduced power operation I got LLS mode running and VLPW mode. I couldn't get VLPS to run reliably. I'm using VLPW mode because I want the Watchdog timer to be active for reliability issues. But LLS mode did have lower power use. I based my code off of the great work in @duff's library.

Just thought I'd pass that along for what it's worth.

neilh20
08-30-2014, 04:50 PM
froeber thanks for posting your experience and for your solution.
I've got it on my list to get to low power as well, and building low uA into my power usage model, so useful to have some real experience.
Here is a posting by Eric Styger on using the FRDM-KL25 that says he got there, and he had to cut the board to get there.
http://mcuoneclipse.com/2013/10/20/tutorial-using-the-frdm-kl25z-as-low-power-board/
The FRDM-KL25 is built to be able to test low power, so I think a similar approach would need to use the FRDM-KL20 board.

In a previous life with an mega128 I got to very low power for the mega128, but I did it by designing the software for the mode right up front, and it was a whole system design.
It taught me, like you are saying I need to think of it in the early stages of the project. This time I'm anticipating using the new Kinetis SDK Processor Expert
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=KINETIS_SDK
which Eric Styger gives some tutorials on. (http://mcuoneclipse.com)
The core of the Kinetis low power is the clocking and managing it.
My plan is to verify the low power upfront,
then switch between a high power run mode for use by the SPI and USB, and a low power run mode for normal operation,
The LowPowerRun which should be able to switch to a wait mode for power saving while processing
and then finally switch to a sleep mode with wakeup sources through the LLWU for getting to the lowest power state.

I'll post if I get there :)

froeber
08-31-2014, 03:03 PM
Here is a posting by Eric Styger on using the FRDM-KL25 that says he got there, and he had to cut the board to get there.
http://mcuoneclipse.com/2013/10/20/tutorial-using-the-frdm-kl25z-as-low-power-board/
The FRDM-KL25 is built to be able to test low power, so I think a similar approach would need to use the FRDM-KL20 board.
Neil, Thanks for the great link! And damn, how much easier things are with the right tools! That guy Eric Styger is using the Freescale Code Warrior toolset with their processor expert support. And it allows you to use a nice Gui to select all sorts of features that then "auto generate" the code for you. And there's a debugger. And... With Teensy we get none of those awesome things. We get the fairly bare bones Arduino IDE and nothing like the processor expert or debugger. And for low power we get libraries from nice people like Duff and stuff we write ourselves. And every tweak to modes is more code to write and different conditional compilation directives. BUT, Arduino costs $0 and list price for the professional version of the Code Warrior toolset that includes Processor expert is like $5K/seat. And that's the trade off. I've been in this business a long time as I suspect have you Neil and it's always wonderful to use the big $$ great toolsets. But too often we get stuck with the cheap low functionality tools and burning our own time instead.

Oh well, enough of that. What was most impressive with Eric's stuff were the results he was able to get. So, as I posted earlier, even with the lowest power mode of the K20 MCU we are using I couldn't get Teensy board power below 250 uA. And it should have been 10 uA or so. And Eric used the LLS low power mode that our processor also supports and got 2uA whereas I could never get much below 300uA. So, there must be one of those vampire power draws on our board that Eric found and eliminated on his board by cutting traces and removing components. I haven't gone to those lengths to try to track this down because I couldn't figure out what was really driving the power usage and I couldn't do all the easy "what if" tests that the processor expert tool allows. Maybe I'll revisit things.

So, one thing I do know is that the Freescale boards use 8MHz oscillators and our Teensy boards use a 16MHz oscillator. I'm not sure why Paul made the different choice but the 2x faster oscillator typically draws 3x the power from the data sheet details I could find. But I'm not sure I ever found the magic code to turn off the oscillator even though I tried the BLPI power mode Eric said lowered his power. Also, our board uses a higher performance M4 processor than the M0 processor on Eric's board. Now, I don't really need that extra performance but our processor does have EEPROM support that's real useful for our application.

So, after reading about Eric's exploits I'm wondering about putting some more time in to figuring out where the extra 200 to 300 uA current draw is going. And maybe at some point I'll try to figure out some more why I have to use VLPW mode and can't get reliable VLPS mode operation (where VLPW is specced at 500uA and VLPS at 20uA). But, for now I reached my low power goal of <1mA when sleeping -- interestingly the same as the goal Eric proposed for his documented exercise. So I think I'll wait to see if anyone else turns anything up. And thanks Neil for the reference to Eric's work!
Fred

neilh20
09-01-2014, 05:22 PM
Hi Froeber,
The Teensy3 is fantastic for a production article, and the support to make it work with the Arduino IDE, and the libs like Duff are doing - all based on the amazing infrastructure by Paul.
I also really appreciate your posting for alerting me again to the difficulty of low power, and its a project assumption for me to get there.
I'm getting a FRDM-MK20D to prototype the low power, as well as using the Teensy3.1. My target board can't use the Teensy3.1 - though it would have been really nice if it had worked for what I wanted it to and I could have used it straight away.

However, there are tradeoff's made in designing something - and sometimes its recognizing them. Teensy3 is evolving and Paul has been hinting online he is coming up with a new product - so maybe it will be informed by this discussion. Also OpenSDA is slowly evolving/pioneering, a simple concept and Freescale is using a tiny MK20 hw to implement it OpenHwSDA, and letting Segger do the software - so its not Open(sw)SDA - and Segger commercially restrict its use in production.

EmBlocks.org is using another open source paradigm to intergrate OpenSDA methods into an IDE, though just for the STM32 line of processors so far.
Eclipse for Freescale is becoming more stable and integrates with OpenSDA SWD/JTAG. So lots happening and the Open Source movement is really making a lot of tools accessible. Thank you to the tools guys for doing that

The whole thing about LOW POWER in the uW is it takes system design and effort. If the cost of the external power source is minimal (ie USB) or externalized to the customer, then its not worth the software (and hardware) effort.
The hierarchy of power sources I'm seeing is - "free" as in USB or wall wart, largeSolarPanels(10W)+12VSLA, Solar(1W)+LiXxxStorage, DDD-->AAA ReplaceableBattery, low power Harvesting+SuperCap

LOW POWER also requires a programming paradigm shift to event based programming and that appears a bit specialist in the Arduino community.
Eric Styger from my reading is a Professor at Lucerne Univ, and also has some sort Freescale recognition with an employee#. Wonderful that Freescale are encouraging that type of support and Eric as Lecturer is publishing simple approaches. :)

gbathree
10-10-2014, 04:14 PM
Hey guys, I am looking to use the Duff's library in a slightly different way and am seeking some feedback.

We are taking analog_reads on a detector, using the 16 bit pins (I think A10 and A11). There's a good amount of noise in the ADC itself, and while we've tracked some of it down there's still some left. I know the ADC isn't actually 16 bit capable so I'm not shooting for the moon here, but I was wondering if there were any low power modes which I could enter to reduce noise on the ADC. I saw in the old low_power library for Teensy 2.0, there is a specific call for adcNoiseReduction() . However, there's no similar call that I can find in the new lowpower_teensy3 library.

I thought the sleep() call in the teensy3 library may work but I saw it hasn't been implemented yet. When I tried the LP.Run(LP_RUN_ON) and ...OFF function, I lost the USB Serial connection, even if I attempted to reconnect using Serial.begin(115200) after the LP.Run(LP_RUN_OFF) call, so that won't for in my application.

So, in short, any ideas for power adjustments to lower ADC noise on a Teensy 3.1?

duff
10-10-2014, 05:43 PM
but I was wondering if there were any low power modes which I could enter to reduce noise on the ADC. I saw in the old low_power library for Teensy 2.0, there is a specific call for adcNoiseReduction() . However, there's no similar call that I can find in the new lowpower_teensy3 library.

Yes, there is not a function named that specifically but basically they are just shutting off the CPU and turning it on and taking a measurement soon after to reduce the CPU noise imposed on the ADC.



I thought the sleep() call in the teensy3 library may work but I saw it hasn't been implemented yet.

This is implemented on the latest version. https://github.com/duff2013/LowPower_Teensy3



When I tried the LP.Run(LP_RUN_ON) and ...OFF function, I lost the USB Serial connection, even if I attempted to reconnect using Serial.begin(115200) after the LP.Run(LP_RUN_OFF) call, so that won't for in my application.

yes it will lose usb but this is old version, the latest library actually you can dynamically go into other CPU speeds, there are MACROS (TWO_MHZ, FOUR_MHZ, EIGHT_MHZ, SIXTEEN_MHZ and F_CPU) that you would use for the function parameter, The github page has examples in the readme. Also you can set the CPU speed using the Arduino IDE.



So, in short, any ideas for power adjustments to lower ADC noise on a Teensy 3.1?

what frequency are you sampling the ADC? You can use DeepSleep function and use the LowPower Timer to wake it up, It has millisecond resolution currently. Or use the Sleep function which you can use your own interrupt source to wake it like Interval Timer and get sub milliseconds sleep if needed.

That being said I'm working on an update to work with the 1.20 core better and an advanced feature to get around ~10uA sleep so any feature request should be directed now. I didn't like the AVR sleep library, it would really limit the many sleep features that the teensy can do. I'm sure that paul will probably port the AVR style sleep modes which is probably fine for many application but I wrote this library to get to all the cool teensy sleep mode features.

gorsha
11-03-2014, 08:44 PM
Hello everyone.

I've been researching how to further reduce power consumption of Teensy 3.1. Currently Deep sleep and Hibernate both use ~0.23mA of current in my case.

However, I've found out that when I upload the program and go to Deep sleep or Hibernate (with Hibernate it happens only the first time), I get ~0.13mA consumption. But if I reapply power (or Hibernate again), I get ~0.23 mA consumption. I think the main issue here is MINI54 chip, which is using less power when in some (program?) mode.

Would it be possible to further reduce the consumption of MINI54? Or as last resort cut the power to MINI54 right before 3.3V pin and make a connection only when uploading (connect both 3.3V pins)?

It would be really great if we could achieve less than 10uA...

bigredbee
12-16-2014, 12:30 AM
Back in April in this thread, Massel reported that he was having trouble with the GPIO_WAKE part of the DeepSleep_Simple example for the LowPower_Teensy library. I'm running into this same problem. LPTMR_WAKE works as expected, but GPIO_WAKE behaves as if it never goes to sleep. I can tell it never goes to sleep because the USB port stays alive (it normally drops after the Teensy goes to sleep).

I'm using a Teensy 3.1, and Teensyduino 1.18 and version 4 of the LowPower_Teensy library.

Anyone else run into this?

Greg

duff
12-16-2014, 01:30 PM
Back in April in this thread, Massel reported that he was having trouble with the GPIO_WAKE part of the DeepSleep_Simple example for the LowPower_Teensy library. I'm running into this same problem. LPTMR_WAKE works as expected, but GPIO_WAKE behaves as if it never goes to sleep. I can tell it never goes to sleep because the USB port stays alive (it normally drops after the Teensy goes to sleep).

I'm using a Teensy 3.1, and Teensyduino 1.18 and version 4 of the LowPower_Teensy library.

Anyone else run into this?

Greg

I would suggest you upgrade to Teensyduino 1.20 since there are many new features and important fixes! If you do that you can check out my new low power library Snooze (https://github.com/duff2013/Snooze) since I'm not developing the old LowPower_Teensy3 anymore.

That being said what are you doing before you are going to sleep? Make sure any communications are finsihed before calling any sleep functions as an example.

bigredbee
12-16-2014, 01:41 PM
I would suggest you upgrade to Teensyduino 1.20 since there are many new features and important fixes! If you do that you can check out my new low power library Snooze (https://github.com/duff2013/Snooze) since I'm not developing the old LowPower_Teensy3 anymore.

I'll do that and let everyone know how it goes.


That being said what are you doing before you are going to sleep? Make sure any communications are finsihed before calling any sleep functions as an example.

I'm just running the stock example with no changes.

solardude
12-24-2014, 07:41 AM
I would suggest you upgrade to Teensyduino 1.20 since there are many new features and important fixes! If you do that you can check out my new low power library Snooze (https://github.com/duff2013/Snooze) since I'm not developing the old LowPower_Teensy3 anymore.

That being said what are you doing before you are going to sleep? Make sure any communications are finished before calling any sleep functions as an example.

Duff I'm super happy to see that you wrote and shared the code that allows us to put the Teensy 3.1 into super duper low 15uA hibernate mode!!!!!:cool:

I'm building a portable product that runs on batteries and has a sharp memory LCD that consumes like 12uA when the screen is showing a static image. So with your new snooze code I will be able to update the battery status on the Sharp LCD screen once every 24 hours and then put the Teensy 3.1 back to sleep for 24 hours. I can do this for 30 days and only consume about 20 mA which is really low power consumption. Your snooze library is perfect for my application.

Great news Duff! Glad I check back in here to see if any changes have been made to this and surprise surprise the low power problem has been solved ;)

I'll report back once I start testing all this together.

Constantin
12-24-2014, 03:49 PM
Gorsha,
As I recall, Paul cut down on power consumption by the mini 54 quite a bit. You could theoretically power it such that it only gets power via usb, but this would likely be limited to self made boards where you can add a small VREG just for the Mini54.

martin7743
01-12-2015, 09:09 AM
Hi,
I am using a Teensy 3.1 with Teensyduino 1.20 and Snooze. During "Snooze.hibernate" the 3.3V Pin reads only 3.20V. If a load (0.5mA) is apllied to the 3.3V line, then the voltage drops even further to 3.11V.
This was a quick measurment with a standard Multimeter, but before investigating this further I just wanted to know if Snooze "allows" to use the 3.3V during hibernating or if the voltage regulator is powered down.
Thanks!

Best regards,
Martin

martin7743
01-15-2015, 08:33 AM
Ok, it seems, that in Snooze.hibernate() the voltageregulator is set to standby, and in Snooze.deepSleep() the voltageregulator is working normal.

Best regards,
Martin

npashine
03-09-2016, 09:37 AM
Hi all,

kindly update the "https://www.pjrc.com/teensy/low_power.html" with teensy 3.2.

Donziboy2
03-09-2016, 09:44 AM
Hi all,

kindly update the "https://www.pjrc.com/teensy/low_power.html" with teensy 3.2.

I dont see any Teensy 3 family info on that page, I don't think that page is for the Teensy 3 series...

npashine
03-09-2016, 09:48 AM
I'm asking if you can update for teensy 3.2.

Fyod
04-20-2016, 04:08 PM
Has anyone done any comparisons for 3.1 or 3.2 testing the various state consumptions?

SnowTrack
09-21-2016, 09:29 AM
you can download my library and check out the examples: https://github.com/duff2013/LowPower_Teensy3

regards,
duff
duff,

Any chance you could add the final stableversion of LowPower_Teensy3 back to your GitHub repository (or attach a .ZIP file of it here as an archive)? I have a teensy 3.2 sketch that uses it to run a solar powered snow depth sensor and it works very well. I'm in the process of rebuilding my Arduino/teensyduino environment on a new PC and with that library missing from GitHub I'm stuck now. I have not been successful in porting my sketch over to use your new Snooze library yet. Too many complications with serial communications, watchdog timers, EPROM writes and dynamic CPU speeds...

Thanks, Fred