• State Not Answered
  • Replies 12 replies
  • Subscribers 25 subscribers
  • Views 297 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 289641
Options

Multiple GPIO interrupts from SYSTEM_SOFT_OFF

user109035

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

Parents
  • 0

    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

Reply
  • 0

    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

Children
  • 0 in reply to user75734

    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
Related
Terms of service