• State Not Answered
  • Replies 12 replies
  • Subscribers 25 subscribers
  • Views 296 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

  • 0 in reply to user109035

    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

  • 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
  • 0

    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

  • 0 in reply to user75734

    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

  • 0

    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

Related
Terms of service