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

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

[Mike Austin (LPI)]

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

[Airat]

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.

[Mike Austin (LPI)]

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