Close

Some Power Measurements

A project log for MAX32660 Motion Co-Processor

Super-small, ultra-low-power 96 MHz Cortex M4F co-processor manages sensors and processes data allowing the MCU host attend to other things.

Kris WinerKris Winer 08/25/2018 at 01:155 Comments

August 24, 2018

First some housekeeping. I learned from Maxim that there was a typo in their data sheet (since corrected) and that the MAX32660 roadmap only includes three device packages: the 1.6 mm x 1.6 mm WLCSP-16, the 4 mm x 4 mm TQFN-20, and the 3 mm x 3 mm TQFN-24 that we are using in our prototype development. No 1.6 mm x 1.6 mm TQFN-16 package :<  We will have to make do with the 3 mm x 3 mm version or bite the bullet and go for more expensive fab methods (or zGlue) and use the WLCSP for minimal size. For the moment we will stick with the 3 mm x 3 mm TQFN-24 IC since it is easy to assemble and has lots of pins for firmware development work.

I have heard that a revision to this TQFN-20 package is due in a month or so that corrects/improves the silicon. Still trying to find out more details but the changes should include improvements in power usage. That is what I want to discuss now.

I finally (with Maxim's help) figured out the low power sector of the MAX32660 and have started doing some preliminary power testing. The low power scheme is a bit different from the STM32L4. There are three core voltages that can be selected which are equivalent to setting the high-speed clock to 96 MHz (OVR= 1.1 V, default), 48 MHz (OVR = 1.0 V), or 24 MHz (OVR = 0.9 V). The actual voltage is an allowed range and lowering this range effectively selects a lower clock speed. Then, for each range the clock can be further divided by 2^N where N can range from 0 to 7. It sounds complicated but in fact it is straightforward to select amongst these limited choices and the effect on average power usage can be quite large. For example, with a simple blink program at 96MHz (OVR = 1.1 V) default the MAX32660 uses 11.1 mA (when the led is off but MCU active). At the lowest core voltage setting (OVR = 0.9 V, 24 MHz) the blink program uses 5.1 mA when using low power sleep mode between RTC alarm interrupts. Let me explain this...

The way most programs we will be using work is to configure everything at the start of the program (like setup in Arduino) and then run a forever loop where all actions are interrupt driven (sensor data ready interrupts, timer interrupts, RTC alarm interrupts, etc). This is so when an interrupt is not being serviced, the MCU can sleep in a low-power state.

So for the simple blink program, we set the RTC alarm to trigger an interrupt every two seconds. The interrupt wakes the MAX32660, it takes some action (turns the led on or turns the led off) and then goes back into SLEEP mode. The program uses 11.1 mA at 96 MHz without invoking SLEEP mode between interrupts and 9.6 mA when SLEEPing between interrupts. The average power drops to 5.1 mA when running at 24 MHz with SLEEP between interrupts. This demonstrates the benefit of the SLEEP scheme as well as selecting the clock speed appropriate to the task, and it just makes common sense to take advantage of these features as a general strategy.

The wake up time from SLEEP mode is very fast (a few us). There is also a DEEPSLEEP mode with a somewhat longer wakeup time (~1 ms), and using this instead of SLEEP at 24 MHz (OVR = 0.9 V) drops the average power down to 175 uA. About 6 uA of this is just due to the sensors in power down mode on the custom board. This (~169 uA) sounds like an impressive power savings and it is much lower than 5.1 mA, but the data sheet says we should be at ~4 uA. So some more fine tuning is required like turning off peripherals that aren't needed (like SWD) and making sure all GPIOs not being specifically used are tri-stated, etc. to get the power as low as possible.

Also, the pending silicon revision should reduce this 1 ms wake up time considerably. Still lots of work to do to get the power sector under control. The goal is 1 mA or less when running the motion co-processor in its normal mode, meaning accel and gyro at 208 Hz, mag at 100 Hz, and barometer at 10 Hz with quaternions at the rate of the gyro.

The EM7180 uses ~300 uA on average and the ST sensors 650 uA under these conditions so we want to be able to run the MAX32660 with this same level of power usage and still produce high-accuracy absolute orientation estimates (<1 degree rms heading error). Of course, the MAX32660 can run at much faster fusion rates than the EM7180, but it needs to be able to run at the same or lower average power usage. This is the twin challenge that we expect our continuing development efforts to meet.

Preliminary testing using SLEEP mode between interrupts shows the MAX32660 plus ST sensors at the above conditions with the Madgwick fusion algorithm uses about 4.3 mA at 24 MHz (OVR = 0.9 V). Until the silicon revision, it is not clear it is advisable or even possible to run at such sample rates with a 1 ms delay (wake up time)  between active and DEEPSLEEP modes. Edit: did it anyway, got DEEPSLEEP to work with the ST sensors and measure 3.3 mA average current at 24 MHz, so better but a lot more work to do...

So we are far from our power usage goal, but these are still early days...what fun!

Discussions

geoffreymbrown wrote 10/29/2018 at 12:33 point

I'm very interested in how low you can push the  power levels.  We've been working on an adxl362/stm32l4 board and get 2uA in stop2 with adxl362 in activity detection mode and 4uA with the adxl362 running at 100Hz.  Of course the stm32l4 uses more energy when running (we wake on the rtc).   The max32660 datasheet provides fairly confusing information about the actual power consumption.

  Are you sure? yes | no

Ken Elkabany wrote 10/10/2018 at 09:09 point

How did you decide to sample the barometer at 10Hz? Was that the optimal point you found trading off between MCU power consumption and sensor fusion performance, or was there another factor?

  Are you sure? yes | no

Kris Winer wrote 10/10/2018 at 16:54 point

It depends on the application. Generally pressure and temperature do not change very fast unless the sensor is flying around the room.

  Are you sure? yes | no

Kris Winer wrote 08/25/2018 at 15:13 point

The error I am quoting is the heading error not gyro error. The gyro, accel and mag data are fused into a quaternion that contains all of the information about the absolute orientation of the sensors. Euler angles can be derived from the quaternions (as well as other interesting estimates like gravity and linear acceleration). The Euler angles are the traditional yaw, pitch, and roll or heading, pitch, and roll used in airplanes (called AHRS, Attitude and Heading Reference System, see https://en.wikipedia.org/wiki/Attitude_and_heading_reference_system). Turns out pitch and roll are relatively easy to estimate to +/- 1 degree rms accuracy even using just an accel and gyro. The accel compensates for the gyro drift (in degrees per hour or minute) but because there is only one reference direction (gravity down) the heading will drift by degrees per minute or second depending on the sensors. By adding the magnetometer and an orthogonal reference (true North) the heading is stabilized and absolute orientation can be estimated with high accuracy when the sensors are high-quality and properly calibrated. Accurate heading estimation is hard to do, which is why I focus on heading error. You can read more about this here: https://github.com/kriswiner/MPU6050/wiki/Affordable-9-DoF-Sensor-Fusion.

  Are you sure? yes | no

Simon Merrett wrote 08/25/2018 at 06:42 point

Very interesting Kris, thanks for taking the time to post this log. I have a question about your description of gyro errors: you use degrees rms but I've heard gyro error represented as an angular drift over a time period (e.g. degrees per hour). Is there a time component assumed in your unit or are you describing a different way of representing the error? Keen to learn more about this! 

  Are you sure? yes | no