Teensy 4.0 Low Power

sadly ma

XFer said:
ma? Are you sure?
Click to expand...

just remade the msmnts - they are good. if you look in IMXRT1060CEC.PDF which is the technical datasheet
111 pages 1.9 megabyte on page 26 table 13 they list some of the idle mode currents and if you assume that
on the T4 you are looking at the sum of the 3 currents they list for different pins (its all gotta ultimately come
from the 5v pin) they vary by mode from a handful of ma down to 20ua. only the power down modes are in
the ua's and keep in mind that there are other parts on the board - datasheet numbers are for 106x only.

so i think that if you need to retain data or status and only do a warm startup after snooze deepsleep or sleep
you are looking at 10-20 ma and if you can stand a total cold start each time the power down current (rtc
running so it knows when to "wake") you still need 220 ua.
 
analog&RFmodels said:
just remade the msmnts - they are good. if you look in IMXRT1060CEC.PDF which is the technical datasheet
111 pages 1.9 megabyte on page 26 table 13 they list some of the idle mode currents and if you assume that
on the T4 you are looking at the sum of the 3 currents they list for different pins (its all gotta ultimately come
from the 5v pin) they vary by mode from a handful of ma down to 20ua. only the power down modes are in
the ua's and keep in mind that there are other parts on the board - datasheet numbers are for 106x only.

so i think that if you need to retain data or status and only do a warm startup after snooze deepsleep or sleep
you are looking at 10-20 ma and if you can stand a total cold start each time the power down current (rtc
running so it knows when to "wake") you still need 220 ua.
Click to expand...
A cold start (via a reset I assumes) is perfect for me. Ill have a need later on to log data but only when the CAN bus is active and the T4 is running.
 
analog&RFmodels said:
so i think that if you need to retain data or status and only do a warm startup after snooze deepsleep or sleep
you are looking at 10-20 ma
Click to expand...

Wow, that's BAD! :(
It would render the T4 unusable for most of my projects.
I had hoped for at least T3.6-level sleep currents (hoped for even better power saving, since the chip is newer and maybe built on thinner litography).
 
XFer said:
Wow, that's BAD! :(
It would render the T4 unusable for most of my projects.
I had hoped for at least T3.6-level sleep currents (hoped for even better power saving, since the chip is newer and maybe built on thinner litography).
Click to expand...

found in my archives two documents - the previously mentioned IMXRT1060CEC.PDF and also IMXRT1060IEC.pdf
basically identical at a glance.

also sometime recently i described TLC hibernate current as 11-14 ua but that is WITH an LM2936 regulator,
so probable around 5 ua bare TLC. my old data shows bare T35 53 ua and bare T36 60 ua.

i am with you - too high for some battery/remote projects. one way out is use 2 cpu - TLC and T4 and
mosfet but that has its own down sides. it would help if no communication between them to save data,
maybe someone more tuned in to T4 would know if practical to save data in T4 eeprom before TLC powers
it down each time. i am glad that Duff has done all the hard work to give us the choice.
 
Can anyone shed light on which mode in snooze is parallel to stop mode?
I have tested an implementation of stop mode with wakeup from
Inturrupt in FlexCAN_T4 but when the T4 wakes up it continues from where it stopped. I don’t believe its doing a hard reset that I was expecting it to do, which means its not going into the lowest power consumption mode.
 
I've gotten around to testing the Snooze library on the T4.
Its goes into sleep mode as expected, but doesn't wake up.

Here is how I've set up the code
Code: 
#include <Snooze.h>
// Load Snooze drivers
SnoozeUSBSerial usb;
SnoozeDigital digital;

// install drivers to a SnoozeBlock
SnoozeBlock config(usb, digital);

void setup(){
    while (!Serial && millis() < 5000);
    Serial.begin(115200);
    digital.pinMode(20, INPUT, RISING); //pin, mode, type

}
const long SleepTimer = 30000; // Time to go to sleep
unsigned long startTime = 0;

void loop(){
    int who;
    if (millis() > startTime + SleepTimer){
      Serial.println("...Time to Sleep....");
      //who = Snooze.sleep( config );
      //who = Snooze.deepSleep( config ); 
      //who = Snooze.hibernate( config );
    }
}

I have a function that is interrupt driven from FlexCAN that rests the sleep timer variable as long as there is CAN activity.
So it does go to sleep as expected when the number hits 30 seconds in any of the three modes.
But when I apply 3.3v to pin 20 on the T4 - nothing happens. I can't get it to wake up.

Am I doing something wrong? Besides Snooze and FlexCAN_T4 im also using SPI and HX8357 libraries, and adding SD or SDFat later on too.
 
it it is any help, when i was testing T4 snooze i started with example code Duff had put in the Snooze library
such as some thing like DeepSleep_all_wakeups - you might compare your code with that - i was using
ARD 1.8.5,TD1.52

as i remember, as the lib is right now there are restrictions on hibernate but sleep and deepsleep will wake
up from many sources
 
analog&RFmodels said:
it it is any help, when i was testing T4 snooze i started with example code Duff had put in the Snooze library
such as some thing like DeepSleep_all_wakeups - you might compare your code with that - i was using
ARD 1.8.5,TD1.52

as i remember, as the lib is right now there are restrictions on hibernate but sleep and deepsleep will wake
up from many sources
Click to expand...

So I spent the last hour doing some tests.
All modes work on a T4.0 with no issues.
So I suspect another library is causing the issue.. I first added FlexCan to Hibernate_all_wakeups and initialized it - worked with the the digital pin
Next I added SPI - same as above, worked. Then I added HX8357 (display driver) - that killed it. So I kept the library and constructor but didn't initialize it - wake up worked.

So I guess I need to figure out what is breaking the digital wake up.
But your advise was helpful as it got me to this far.
 
Took some more measurements after soldering on a single 8 MB PSRAM.

5V supply, 600 MHz, empty loop(): 545 mW
5V supply, 24 MHz, empty loop(): 183 mW
5V supply, 600 MHz, WFI: 301 mW
5V supply, 24 MHz, WFI: 175 mW
Additional power draw if LED is on: 19 mW

3.7V supply, 600 MHz, empty loop(): 404 mW
3.7V supply, 24 MHz, empty loop(): 133 mW
3.7V supply, 600 MHz, WFI: 225 mW
3.7V supply, 24 MHz, WFI: 129 mW
Additional power draw if LED is on: 14 mW

Commentary: At 5 V, 600 MHz, WFI the measured power draw is 301 mW, up from 286 mW before adding the PSRAM. I'm not sure how different this is than the SYSTEM_IDLE conditions in 4.1.6 Table 13 of https://www.nxp.com/docs/en/nxp/data-sheets/IMXRT1060CEC.pdf but under those conditions it says it should be drawing 39ish mW.
 
One additional measurement: while memcpying from PSRAM to SRAM, at 600 MHz and 5 V supply, it draws 400 mW. This is quite a bit LESS than in an empty loop(), suggesting the cpu draws less power when it's waiting for a resource even if not explicitly told to go into a lower power state.
 
campbell - that is an interesting observation. in 1977 Motorola had a trademark term for their newest family
of processors - "systems on silicon" - wrong. but things like the ridiculously complex mpus on T3.6 and T4
along with all of the core code PaulS and others wrote and all of the library code written by many people-
now THAT'S a system on silicon. i am not surprised that the 1062 decides to "do things it has not explicitly
been told to" (the datasheet is ONLY 3600 pages long)- it is a short step to "i'm afraid i can't do that Dave"
 
You must log in or register to reply here.
Back
Top