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

Status
Not open for further replies.
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.
 
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:

SettingsCurrent (uA)
VLLS3 (Duff's Hibernate), no changes to pins 18 & 19132
VLLS0, pins 18 & 19 configured as INPUT_PULLUP130

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.
 
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
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
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.
 
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?
 
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
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 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
 
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?
 
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....
 
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!
 
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.
 
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.
 
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.
 
@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.
 
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.
 
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.

Code:
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.
 
Going into VLPS mode

@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.
 
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.
 
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
 

Attachments

  • LowPower_Teensy3.zip
    39.7 KB · Views: 360
@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!
 
Status
Not open for further replies.
Back
Top