Linux Low-Power Mode on Kinetis Print


This application note explains how to use the Linux low-power mode (the so-called "suspended to RAM") on the Emcraft Systems Kinetis K70/K61 System-On-Module (SOM). When suspended, the SOM consumes as little as 600-700 uA @3.3V, at the same the providing instantaneous wake-up on configured I/O events, such as RTC alarm triggers or activity on UART RX line.

All the tests described below were run on the Kinetis SOM Starter Kit using a SOM-K61-xETH SOM (the K61 System-On-Module with no on-module Ethernet PHY installed). In this setup, the Ethernet PHY on the TWR-SOM-BSB Rev 2A baseboard is used to provide Ethernet connectivity for the SOM. A battery is installed into the battery holder on the back side of the TWR-SOM-BSB baseboard to provide back-up power for the Kinetis RTC. A Micro-SD is plugged to the SD Card holder on the TWR-SOM-BSB baseboard to provide removable storage for the tests.

To allow measuring power consumption of the System-On-Module, a digital ampmeter is connected to the TWR-SOM-BSB baseboard. To connect a ampmeter to the kit, apply the following reworks to the baseboard. Please note that using such connection to an ampmeter, measurements will include power consumption only by the Kinetis System-On-Module itself and not by any components residing on the baseboard.

  • Solder out the R38 0 Ohm resistor;
  • Solder the ammeter wires to the R38 pads as shown in this picture.

The following picture illustrates the above hardware platform:


Click to enlarge

Customers of the Emcaft Systems Kinetis SOM Starter Kit may download a Linux low-power demo project from the following page: https://www.emcraft.com/suspend/

Here is how you install the demo project to the Emcraft Systems Kinetis Linux cross-development environment. On the Linux host, from the top of the Kinetis software distribution activate the cross-development environment:

-bash-3.2$ . ./ACTIVATE.sh
-bash-3.2$ echo $MCU
K70
-bash-3.2$

Go to the projects tree and unpack the demo project:

-bash-3.2$ cd projects/
-bash-3.2$ tar xvf suspend.tgz
suspend/
suspend/local/
...

Go to the demo project directory and build the bootable Linux image (suspend.uImage):

-bash-3.2$ cd suspend
-bash-3.2$ make
...
-bash-3.2$

Install the newly built suspend.uImage to the Kinetis SOM as described in Installing Linux Images to Flash. Note that if you are using the SOM with no on-module Ethernet PHY (the "SOM-K70/K61-xETH" partnumbers), you will have to close 1-2 on the jumper JP1 on the TWR-SOM-BSB Rev 2A baseboard. This will connect the on-baseboard Ethernet PHY between the RMII interface of the Kinetis and the RJ-45 connector (P5). If you are using the SOM with the on-module Ethernet PHY (the "SOM-K70/K61" partnumbers) leave 1-2 open on JP1 in order to connect the RJ-45 connector to the on-module PHY.

Next reset will boot the demo project from the on-module Flash:

...
init started: BusyBox v1.17.0 (2014-06-13 15:33:14 +0400)
mmc0: new SD card at address c4ae
mmcblk0: mmc0:c4ae SU02G 1.84 GiB
mmcblk0:
p1
~ #

As a first step in the demo, let's set the system time and the Kinetis RTC to the "wall clock" values. Strictly speaking, this is not required for the low-power operation, however a typical embedded application will want to maintain the "real-life" time and date:

~ # date -s "2014-06-17 15:35"
Tue Jun 17 15:35:00 UTC 2014
~ # hwclock -w

Validate that the RTC and the system time both have correct values:

~ # hwclock; date
Tue Jun 17 15:35:21 2014 0.000000 seconds
Tue Jun 17 15:35:22 UTC 2014
~ #

Note that on each system bootstrap, Linux will automatically read the system time from the Kinetis RTC so you will always have the correct time and date, even after power outages.

Ok, Linux is up and running, however with no commands entered from the interactive shell or a shell script, the system is idling awaiting user input or some other I/O events. The power consumption of the SOM (the SOM-K70/K61-xETH configuration) is around 100 mA on the average at such times:

If you create some load for the system, the power consumption will go up. For instance, using the following shell commands to create an endless command loop:

~ # while echo hey > /dev/null
> do
> echo Linux is running
> done
Linux is running
Linux is running
...
^C

~ #

you should measure the SOM power consumption of around 140 mA:

Now, let's put the system into the low-power mode. This is done by running the following command:

~ # echo mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s) (use no_console_suspend to debug)

At this time, the power consumption goes down dramatically and should measure between 0.6 to 0.8 mA:

Touch any key on the serial console terminal to wake the system up:

PM: suspend of devices complete after 0.846 msecs
PM: late suspend of devices complete after 0.227 msecs
PM: early resume of devices complete after 0.022 msecs
PM: resume of devices complete after 83.704 msecs
Restarting tasks ...
done.
~ #

This will wake Linux up and return the power consumption to a 100 mA ballpark.

Note that besides using activity on UART RX to wake Linux up, you can also use an RTC alarm to wake the system up on a predefined schedule. The following commands will put the system to the low power and then wake it up in 5 seconds:

~ # echo +5 > /sys/class/rtc/rtc0/wakealarm; echo mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
fec_stop : Graceful transmit stop did not complete !
PM: suspend of devices complete after 0.875 msecs
PM: late suspend of devices complete after 0.226 msecs
PM: early resume of devices complete after 0.022 msecs
PM: resume of devices complete after 83.661 msecs
Restarting tasks ...
done.
~ #

Let's try a more complex scenario. The following example provides basic implementation for a typical workflow in a microcontroller application, specifically: system is in low power most of the time but wakes up on a predefined schedule or when there is a I/O event to be processed. In this example, we mount a FAT32 file system on the inserted SD Card to provide removable storage for application data logs:

~ # mount /dev/mmcblk0p1 /mnt
~ # ls -lt /mnt
~ #

The demo project (suspend.uImage) provides a shell script, which we will use to put the system into low-power mode, with time stamps logged onto the mounted SD Card before and after the low-power suspend:

~ # cat /str.sh
#!/bin/sh

echo Suspending at `date`
echo Suspending at `date` >> /mnt/log.file
echo 0 > /sys/class/rtc/rtc0/wakealarm
echo +$1 > /sys/class/rtc/rtc0/wakealarm
echo mem > /sys/power/state
echo Woke up at `date`
echo ""
echo Woke up at `date` >> /mnt/log.file
echo "" >> /mnt/log.file

~ #

Using that script in a shell loop will keep your system in low-power mode (sub 1 mA power levels) except for brief periods of scheduled activity (when the power consumption spikes to 100 mA levels). Alternatively, pressing any key on the system console will wake the system up immediately:

~ # while echo hey > /dev/null; do ./str.sh 10; done
Suspending at Tue Jun 17 16:03:46 UTC 2014
PM: Syncing filesystems ...
done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
fec_stop : Graceful transmit stop did not complete !
PM: suspend of devices complete after 0.874 msecs
PM: late suspend of devices complete after 0.228 msecs
PM: early resume of devices complete after 0.021 msecs
PM: resume of devices complete after 83.693 msecs
Restarting tasks ...
done.
Woke up at Tue Jun 17 16:03:55 UTC 2014
...

Press ^C on the system console to interrupt the loop and validate that the time stamps have indeed been stored on the SD Card:

~ # cat /mnt/log.file
Suspending at Tue Jun 17 16:03:46 UTC 2014
Woke up at Tue Jun 17 16:03:55 UTC 2014

Suspending at Tue Jun 17 16:03:55 UTC 2014
Woke up at Tue Jun 17 16:04:05 UTC 2014

Suspending at Tue Jun 17 16:04:05 UTC 2014
Woke up at Tue Jun 17 16:04:15 UTC 2014

Suspending at Tue Jun 17 16:04:15 UTC 2014
Woke up at Tue Jun 17 16:04:25 UTC 2014

...

Note that if you run the above tests on the SOM with the on-module Ethernet PHY, the power consumption should be around 2 mA while in suspend. Note further that the current release of the Linux BSP does not provide full recovery of the Ethernet link. In other words, Ethernet connectivity will be not available after a first suspend. Hit the reset button on the TWR-SOM-BSB baseboard to allow the Ethernet interface to recover.