Monitoring wakeup reasons of AR7594



we recently starting deploying our device to a number of test customers. Our device shall sleep (suspend to ram) most of the time, but it can be woken up by SMS and a couple of GPIOs.

While browsing through the logfiles from our test devices, we saw a couple of wakeups which we couldn’t explain. Some colleagues are already starting to blame EMF radiation.

So I was wondering if there is a way to track down the reason for each single wakeup:

  1. Can Legato notify our application after a wakeup occured?
  2. Can we query the wakeup reason from Legato or from the kernel then? (I noticed /sys/kernel/wakeup_reasons/last_resume_reason, but it seems to be always empty)
  3. Is there any kernel debug output we could activate to log the wakeup reason?



Hello Flo,

If useful, here is a command that list the active wakeup sources:

# cat /sys/kernel/debug/wakeup_sources | sed -e s/"^       "/"unnamed"/ | awk '{print $6 "\t" $1}' | grep -v "^0" | sort -n
active_since	name
138671	msm_otg

(here the remaining wakeup source if due to the USB cable still connected to the device.)

It should be possible to read proc file system from a Legato Application. You have to tune yout *.adef accordingly.



Hi KR,

thanks for your reply.

In the meantime we gathered some more hints:

  • we observed that these wakeups are happening more frequent at places with no/or bad network signal (e.g. underground parking).
  • the wakeups are not happening anymore if we switch on airplane mode (cm radio off)

=> so our conclusion right now is that these wakeups are caused by the baseband processor.

We are just wondering: is that an intended - to be expected - behavior? Does the baseband processor actively wakeup the application processor regularly in case network signal is bad?
Or are we suffering from some kind of electrical side-effect?

Any hints or experiences are highly appreciated.