How to check the reason for wakeup from idle and GPIO interrupt unresponsive in idle

RE: How to check the reason for wakeup from idle and GPIO interrupt unresponsive in idle

hmolesworth — Thu, 29 Feb 2024 15:41:03 GMT

It is confusing, but literally every hardware event in the data sheet labelled "EVENTS_blahblah" (ie tons of them) will wake up from SYSTEM_ON if and only if the corresponding "ENABLE" register for the peripheral with the event is enabled and the conditions for the hardware event occurs. This has nothing to do with interrupts whether enabled or not; additionally a hardware event under active and enabled conditions can trigger an interrupt if and only if the corresponding interrupt is also enabled. A hardware Event can be triggered by hardware (eg uart rx character), implicitly by software (eg setting Tasks-Start and getting Events-Started, or explicitly by software (eg setting an Event in the EGU).

Many hardware events once triggered in an enabled peripheral will keep generating interrupts (if enabled) and waking up from SYSTEM_ON until the hardware event is explicitly cleared (aka level-sensitive not edge-sensitive). If not enabling interrupts for a specific hardware event the hardware event must be cleared in foreground code otherwise remaining in SYSTEM_ON sleep is not possible. It is possible to write code which checks every peripheral for 1) is it enabled and 2) are there any active hardware events for that peripheral; yes a pain.

This is effectively nothing to do with Zephyr, by the way, other than when Zephyr secretly clears the events for you. Normal practice is to clear the events within interrupts; which implies the interrupts corresponding to each possible enabled event must be enabled and embed the correct code.

RE: How to check the reason for wakeup from idle and GPIO interrupt unresponsive in idle

Bjoern Bialy — Thu, 29 Feb 2024 15:17:09 GMT

For me the problem is what even qualifies as a wakeup from the SYSTEM ON idle. In the data sheet it just says "wake on any event", but what kind of event? If it were really any event, then the MCU would never keep sleeping, as something will always happen.

RE: How to check the reason for wakeup from idle and GPIO interrupt unresponsive in idle

Jørgen Holmefjord — Thu, 22 Feb 2024 14:16:40 GMT

Hi,

[quote user=""]The first problem is now that I don't even know what triggered the wakeup from idle. Is there any way to check the wakeup reason? Debugging does not help here as the reason is obfuscated by the OS. Maybe a register value?[/quote]

There are generally two power saving modes in nRF52833:

Reason for wakeup from SystemOFF mode can be read from the RESETREAS register.

Since you are using PM_STATE_SUSPEND_TO_IDLE, the system will likely enter SystemON mode. In this mode, every HW event will wake the CPU and continue execution. Events will be visible in the EVENTS_* register in each peripheral, but if you do not know which peripheral caused the wakeup, it is not trivial to find the actual event. Are you only seeing this behavior when debugging the application, or does it also wakeup in normal operation mode?

Technically it would be possible to enable interrupts for EVENTS_SLEEPEXIT event with high interrupt priority and step through the application to see what code is executed after wakeup, but I have not tested this in nRF Connect SDK.

[quote user=""]For the second problem I am not even sure how the GPIO interrupt is supposedly linked to the wakeup. Is there a resource with an appropriate example? Most examples with the interfaces used in the code only handle the power down but not the power up, or it is thread triggered and not by interrupt.[/quote]

The interrupt handling is primarily done in the lower layer driver implementations in Zephyr, and events are passed from driver to application handlers to take appropriate action.

Best regards,
Jørgen