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

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

[Mike Austin (LPI)]

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