When trying to register a wakeup alarm using rtc0 with wakealarm file to wakeup from suspend to ram I observed that something is setting an alarm more or less each pm resume to usually 1h0m27s once the first wakeup alarm set by sierra_monitor module ends its job according to startup_timer parameter which is be default set to 120sec in devicetree.
I also observed that if we reach this rtc time an alarm is indeed triggered and another one is set 1 hour later.
Just in case I precise that it’s the same behavior with or without our custom app installed.
To see that we enable debug in kernel with :
echo ‘file qpnp-rtc.c +p’>/sys/kernel/debug/dynamic_debug/control
I would like to know who register this alarm and if possible if we can avoid this alarm registration ?
As it also happens when the system get out of suspend to ram on is own to try to enter it again asap => resume => set alarm again to 1h which erase our alarm registration from user space and in some case erase info from rtc0/wakealarm file whereas we can see in kernel log that the a wakeup alarm has been set.
Hello
We could reproduce it with a generic SPK R14.1 on a clean WP7702 module.
Prerequis:
Install SPK generic firmware R14.1
Add following lines in /etc/init.d/startlegato.sh to enable rtc debug and set a wakeup alarm to 180sec since boot:
echo “file qpnp-rtc.c +p” >/sys/kernel/debug/dynamic_debug/control
echo 180 > /sys/class/rtc/rtc0/wakealarm
Also put a SIM card with the right apn (didn’t check if there is an impact or not)
Steps:
Power on the board with out USB plugged
Wait for 5min to wait for sierra_monitor to manage its 120sec delay from boot and its wakealarm auto set 120 later at each pm suspend until it reaches 120sec from boot which can be at max 240secs + N secs
Plug USB to the board and check logread, a wakeup alarm should have been set to 1hour from boot once the first alarm expired and system is subject to a pm_resume which was not expected
By the way it would be nice to know what triggers these unexpected wakeup but firstly I would like to know who set this alarm to 1Hour.
Not tested in R15.1 as our products are already in R14
Lines are in the log file put here they are:
echo “file qpnp-rtc.c +p” >/sys/kernel/debug/dynamic_debug/control
echo 180 > /sys/class/rtc/rtc0/wakealarm
Nothing set with AT command. The logs shared are from a test with a fresh new module which has only been flashed with firmware R14.1 spk Sierra Wireless
The purpose of adding these commands in init script is to automatically activate rtc debug and to register a wakeup alarm before system tries to go to suspend to ram automatically since USB should not be plugged to the board as I described in the test case scenario
The purpose of the whole test is to show that an rtc alarm is set and modified by the system to expire 1h from boot. And I want/need to know who does this and if it can be modified or stopped.
As I previously tried to explain, following the test case, if no USB is plugged since boot, the system will try to goes into suspend to ram as soon as sierra_monitor kernel module stops to prevent system to go in. When this module is active during the 120secs since boot (which is a parameter) it will erase the first wakealarm set to 180 from the init script and set it to 120sec in the future each time system try to enter in suspend to ram. The module stops to do that once the system is woken up since more than 120sec.
After that at next wakeup/sleep sequence this unexpected wakealarm to 1h is set and I want to know who does that.
To be able to see that on your side it’s mandatory to not plug the usb until you want to check the logs and that no wake_lock are active which should be the case if default R14.1 + default legato is flashed
WakeAlarm command is working fine until unexpected wakeup/sleep sequence happen because it reconfigure the rtc wakeup alarm
Are you able to say where is done this and if it can be modified ?
As previously said, it’s not possible for us to update the firmware of already living products. So either we are able to do something on R14.1 or we are going to find another way on side.
AT!POWERWAKE and AT!POWERMODE are only returning error even if we send the ENTERCND command first
