How to configure to wake up from SYSTEM_ON and SYSTEM_OFF using RTC2 (periodically) and from GPIO pin change

RE: How to configure to wake up from SYSTEM_ON and SYSTEM_OFF using RTC2 (periodically) and from GPIO pin change

Simonr — Thu, 05 May 2022 12:53:33 GMT

This looks much better. The spikes look like the auto-controlled refresh mode being active, where the frequency depends on the current being drawn on the regulator output. In system OFF mode the refresh interval is at 100-150ms.

The current consumed during refresh modes are documented here. Note that the numbers in the PS are typical numbers only, and there will be device to device variations.

Best regards,

Simon

RE: How to configure to wake up from SYSTEM_ON and SYSTEM_OFF using RTC2 (periodically) and from GPIO pin change

V.Lorz — Wed, 04 May 2022 16:20:03 GMT

Hi, let's see if it is better now.

I inserted the coin cell battery, PPK-II in Ampere meter mode and connected like below:

I started capturing data and pressed BTN1 for taking the SoC out from POWER_OFF.

Here is how it looks like (full data set and close-up):

The spikes are periodic, and in between them the current seems to fall to what is expected. I suppose the noise originates in the PPK's current sense signal-chain and the long sensing wires, as expected.

The full dataset is attached here.

According to your experience/knowledge, what's the origin of those peaks? They have a fast rise time and a slow exponential-like decay, like in a low-ESR capacitor charge discharge cycle.

Thanks again.

devzone.nordicsemi.com/.../ppk_2D00_20220504T160437_2D00_data_2D00_logger.zip

RE: How to configure to wake up from SYSTEM_ON and SYSTEM_OFF using RTC2 (periodically) and from GPIO pin change

Simonr — Wed, 04 May 2022 12:43:40 GMT

If you have matched the voltage for the PPK and DK (~2.7V) in the first image that measurement should be correct, but it looks very strange indeed, and there shouldn't be any current measurements looking like this, so it does indeed look like the PPK might have some issue with it. To confirm, can you try with the PPK2 in Ampere mode as well, using a clean supply to power the DK as I explained in my last reply.

You can't power the DK just from the PPK like in image 2, that won't result in a correct current measurement or behavior.

Best regards,

Simon

RE: How to configure to wake up from SYSTEM_ON and SYSTEM_OFF using RTC2 (periodically) and from GPIO pin change

V.Lorz — Tue, 03 May 2022 11:03:41 GMT

Hi,

I'm starting to think on the possibility of PPK/DK not working properly for some reason (maybe me).

Here are how I connected the PPK-II and the nRF52 DK for Source Meter mode. One with the USB connected to the DK, the other without.

Here attached are also the ppk capture files.

I have SB9 open in the DK and uploaded same project I attached previously.

I configured VOUT for 2.75V in the PPK, but I've seen a strange bahaviour, the SoC is not reset when powered from the PPK only. I tested from 2.0V to 3.2V with same results: I needed to power from USB with the PPK VOUT active, then remove the USB plug. After doing this the app behaved like expected, wake up on pressing BTN1, then going to "low power".

I didn't check voltage across P0.21/RESET, but I think the nRF is not been reset when the SAM (U2) is not powered.

Enabling and disabling power output from the PPK did enable and disable the PPK voltage output, checked with voltmeter at DC4 pin (C10 in the DK) and had 1.24V, and also had the same VOUT voltage at VDD pin (C9 in the DK).

Is the PPK-DK wiring correct? Am I missing something? Is there any need to change anything the compiler/project options for the board so anything else is initialised in the silicon?

devzone.nordicsemi.com/.../data_2D00_logger_2D00_source-meter-_2D00_-2750mV-_2B00_-USB.zip

devzone.nordicsemi.com/.../data_2D00_logger_2D00_source-meter-_2D00_-2750mV.zip

RE: How to configure to wake up from SYSTEM_ON and SYSTEM_OFF using RTC2 (periodically) and from GPIO pin change

Simonr — Tue, 03 May 2022 07:17:14 GMT

These are spikes caused by noise from the USB port.

You have two options, either unplug the USB cable and power the DK with a clean supply on the power supply header. Then you can measure current going through the current measurement header with the PPK2 in ampere meter mode.

Alternatively you can leave the USB plugged in, but then you will have to power the nRF52 from the PPK using source meter mode. Connect the GND from PPK to GND on the DK, and VOUT from the PPK to the nRF52 side of the current measurement header (the pin closest to the debug out header). Then you need to adjust the PPK2 output voltage to match the VDD voltage on the DK exactly. I believe it should be around 2.7V.

Best regards,

Simon

RE: How to configure to wake up from SYSTEM_ON and SYSTEM_OFF using RTC2 (periodically) and from GPIO pin change

V.Lorz — Mon, 02 May 2022 14:09:13 GMT

Simonr, please find here the data captured and the project for reproducing the behaviour.

It was not possible for me to compile neither the original project nor a new project created using the sample as a template. This project uses snippets from the original code.

devzone.nordicsemi.com/.../hello_5F00_off.zip

devzone.nordicsemi.com/.../power_2D00_off_2D00_capture_2D00_data.zip

RE: How to configure to wake up from SYSTEM_ON and SYSTEM_OFF using RTC2 (periodically) and from GPIO pin change

Simonr — Mon, 02 May 2022 13:28:35 GMT

Indeed, the version of the application you were using seemed to not take care of the final call to put the device to sleep. Glad you were able to figure it out yourself!

Can you upload the .ppk file here by exporting it from the Power Profiler app and uploading it in a .zip file so we can get a better look at what's going on here. We'll need to zoom in more on these spikes to determine what they are exactly.

Best regards,

Simon

RE: How to configure to wake up from SYSTEM_ON and SYSTEM_OFF using RTC2 (periodically) and from GPIO pin change

V.Lorz — Sat, 30 Apr 2022 17:42:45 GMT

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?

RE: How to configure to wake up from SYSTEM_ON and SYSTEM_OFF using RTC2 (periodically) and from GPIO pin change

V.Lorz — Fri, 29 Apr 2022 11:37:56 GMT

Simonr, thanks for your comments, I couldn't test until now.

I tried to compile the sample application for system OFF but it failed in both ways I tried, "Add existing application" and "Create a new application from sample". Build log is at the end.

Then I took the code and incorporated it to my application, enabling CONFIG_PM and CONFIG_PM_DEVICE in my prj.conf. Here below is the code:

///...headers here...

#define CONSOLE_LABEL DT_LABEL(DT_CHOSEN(zephyr_console))
#define BUSY_WAIT_S 4U
#define SLEEP_S 2U
#define CONSOLE_LABEL DT_LABEL(DT_CHOSEN(zephyr_console))

static int disable_ds_1(const struct device *dev)
{
	ARG_UNUSED(dev);

	pm_constraint_set(PM_STATE_SOFT_OFF);
	return 0;
}

SYS_INIT(disable_ds_1, PRE_KERNEL_2, 0);

/* main */
void main(void)
{
	int rc;
	const struct device *cons = device_get_binding(CONSOLE_LABEL);

	nrf_gpio_cfg_input(DT_GPIO_PIN(DT_NODELABEL(button0), gpios), NRF_GPIO_PIN_PULLUP);
	nrf_gpio_cfg_sense_set(DT_GPIO_PIN(DT_NODELABEL(button0), gpios), NRF_GPIO_PIN_SENSE_LOW);

	printk("Busy-wait %u s\n", BUSY_WAIT_S);
	k_busy_wait(BUSY_WAIT_S * USEC_PER_SEC);

	printk("Busy-wait %u s with UART off\n", BUSY_WAIT_S);
	rc = pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND);
	k_busy_wait(BUSY_WAIT_S * USEC_PER_SEC);
	rc = pm_device_action_run(cons, PM_DEVICE_ACTION_RESUME);

	printk("Sleep %u s\n", SLEEP_S);
	k_sleep(K_SECONDS(SLEEP_S));

	printk("Sleep %u s with UART off\n", SLEEP_S);
	rc = pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND);
	k_sleep(K_SECONDS(SLEEP_S));
	rc = pm_device_action_run(cons, PM_DEVICE_ACTION_RESUME);

	printk("Entering system off; press BUTTON1 to restart\n");

	pm_power_state_force(0u, (struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});

	printk("ERROR: System off failed\n");


	volatile int stay = true;

	while (stay)
	{
	}
}

Here is what comes out in the console:

*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
Busy-wait 4 s
Busy-wait 4 s with UART off
Sleep 2 s
Sleep 2 s with UART off
Entering system off; press BUTTON1 to restart
ERROR: System off failed

I have the DK connected to a PPK-II and I can see the changes in power consumption after the calls to k_sleep() ,so I can confirm it did not enter power off after the call to pm_power_state_force().

---- build log for original sample project ----

> Executing task: nRF Connect: Build: system_off/build (active) <

Building system_off
west build --build-dir d:\nordic\v1.9.1\zephyr\samples\boards\nrf\system_off\build d:\nordic\v1.9.1\zephyr\samples\boards\nrf\system_off

-- west build: generating a build system
Including boilerplate (Zephyr base (cached)): D:/nordic/v1.9.1/zephyr/cmake/app/boilerplate.cmake
-- Application: D:/nordic/v1.9.1/zephyr/samples/boards/nrf/system_off
-- Zephyr version: 2.7.99 (D:/nordic/v1.9.1/zephyr), build: v2.7.99-ncs1-1
-- Found west (found suitable version "0.12.0", minimum required is "0.7.1")
-- Board: nrf52dk_nrf52832
-- Cache files will be written to: D:/nordic/v1.9.1/zephyr/.cache
-- Found dtc: D:/nordic/v1.9.1/toolchain/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (d:/nordic/v1.9.1/toolchain/opt)
-- Found BOARD.dts: D:/nordic/v1.9.1/zephyr/boards/arm/nrf52dk_nrf52832/nrf52dk_nrf52832.dts
-- Generated zephyr.dts: D:/nordic/v1.9.1/zephyr/samples/boards/nrf/system_off/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: D:/nordic/v1.9.1/zephyr/samples/boards/nrf/system_off/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: D:/nordic/v1.9.1/zephyr/samples/boards/nrf/system_off/build/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: D:/nordic/v1.9.1/zephyr/samples/boards/nrf/system_off/build/zephyr/dts.cmake
Parsing D:/nordic/v1.9.1/zephyr/samples/boards/nrf/system_off/Kconfig
Loaded configuration 'D:/nordic/v1.9.1/zephyr/boards/arm/nrf52dk_nrf52832/nrf52dk_nrf52832_defconfig'
Merged configuration 'D:/nordic/v1.9.1/zephyr/samples/boards/nrf/system_off/prj.conf'
Merged configuration 'D:/nordic/v1.9.1/zephyr/samples/boards/nrf/system_off/build/zephyr/misc/generated/extra_kconfig_options.conf'
Traceback (most recent call last):
File "D:/nordic/v1.9.1/zephyr/scripts/kconfig/kconfig.py", line 278, in <module>
main()
File "D:/nordic/v1.9.1/zephyr/scripts/kconfig/kconfig.py", line 65, in main
if kconf.syms['WARN_EXPERIMENTAL'].tri_value == 2:
KeyError: 'WARN_EXPERIMENTAL'
CMake Error at D:\nordic\v1.9.1\zephyr\cmake\kconfig.cmake:272 (message):
command failed with return code: 1
Call Stack (most recent call first):
D:\nordic\v1.9.1\zephyr\cmake\app\boilerplate.cmake:544 (include)
D:\nordic\v1.9.1\zephyr\share\zephyr-package\cmake\ZephyrConfig.cmake:24 (include)
D:\nordic\v1.9.1\zephyr\share\zephyr-package\cmake\ZephyrConfig.cmake:40 (include_boilerplate)
d:\nordic\v1.9.1\zephyr\samples\boards\nrf\system_off\build\CMakeLists.txt:4 (find_package)

-- Configuring incomplete, errors occurred!
FATAL ERROR: command exited with status 1: 'd:\nordic\v1.9.1\toolchain\opt\bin\cmake.EXE' '-DWEST_PYTHON=d:\nordic\v1.9.1\toolchain\opt\bin\python.exe' '-Bd:\nordic\v1.9.1\zephyr\samples\boards\nrf\system_off\build' '-Sd:\nordic\v1.9.1\zephyr\samples\boards\nrf\system_off' -GNinja
The terminal process terminated with exit code: 1.

Terminal will be reused by tasks, press any key to close it.

RE: How to configure to wake up from SYSTEM_ON and SYSTEM_OFF using RTC2 (periodically) and from GPIO pin change

Simonr — Thu, 28 Apr 2022 13:07:10 GMT

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