|Linux Low-Power Mode on Kinetis|
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.
The following picture illustrates the above hardware platform:
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
Go to the projects tree and unpack the demo project:
-bash-3.2$ cd projects/
Go to the demo project directory and build the bootable Linux image (suspend.uImage):
-bash-3.2$ cd suspend
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:
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"
Validate that the RTC and the system time both have correct values:
~ # hwclock; date
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
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
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
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
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
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
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
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
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.