Hi,
I need to configure an nRF52832 to wake up periodically from SYSTEM_ON and SYSTEM_OFF and, also, when a GPIO pin changes.
Where can I find sample code and docs for this?
I'm using nRF Connect SDK version 1.9.1 and Visual Studio Code.
BR
Hi,
I need to configure an nRF52832 to wake up periodically from SYSTEM_ON and SYSTEM_OFF and, also, when a GPIO pin changes.
Where can I find sample code and docs for this?
I'm using nRF Connect SDK version 1.9.1 and Visual Studio Code.
BR
Hi
First off, to clarify. When the nRF52832 (or any of our devices are in "system OFF") the CPU and all peripherals are completely turned off, so it can't be waken up periodically from the RTC in system OFF mode. That will only be possible in system ON mode. To wake up the device from System OFF mode you have to use an external source, like when a button is pressed or have an external timer going that trigs a GPIO every X amount of time.
We have a sample project showing how you can put the nRF5x series devices into system OFF here.
We don't have an official example showing how to use the RTC in the nRF Connect SDK at the moment, but one of my colleagues made this example for the RTC on the nRF91. Since the same driver is used in the nRF52 series, it should be pretty straight forward to modify to work on an nRF52832 as well. Alternatively, you can check out the Zephyr kernel timer that can perform an application-defined action after a specific time limit is reached.
Best regards,
Simon
In regard to the power off sample project, I found out that calling pm_power_state_force() and checking immediately after it returns would always be interpreted as an error since nothing was done in that function but setting some flags. Then I came across this recent thread here [^] dealing with same issue, a bug in the sample code.
It was reported [^] to zephyr project and the solution is straight forward (see here [^]), the thread must be put to sleep, as simple as calling k_sleep(K_SECONDS(SLEEP_S)) after the call to pm_power_state_force(), so the power manager detects the idle task is running and enforces the power off mode.
Now I'm dealing with some strange behaviour I see in the current consumption while in power off in the power profiler (PPK-II). Current is not flat and peaks at an approximately constant pace.

Before going to power off, I disable the console's uart with a call to pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND), where cons is const struct device *cons = device_get_binding(DT_LABEL(DT_CHOSEN(zephyr_console))).
Is there any reason to expect such behaviour?
In regard to the power off sample project, I found out that calling pm_power_state_force() and checking immediately after it returns would always be interpreted as an error since nothing was done in that function but setting some flags. Then I came across this recent thread here [^] dealing with same issue, a bug in the sample code.
It was reported [^] to zephyr project and the solution is straight forward (see here [^]), the thread must be put to sleep, as simple as calling k_sleep(K_SECONDS(SLEEP_S)) after the call to pm_power_state_force(), so the power manager detects the idle task is running and enforces the power off mode.
Now I'm dealing with some strange behaviour I see in the current consumption while in power off in the power profiler (PPK-II). Current is not flat and peaks at an approximately constant pace.

Before going to power off, I disable the console's uart with a call to pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND), where cons is const struct device *cons = device_get_binding(DT_LABEL(DT_CHOSEN(zephyr_console))).
Is there any reason to expect such behaviour?