Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Okay, it shouldn't take this long to wake up, can you show me your wake up procedure? This only makes sense if you initialize the BLE stack and thus starts up the oscillator. The wake up timings can be found in the nRF52832 PS here.

Best regards,

Simon

Okay, it shouldn't take this long to wake up, can you show me your wake up procedure? This only makes sense if you initialize the BLE stack and thus starts up the oscillator. The wake up timings can be found in the nRF52832 PS here.

Best regards,

Simon

Hi Simon,

So, I'm using the system_off example in ...v1.9.1\zephyr\samples\boards\nrf\system_off and the only modifications I have made are:

1. Configure P0.14 to be an output and set it low on start up

2. Removed all the stuff about enabling/disabling the UART and putting it into various low(er) power modes

3. Set P0.14 just prior to entering System Off

4. Added a k_sleep() statement straight after the call to go into System Off, otherwise it doesn't work (a known issue with the example code)

The delay between my button0 signal going low, and my button1 signal going low, which is essentially measuring the time it takes to get to the first line in my main.c, is around 400msec, although it does vary a bit

This is my main.c in full.

/*
 * Copyright (c) 2019 Nordic Semiconductor ASA
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <stdio.h>
#include <zephyr.h>
#include <device.h>
#include <init.h>
#include <pm/pm.h>
#include <pm/device.h>
#include "retained.h"
#include <hal/nrf_gpio.h>

#define CONSOLE_LABEL DT_LABEL(DT_CHOSEN(zephyr_console))

#define BUSY_WAIT_S 2U
#define SLEEP_S 2U

/* Prevent deep sleep (system off) from being entered on long timeouts
 * or `K_FOREVER` due to the default residency policy.
 *
 * This has to be done before anything tries to sleep, which means
 * before the threading system starts up between PRE_KERNEL_2 and
 * POST_KERNEL.  Do it at the start of PRE_KERNEL_2.
 */
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);

void main(void)
{
	/* Configure button 1 (P0.14) to be an output to allow start up delay measurement */
	nrf_gpio_cfg_output(DT_GPIO_PIN(DT_NODELABEL(button1), gpios));

	/* Toggle P0.14 output on startup.  P0.14 is linked to button1, which has a resistor pull-up, so need to clear it */
	nrf_gpio_pin_clear(DT_GPIO_PIN(DT_NODELABEL(button1), gpios));

	printk("\n%s system off demo\n", CONFIG_BOARD);

	if (IS_ENABLED(CONFIG_APP_RETENTION)) {
		bool retained_ok = retained_validate();

		/* Increment for this boot attempt and update. */
		retained.boots += 1;
		retained_update();

		printk("Retained data: %s\n", retained_ok ? "valid" : "INVALID");
		printk("Boot count: %u\n", retained.boots);
		printk("Off count: %u\n", retained.off_count);
		printk("Active Ticks: %" PRIu64 "\n", retained.uptime_sum);
	} else {
		printk("Retained data not supported\n");
	}

	/* Configure to generate PORT event (wakeup) on button 1 press. */
	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);

	/* Reset P0.14 */
	nrf_gpio_pin_set(DT_GPIO_PIN(DT_NODELABEL(button1), gpios));

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

	if (IS_ENABLED(CONFIG_APP_RETENTION)) {
		/* Update the retained state */
		retained.off_count += 1;
		retained_update();
	}

	/* Above we disabled entry to deep sleep based on duration of
	 * controlled delay.  Here we need to override that, then
	 * force entry to deep sleep on any delay.
	 */
	pm_power_state_force(0u, (struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});
	k_sleep(K_SECONDS(SLEEP_S));
	printk("ERROR: System off failed\n");
	while (true) {
		/* spin to avoid fall-off behavior */
	}
}

Regards,

Mike

Putting the pin toggle in a SYS_INT call in either of the PRE_KERNEL stages (I've tried both PRE_KERNEL_1 and PRE_KERNAL_2) drops the start up delay down to < 400usec, which is more what I would have expected to see.

I think if I can get my start-up delay to < 10msec, I can make things work for my application

Cheers,

Mike