Multiple GPIO interrupts from SYSTEM_SOFT_OFF

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Mike Austin (LPI) — Tue, 13 Dec 2022 09:15:53 GMT

Yes,, that was the approach I had to take.

it was further complicated by the fact that I have mcuboot enabled (my code allows for an OTA DFU) and this was clearing my LATCH register before the Pre-kernel code could grab the value as you are doing.

if you read the thread further down, you can see how I got around this (using the mcuboot.confi file with CONFIG_GPIO=N setting)

Cheers,

Mike

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Airat — Tue, 13 Dec 2022 08:07:14 GMT

Hi,

do you have any success in figuring out the reason for the reset LATCH register? We have the same problem with nRF52832 and NCS 2.0.0 multiple wake up interrupts from different sources. I also managed to recreate the issue on mNR52840dk by clicking two buttons quickly one after another.

The only work around that worked for us is to read the value of the LATCH register on the PRE_KERNEL_2 level, save the value in some static variable and then process that value on the application level.

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Mike Austin (LPI) — Mon, 27 Jun 2022 07:16:29 GMT

Hi Simon,

Yep - tried Hakon's suggestion, which fixed that issue. It did, unfortunately, knobble my retained RAM functionality. But that may not be an issue for me if I can get the "write struct to NVS" issue I've had sitting in the background for a month or so now sorted. Realistically, writing my data to flash each time I come out of System OFF will be a more robust solution that simply having retained RAM, as at some point the end user may need to replace the battery and they'd then lose all the historical data if I relied only on retained RAM.

Sorting out writing a custom struct of data to NVS is my target this week. I'll hassle you on the other thread about that one if I get stuck

Cheers,

Mike

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Simonr — Mon, 27 Jun 2022 07:04:55 GMT

Sorry about the late reply, but I have been out of office the last week and I'm only now getting to going through my backlog. To upload files or code snippets you can use the "Insert" dropdown menu in your reply.

Yes, NCS is our unofficial acronym of nRF Connect SDK. From the project configs it does indeed seem like it uses the LF clock. Glad to hear you were able to find a way around this.

Did you try doing what Håkon is suggesting, disabling CONFIG_GPIO in MCUboot by creating a child image folder and creating an mcuboot.conf with CONFIG_GPIO=n.

Best regards,

Simon

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Mike Austin (LPI) — Wed, 22 Jun 2022 04:32:07 GMT

Hi Simon,

I commented on another thread, that appeared related to my issues, and one of the other Nordic Engineers proposed some reasoning behind the ~ 400msec delay:

RE: PIN_CNF Sense change state

I am actually using nRF Connect within VSC - but I assume this is what Hakon is referring to when he mentions "NCS"?

Seems this implements the LFCLK by default, regardless of whether I am using BLE at the time or not, which is what is causing the delay. So, I was kind of on the right track.

I have moved where I read the values of RESETREAS and LATCH into a SYS_INIT call in PRE_KERNEL_2 to overcome the 400msec delay issue, so I think I can park that part of the problem and say "its resolved"

The issue I am still struggling with is the LATCH being reset if I get two GPIO triggers within this software start up period. In my actual application, this is very likely to happen.

What I've uncovered is that if I have

CONFIG_BOOTLOADER_MCUBOOT=y

in my proj.config file, then the problem of the LATCH register getting reset with the second GPIO trigger signal exists. If I don't have this in my prof.config file, then the LATCH signal remains intact and I can successfully grab the value of that in my SYS_INIT routine.

I am writing

NRF_GPIO->PIN_CNF[13] &= 0x02;

as the very first thing I do in my SYS_INIT function, so that the relevant GPIO is disconnected as an input and the SENSE is also disabled. I'm doing this in an attempt to stop any subsequent reset triggers from the GPIO once the device has come out of System OFF. But with the CONFIG_BOOTLOADER_MCUBOOT=y statement present in my conf file, this appears to have no impact. I will see a second reboot of the chip.

I'm even putting a 2sec wait at the end of my main.c, prior to putting the chip back into System OFF, so that I know its not actually going into System OFF when the second GPIO trigger comes along, but that's not changing the behaviour I am seeing. The issue seems to be that if I get a second GPIO trigger prior to my main.c code starting up, and with CONFIG_BOOTLOADER_MCUBOOT=y, I will get LATCH reset to zero unexpectantly.

I am setting CONFIG_BOOTLOADER_MCUBOOT=y because in my final application I need to have DFU functionality, and this was a requirement as indicated in the example code for DFU.

Any ideas how to get around this LATCH issue?

Cheers,

Mike

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Mike Austin (LPI) — Fri, 17 Jun 2022 06:22:34 GMT

Hi Simon,

Not sure how to actually attach files on here. But this is my proj.conf file:

CONFIG_PM=y
# Required to disable default behavior of deep sleep on timeout
CONFIG_PM_DEVICE=y
CONFIG_GPIO=y
# Optional select RAM retention (nRF52 only)
CONFIG_APP_RETENTION=y

And this is the kconfig file:

# Copyright (c) 2021 Nordic Semiconductor ASA
# SPDX-License-Identifier: Apache-2.0

mainmenu "Nordic SYSTEM_OFF demo"

config APP_RETENTION
	bool "Enable state retention in system off"
	depends on SOC_COMPATIBLE_NRF52X
	help
	  On some Nordic chips this application supports retaining
	  memory while in system off.  Select this to enable the
	  feature.

source "Kconfig.zephyr"

I've not changed either of these from the defaults that came with that example code.

I am using VSC with the nRF Connect extension. Not sure if that is causing some issues

Cheers,

Mike

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Simonr — Fri, 17 Jun 2022 06:05:05 GMT

Hi Mike

After looking through your main file and discussing this with a couple of colleagues, I still find this strange. It does not seem to be the delays in HW causing this, but rather something set in the application. My guess would be that some peripheral is taking time. Can you upload your configuration file (.conf) so we can make sure it doesn't enable any peripheral taking extra time to start up. Because 400ms is too high for just starting up the device.

Best regards,

Simon

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Mike Austin (LPI) — Thu, 16 Jun 2022 01:26:16 GMT

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

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Mike Austin (LPI) — Thu, 16 Jun 2022 00:07:17 GMT

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

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Simonr — Wed, 15 Jun 2022 13:16:18 GMT

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

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Mike Austin (LPI) — Wed, 15 Jun 2022 08:18:31 GMT

Thanks Simon.

I ended up opening a new thread as I couldn’t respond to myself for some reason.

The issue seems to be how long things take to exit System Off and start running my code. I’m seeing delays of 200-500msec!!!

So, if I get two or more GPIO triggers in that time, it seems to reset the value of LATCH and I can’t determine which GPIO caused the exit.

The new thread is here:

https://devzone.nordicsemi.com/f/nordic-q-a/88979/delay-between-exiting-system-off-and-starting-main-loop

Regards,

Mike

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Simonr — Wed, 15 Jun 2022 07:41:23 GMT

After a second look at the wake up side of things:

reset_reason = NRF_POWER->RESETREAS;
gpio_trigger = NRF_GPIO->LATCH;
printk("reset_reason = %d\n", reset_reason);
printk("gpio_trigger = %d\n", gpio_trigger);

Seems like this could cause some strange behavior. I think doing something like the following would be better:

reset_reason = NRF_POWER->RESETREAS;
(void)NRF_TIMER0->EVENTS_COMPARE[0];

gpio_trigger = NRF_GPIO->LATCH;
...

If you'd like, you can upload your project here and we can take a look on our side. Debugging is indeed tough when working on application going to system OFF as the CPU can't go to system OFF while debugging.

Best regards,

Simon

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Mike Austin (LPI) — Wed, 15 Jun 2022 06:52:20 GMT

Hi Simon,

Apologies for the multiple posts. I have been playing around with the original system_off example, to see if that displays the same behaviour (which it does). So that led me to looking at some of the timing.

I'm monitoring two GPIO on by scope:

1. The button signal that triggers the device out of System OFF

2. A second GPIO that I set and then clear within my code, as the very first thing I do in my main loop upon start up

What I'm seeing is a delay of anywhere from 200msec up to nearly 500msec between those two signals, which means there is upwards of 1/2sec a delay in some situations between the device being triggered out of System OFF, and my main loop commencing.

If there is another GPIO trigger during that period, it does something to the value of the LATCH signals, such that they are all cleared. So, when I then get to the point where I call:

NRF_GPIO->LATCH

I get zero, rather than any indication of which GPIO caused the exit from System OFF.

So, there are a few ways I can tackle this:

1. Hardware - have a really, really long time constant on my GPIO inputs so I can't get multiple triggers in < 500msec. Seems very cludgy, and may mean I can't actually get the performance I need

2. Work out why the code is taking so long to start up, and either reducing this time to < 50msec

3. Somehow shoe-horn the code where I grab the value of the LATCH signal much earlier in the start up sequence, so when my main loop eventually starts up, I've got the value stored there ready for use

Any ideas what's causing this delay, and how I can potentially reduce it?

Cheers,

Mike

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Mike Austin (LPI) — Tue, 14 Jun 2022 01:08:15 GMT

I've been trying to emulate this behaviour in debug mode, but I'm not seeing it happen. Essentially any subsequent button presses whilst my code is running are ignored (which is how I want it to work) and it only responds to a button press when its in System OFF. So I can't even work out why its behaving the way it is with debugging :-(

Cheers,

Mike

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Mike Austin (LPI) — Sun, 12 Jun 2022 23:31:54 GMT

Hi Simon,

Thanks for the link. Seems pretty straight forward.

I still think there is something else going on. To test this, I put a simple 1 sec delay (using kmsleep() ) at the very start of my code, and then a similar 1 second delay just prior to my code going back into System OFF.

This is the behaviour I see:

Press one of the buttons to bring it out of System OFF mode - it will succesfully detect that a GPIO caused the exit (as indicated by RESETREAS), and will successfully detect which button was pressed (via LATCH). It will then go back into System OFF mode

Press one of the buttons to bring it out of System OFF mode, then within 0.5 sec (effectively whilst its still in its waiting mode), press the same button a second time - it will successfully detect that a GPIO caused the exit (as indicated by RESETEREAS) but it no longer is able to detect what button was pressed (via LATCH). The result for LATCH = 0 in this case, which means I've got a scenario where my code has detected a GPIO has caused the exit from System OFF, but it can't tell which button has caused it. In this scenario, my code then just goes back into System OFF, and doesn't update any of my counters.

I'm using buttons in my testing, but ultimately the GPIO's will be triggered via an external signal. I will have three GPIO's, corresponding to a "Small", "Medium" or "Large" level on the external signal. These signals are very transient (will only be present for a few tens of milliseconds) and with the behaviour I am seeing at the moment, if I get two external signals within a short period of time, rather than detecting the first and ignoring any subsequent ones (what I would prefer) its essentially not correctly detecting any of them. And that's what I'm trying to sort out.

In my limited understanding, I think its something to do with the way the DETECT signal works. And I've been trying to disable the GPIO from impacting the DETECT signal at the start of my code, via a call to:

nrf_gpio_cfg_sense_input(pin, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_NOSENSE);

But this isn't achieving what I want, so perhaps there is another way?

So, what I want to be able to do the moment my code exits System OFF is:

1. Check the value of RESETREAS

2. Check the value of LATCH

3. Disable any GPIO from triggering anything

4. Process my counters based on the values of RESETREAS and LATCH

5. Re-enable GPIO's to allow exit from System OFF

6. Enter System OFF

Its step 3 that I seem to be unable to achieve

Cheers,

Mike

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Simonr — Fri, 10 Jun 2022 08:00:50 GMT

Hi MIke

We already have a good discussion on how to implement debouncing to GPIOs in your application in this thread that should be helpful. There is a "verified answer" with a code snippet shoing how/where you can add the debounce. As for the multiple button issue. Does just any button in your design wake the device from System OFF mode, and is that why you need the debounce on multiple buttons?

As for your confusion between the GPIO functions in your previous answer I'm not sure how to explain it better than the descriptions of the functions themselves.

nrf_gpio_cfg_input: "Function for configuring the given GPIO pin number as input, hiding inner details. This function can be used to configure a pin as simple input."

gpio_pin_configure_dt: "Configure a single pin from a @p gpio_dt_spec and some extra flags. This is equivalent to: gpio_pin_configure(spec->port, spec->pin, spec->dt_flags | extra_flags);

Best regards,

Simon

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Mike Austin (LPI) — Thu, 09 Jun 2022 11:07:12 GMT

Hi (again) Simon,

OK, a little bit more paring down my code, and some late afternoon testing, and I think my issue is somehow related to this:

Trying to put the system to System OFF while DETECT is high will cause a wakeup from System OFF reset.

What I do in my code when it first comes out of System OFF is the following:

reset_reason = NRF_POWER->RESETREAS;
gpio_trigger = NRF_GPIO->LATCH;
printk("reset_reason = %d\n", reset_reason);
printk("gpio_trigger = %d\n", gpio_trigger);

I then check reset_reason and gpio_trigger to determine what, principally, caused the exit from System_OFF and, in the case of it being a GPIO state change, which of my GPIO was the cause of this. The printk statements just let me check that what my code thinks has caused the exit, is actually the case.

What I notice is that if I only push the button the once, I will get the correct values for reset_reason and gpio_trigger. For example, if I push the button associated with P0.13, I will get:

reset_reason = 0x1000

gpio_trigger = 0x2000

However, if I push the button several times in quick succession, I will not get the correct value for gpio_trigger; this will almost always come back as zero, even though the reset_reason value is correct.

I put a k_sleep(K_SECONDS(1)); statement just prior to going back into System_OFF, to delay things for a second and thus try and prevent the multiple button press issue. This doesn't work reliably - if I press one button and then quickly a second one, I can get the issue described above where the gpio_trigger value comes out as zero.

Does it look like I'm on the right track in terms of thinking the DETECT signal is what is causing the second reset (even though my code is in the middle of operating at the time of the second button press)? And if so, is a software GPIO debounce at the very start of my code, where I just loop around until all the GPIOs have returned to their non-trigger state, the best approach to resolving it?

Cheers,

Mike

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Mike Austin (LPI) — Thu, 09 Jun 2022 06:06:59 GMT

Thanks Simon.

I think I may have solved my problem. Lets just say I had a convoluted mess of various gpio configs and interrupt configs, and when I stripped everything back to the basics to test what was causing my issue, it looks like the multiple reset issue has gone away. But I'll need to do a bit more investigations to be sure of that, using something that can operate my GPIO a bit quicker than I can!

I think my confusion (and it still exists to an extent) is trying to understand the difference between using:

nrf_gpio_cfg_input(pin, flags) &

nrf_gpio_cfg_sense_input(pin, flags)

compared to using:

gpio_pin_configure_dt(spec, flags)

I think its something to do with the difference between GPIO and GPIOTE, in that I need to use the nrf_gpio API's to set up my GPIO to trigger out of System-Off mode, but then need to use the gpio_pin_configure API's to set up those GPIO if I want to read in their status whilst my code is running. But don't quote me on that!

Any clarification would be greatly appreciate :-)

Cheers,

Mike

RE: Multiple GPIO interrupts from SYSTEM_SOFT_OFF

Simonr — Mon, 30 May 2022 07:49:46 GMT

Hi Mike

Yes, verifying an answer will mark your ticket as "resolved" and lock it. For the nRF52832 you also have the option to use the nRF5 SDK, but this SDK is only in maintenance mode, so for new designs we recommend using the nRF Connect SDK instead. See the nRF Connect SDK and nRF5 SDK statement for more details.

I still think that adding the debounce will fix the issue with multiple button presses after the initial one, as that will not cause any interrupts after pressing the button once until the debounce duration is done. Then you'll have to set the button input as disconnected for example to make the button not do anything until you go to sleep again. I don't think using another low power mode will help much, as the wake up GPIO will function similarly no matter what sleep mode the device is in.

Debounce in the nRF Connect SDK uses the GPIO_DEBOUNCE flag to add a debounce to GPIOs I believe, and it can be seen "in action" in the BLE Mesh OnOff Model sample here.

Best regards,

Simon