The power consumption of Teensy's processor?

M

Miika

New member
Hi! I need to know the power consumption of the processor of my Teensy 4.0 board. Especially, I need to know the power consumption only when the processor is computing. My code is reading HW serial data, computing some stuff from the data, and sending the results via USB serial. The computation of the stuff takes about 1 millisecond. The data arrives at 100 Hz so I presume that 9 ms is spent on waiting for new data ("HWSERIAL.read()").

I measured the power consumption to be 500 mW but in my understanding, Teensy is always consuming this much, unless being at deep sleep.

Can I interpret that the "true" power consumption of our code, during that 1 ms period when it's doing the actual computations, is then at most 10 % of the 500 mW (so 50 mW)? And to get more precise measurement, I could first make a program that puts Teensy in deep sleep (e.g., using the deepSleep from the Snooze library), measure the power consumption of that (as it will be more than 0 mW), and use that as a benchmark to be subtracted from the 50 mW?

Or if not, what would be the suggested way to estimate the power consumption of the processor?
 
The power consumption will be dependant on the processor speed.

Whether the processor is reading hardware serial data, or waiting for hardware serial data or in an empty loop the power consumption will not change. It does not 'idle' down.

To reduce the power consumption you can either underclock the processor, or put it into sleep mode
 
I tried a quick test with Teensy 4.0 and my lab bench power supply with (not highly accurate) display of current. All settings defaults, so 600 MHz speed. Each test I uploaded code, then unplugged the USB cable and powered the Teensy 4.0 with 5.0 volts applied to VIN and GND.

Running this do nothing program: 102 mA
Code: 
void setup() {
}

void loop() {
}

Running this program which puts the CPU into idle mode: 57 mA

Code: 
void setup() {
}

void loop() {
  asm("wfi");
}
 
PaulStoffregen said:
I tried a quick test with Teensy 4.0 and my lab bench power supply with (not highly accurate) display of current. All settings defaults, so 600 MHz speed. Each test I uploaded code, then unplugged the USB cable and powered the Teensy 4.0 with 5.0 volts applied to VIN and GND.

Running this do nothing program: 102 mA
Code: 
void setup() {
}

void loop() {
}

Running this program which puts the CPU into idle mode: 57 mA

Code: 
void setup() {
}

void loop() {
  asm("wfi");
}
Click to expand...
Hmmm, Is the capacitance in the Teensy and power supply sufficient that you don't see negative-going spikes when the Systic timer fires off? Intermittent current spikes can result in hard-to-diagnose problems if the supply lacks the capability to handle the spikes. This really becomes an issue when you write to SD cards and the peak current jumps by 100-150mA for a few milliseconds.
 
I believe the many capacitors on Teensy 4.0 are sufficient.

But it is still on my workbench. I could fire up my oscilloscope and do a quick measurement. Not looking to turn this into extensive testing... which of the voltage rails would you like to see? The main 3.3V power? Or 1.25V CPU voltage? Or the 5V input from USB? Probably only going to do 1 screenshot... choose wisely...
 
I tried a quick measurement on the 3.3V rail, with AC coupled measurement so I can turn up the sensitivity. This is at 1ms/div, so if the systick wakeup were causing a significant disturbance in the voltage we could expect to see 10 of them in the screenshot.

1707527130545.png


My scope's noise floor leaves a lot to be desired. Maybe a scope with less noise could see something? On the other hand, if that something is only millivolts riding on the 3.3V rail, maybe not such a big deal?
 
I also quickly touched the bottom side test points. No voltage spikes visible, with this scope's not-wonderful noise floor. Going to have to take my word on those as both my hands are occupied during those tests, so a lot of extra effort would be needed to produce screenshots that look pretty much identical... just my scope's noise floor.
 
jmarsh said:
A "wfi" instruction on the Teensy 4 stops systick from running, by default.
Click to expand...
I stand corrected. Perhaps I was confusing the T4.1 with an older Cortex-M4 system from 10 years ago, which may have had a different implementation of systick.

On the principle of "trust, but verify", I wrote a more instrumented version of the minimalist sketch:
Code: 
const int pinLED = 13;

#define LEDON digitalWriteFast(pinLED, HIGH);
#define LEDOFF digitalWriteFast(pinLED, LOW);
#define LEDTOGGLE digitalToggleFast(pinLED);
void setup() {
  pinMode(pinLED, OUTPUT);

}

void loop() {
  // put your main code here, to run repeatedly:
  LEDON
  asm("wfi");
  LEDOFF
  asm("wfi");
}

As noted by @jmarsh, the LED does not blink (or glow, as systick at 1KHz would show up as pulses on a scope, but not to the eyeball).

However, if you compile with USB Serial, even though there are no references to the Serial device in the sketch, the LED will blink with each input character from a terminal. This indicates that peripheral clocks are still running and the peripherals can still generate interrupts.

In Teensy systems where I've used "wfi" to reduce overall power, there have always been multiple peripherals running to wake up the CPU, collect and store some data, then allow the CPU to go back to sleep with a "wfi" in loop. This is done most often using an IntervalTimer to control the collection rate. For collection at rates below 1K samples/second and buffering 8KB between SD card writes, using "wfi" in loop() can significantly reduce power consumption.
 
I repeated the test with this code.

Code: 
void setup() {
  pinMode(13, OUTPUT);
  CCM_CLPCR &= ~CCM_CLPCR_ARM_CLK_DIS_ON_LPM;
}

void loop() {
  digitalToggleFast(13);
  asm("wfi");
}

Power supply display now shows 68 mA. Some of that current is the orange LED blinking 50% duty cycle.

Here's what my scope sees. The green waveform is pin 13. Yellow is AC coupled view of 3.3V power on 50mV/div scale, same as before

file.png



1707603630947.png
 
PaulStoffregen said:
repeated the test with this code.

Code: 
void setup() {
pinMode(13, OUTPUT);
CCM_CLPCR &= ~CCM_CLPCR_ARM_CLK_DIS_ON_LPM;
}

void loop() {
digitalToggleFast(13);
asm("wfi");
}
Click to expand...
Running this code on T_4.1 or T_4.0 or T_MM not seeing any LED blink?
IDE 2.3 with TD 1.59.0 on Win 11
 
Perhaps the asm("wfi"); overrides anything done earlier in loop();

Are you looking at pin 13 with an oscilloscope? Perhaps setting pin 13 high (or low) in setup() would be instructive..
 
defragster said:
Running this code on T_4.1 or T_4.0 or T_MM not seeing any LED blink?
IDE 2.3 with TD 1.59.0 on Win 11
Click to expand...
Opps - My bad - the blink is 1 millisecond not a whole second - of course it is not a visible blink.

mborgerson said:
Perhaps the asm("wfi"); overrides anything done earlier in loop();

Are you looking at pin 13 with an oscilloscope? Perhaps setting pin 13 high (or low) in setup() would be instructive..
Click to expand...
I was taking a quick run with the code and wrongly expecting to see a 1 sec blink like this:
Code: 
void setup() {
  pinMode(13, OUTPUT);
  CCM_CLPCR &= ~CCM_CLPCR_ARM_CLK_DIS_ON_LPM; // Interrupt on sys_tick T_4.x
}

uint32_t lCnt=0;
void loop() {
  lCnt++;
  if (!(lCnt % 1000)) digitalToggleFast(13);
  asm("wfi");
}
 
I see. Thanks for the answers!

I'm still wondering... Could I speculate that if I will, some day, have an embedded system with Cortex-M7 processor or similar on it, and the processor would be able to deepsleep in between the new data arrivals, then the current consumption of the processor might be (less than) 10 % of the 102 mA? (See my original question.)
And on the other hand, subtracting the Teensy board's "idle current consumption" (57 mA), I get the "actual" current consumption of the Teensy's processor to be 102 mA - 57 mA = 45 mA?
And then finally, the current consumption of the processor in my ideal embedded system would be 10 % of 45 mA = 4.5 mA, or even close to it?
Or am I totally lost with this deduction?

(I know, I can lower the power consumption by underclocking the processor but I'd like it to compute the results as fast as possible to minimize the latency.)
 
Miika said:
And then finally, the current consumption of the processor in my ideal embedded system would be 10 % of 45 mA = 4.5 mA, or even close to it?
Click to expand...

This is really a question for the semiconductor vendor who would make the chip for your ideal embedded system.

This RT1062 chip on Teensy 4.x was (probably partially) designed by Freescale before they were acquired by NXP. Freescale was originally Motorola, so they had decades of experience designing high performance processors, going at least back to the 68000 series chips in the 1980s and PowerPC in the 1990s, and of course their modern iMX application processors. NXP also had a long history of commercially successful microcontroller designs before they acquired Freescale. My point is this chip comes from one of the world's largest semiconductor companies with vast experience designing very competitive chips.

I really doubt another company could achieve significantly different power consumption with the same level of CPU performance, if implemented in the same or a similar silicon process. Maybe a more advanced (smaller than 40nm feature size) silicon process could do better? I really do not know. But without any solid evidence, I would be pretty skeptical of imagining a 10X reduction.
 
Last edited:
Okay. Just to clarify, this "10X reduction" stemmed from the idea of the processor waiting for new data 90 % of the time, hence processing the data only 10 % of the time. But I get it that it's oversimplified to infer such reduction.
 
You really need to run tests on actual hardware. As we've seen already in this thread, small details matter.

The peripherals (and/or other stuff) are consuming as much power as the CPU. You wrote "deepsleep in between the new data arrivals" in your question. What will recognize the data arrival to wake the CPU? Presumably you'll need peripherals active to accomplish data reception.

You can probably do better than these very simple tests with some effort configuring peripherals and clocks and special low power features. But if there's one thing these quick tests show, you definitely should not neglect the power needed by peripherals and other stuff while the CPU sleeps.
 
You must log in or register to reply here.
Back
Top