Multiple GPIO interrupts from SYSTEM_SOFT_OFF

[Mike Austin (LPI)]

OK, so it seems if you accidently hit "VERIFY ANSWER" your discussion gets locked and you can no longer comment, nor reverse that process.  So, I've had to start a new discussion in order to keep on with the old one:

https://devzone.nordicsemi.com/f/nordic-q-a/88286/multiple-gpio-interrupts-from-system_soft_off

What I wanted to say, rather than verify the answer, was:

Hi Simon,

Firstly, I seem to have accidently set your reply to "verified answer" and I can't seem to work out how to reverse that.

Anyway, I'm actually using the nRF Connect SDK (V1.9.1) and Zephyr, and may be 'cross-pollinating" by using those API's.  But I did ask on here if they were the only ones to use and didn't ever get an answer, so have just made them work for the moment.

What I'm seeing I don't think will benefit from button debounce, but I may be wrong.  What seems to be happening is that the first button press will trigger the device out of SYSTEM_OFF mode, and then my code starts running.  But any subsequent button press seems to interrupt the code that is being run and boot the device out of SYSTEM_OFF mode, even though I don't think it is actually in that mode.  This then seems to scramble all the registers I am using to determine how/why it came out of SYSTEM_OFF, and then I can't get it to do what it is supposed to do.

What I want to be able to do is the moment any GPIO triggers an exit from SYSTEM_OFF, that I disable this function so that any subsequent button presses will have no impact.  Essentially a bit like disabling interrupts whilst you service an exisiting interrupt.

But I can't find anywhere online where the functionality to achieve this is described.

I'd be happy to go with a low power mode rather than SYSTEM_OFF if it makes achieving what I want easier.  I can probably deal with quiescent currents of < 5uA.  Its just I couldn't actually find any helpful Zephyr/nRF Connect SDK low power examples, and everyone I have asked seems to look at me blankly.

I had a quick look at the example you listed in the original post.  Can't immediately understand much of it, but I'll go and have a more detailed look.  Also, not sure how relevant it is given I'm not using the nRF5 SDK

Cheers,

Mike

[Simonr]

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

[Mike Austin (LPI)]

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