This application note explains how to use the Linux low power mode (the so-called "suspend to RAM") on the Emcraft Systems STM32F7 System-On-Module (SOM). When suspended, the SOM consumes approximately 2 mA @3.3V, at the same time providing instantaneous wake-up on configured I/O events, such as GPIO triggers.
Support for the low power mode is enabled in the standard rootfs project available from the Emcraft software distribution and installed on each module shipped by Emcraft. With Linux booted up to the shell, and 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 is around 130 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 170 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.004 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.004 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
At this time, the power consumption goes down dramatically and should measure at less then 2.5 mA. Press the S2 User Button on the SOM-BSB-EXT board to wake the system up:
PM: suspend of devices complete after 4.036 msecs
PM: late suspend of devices complete after 3.523 msecs
PM: noirq suspend of devices complete after 1.714 msecs
PM: noirq resume of devices complete after 1.210 msecs
PM: early resume of devices complete after 1.634 msecs
PM: resume of devices complete after 17.160 msecs
Restarting tasks ... done.
/ #
Note also that the system automatically restores the TCP/IP stack on wake-up from the suspended state. The following test illustrates this:
/ # ping 192.168.1.1&
[1] 50 ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=2.757 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=1.296 ms
64 bytes from 192.168.1.1: seq=2 ttl=64 time=1.290 ms
/ # echo mem > sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.009 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.004 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: suspend of devices complete after 4.704 msecs
PM: late suspend of devices complete after 3.406 msecs
PM: noirq suspend of devices complete after 1.704 msecs
PM: noirq resume of devices complete after 1.146 msecs
PM: early resume of devices complete after 1.453 msecs
PM: resume of devices complete after 17.201 msecs
Restarting tasks ... done.
stm32-dwmac 40028000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
64 bytes from 192.168.1.1: seq=7 ttl=64 time=1.288 ms
64 bytes from 192.168.1.1: seq=8 ttl=64 time=1.280 ms
64 bytes from 192.168.1.1: seq=9 ttl=64 time=1.283 ms
Similarly, if you were running any operations with the on-module Flash prior to suspending the system, these operations will automatically resume when the system wakes up. The following test illustrates this:
/ # flash_eraseall -j /dev/mtd2
Erasing 128 Kibyte @ 5e0000 - 100% complete.Cleanmarker written at 5c0000.
/ # mount -t jffs2 /dev/mtdblock2 /mnt
/ # mkdir /m
/ # mount -o nolock 192.168.1.102:/mnt/work/emcraft/bsp/nfs /m
/ # ls /mnt
/ # ls -l /m/networking.uImage
-rw-r--r-- 1 1000 1000 2228848 Oct 5 2016 /m/networking.uImage
/ # time cp /m/networking.uImage /mnt &
[1] 61 time cp /m/networking.uImage /mnt
/ # echo mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.002 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.014 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: suspend of devices complete after 4.057 msecs
PM: late suspend of devices complete after 2.995 msecs
PM: noirq suspend of devices complete after 1.870 msecs
PM: noirq resume of devices complete after 2.902 msecs
PM: early resume of devices complete after 1.571 msecs
PM: resume of devices complete after 17.480 msecs
Restarting tasks ... done.
stm32-dwmac 40028000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
real 0m 6.74s
user 0m 0.00s
sys 0m 6.09s
[1] Done time cp /m/networking.uImage /mnt
/ # ls -l /mnt/networking.uImage
-rw-r--r-- 1 root root 2228848 Jan 1 00:07 /mnt/networking.uImage
The default trigger used for system wake-up is the S2 User Button on the EXT-SOM-BSB development board. It is connected to the PH.2 GPIO on the STM32F7. The
pin-controller and
inputs nodes in the
rootfs.dts file configure this GPIO appropriatelly:
- The pinctrl_inputs node in pin-controller defines the GPIO pull-up settings;
- The input@1 node in inputs specifies the gpio-key,wakeup property to enable wake-up from this pin;
...
pin-controller {
gpio {
pinctrl_inputs: ins {
st,pins {
S2.but = <&gpioh 2 IN PULL_UP
PUSH_PULL LOW_SPEED>;
};
};
};
};
inputs {
compatible = "gpio-keys";
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_inputs>;
input@1 {
label = "Wake-up button (S2)";
gpios = <&gpioh 2 GPIO_ACTIVE_LOW>;
linux,code = <116>;
gpio-key,wakeup;
};
};
...
