Wake up from GPIO pin

RE: Wake up from GPIO pin

Wael — Wed, 16 Oct 2019 18:13:21 GMT

I am having an issue where if I change the NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(true) to NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(false), my interrupt handler gets triggered right away. the pin starts low but the handler should NOT be getting triggered since the pin did NOT transition from high to low. if i run the app with NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(true), everything functions as it should. I am trying to lower my power consumption and I am using SDK 15.0.0 and S132. I have been at this problem for days and any help would be greatly appreciated.

RE: Wake up from GPIO pin

mmmark84 — Mon, 22 Oct 2018 13:31:10 GMT

We added a little RC delay to it. should work for us.

RE: Wake up from GPIO pin

bjorn-spockeli — Tue, 16 Oct 2018 11:11:23 GMT

OK, you do not enter the GPIOTE_IRQHandler at all when using the port event? IF that is the case then yes, you will have to add some external circuitry.

RE: Wake up from GPIO pin

mmmark84 — Mon, 15 Oct 2018 13:28:42 GMT

with the IN event it detected just fine. With the port event, it misses it all the time, even with the BLE stack disabled. So I guess we dont have a choice to make it a delayed flank with some RC components.

RE: Wake up from GPIO pin

bjorn-spockeli — Fri, 12 Oct 2018 14:09:00 GMT

10uS is the number I got from R&D, but they also stated that its conservative. It was chosen as the recommended pulse length in order to avoid marginal designs where external factors reduce the actual pulse width seen by the device.

Were you able to detect the 10uS pulse with the IN event enabled or do you see the same behaviour as with the Port event?

RE: Wake up from GPIO pin

mmmark84 — Fri, 12 Oct 2018 12:42:28 GMT

thats..... pretty insanly long... Our old product has a LPC11E68 Cortex M0+ MCU which this 10uS works fine with and is able to set wakeup events that know what pin caused the wakeup. Is there no way we can have something similar on NRF52832? Or is reading NRF_GPIO -> LATCH maybe an option when we resume from nrf_pwr_mgmt_run() to know this?

RE: Wake up from GPIO pin

bjorn-spockeli — Fri, 12 Oct 2018 09:45:29 GMT

The minimum pulse width needed trigger DETECT Signal(which in turn will trigger the SENSE signal) is around 10uS. However, if you're using the GPIOTE driver then a longer pusle width is required for GPIOTE PORT events compared with PIN events. This is because when using port events, GPIOTE_IRQHandler in nrf_drv_gpiote.h checks the status of each gpio to figure out which gpio that was trigged when the PORT event occurred.

Therefore, since the GPIOTE handler checks the state of each enabled pin for PORT events, the triggered pin has to stay high (or low) until that operation is finished.

It might be possible to modify the GPIOTE_IRQHandler so that it fits your application e.g. checks the pins with the shortest pulse first or similar.

Note: Since the radio has higher priority than GPIOTE when using the softdevice, software processing of the GPIOTE interrupt is delayed until the radio has finished its operations.

RE: Wake up from GPIO pin

mmmark84 — Fri, 12 Oct 2018 09:32:08 GMT

What is the minimal time that my pin needs to be low, when using the port mode? We have a device that generates a 10uS low pulse for which we need to wake from. We are also running SD 132 on the module. Seems it is missing this pulse?

RE: Wake up from GPIO pin

bjorn-spockeli — Thu, 11 Oct 2018 13:30:38 GMT

Ok, then you might have to add some button debouncing in SW or in HW to mitigate this.

RE: Wake up from GPIO pin

mmmark84 — Thu, 11 Oct 2018 13:08:08 GMT

Yes, that was the trick! Thank you too

RE: Wake up from GPIO pin

mmmark84 — Thu, 11 Oct 2018 12:58:30 GMT

When I use the button to test it and debug it, im getting it all the time when I press and hold it (at least a couple of times when I run after the breakpoint in the button handler function).

RE: Wake up from GPIO pin

bjorn-spockeli — Thu, 11 Oct 2018 12:56:41 GMT

Ok, so you get NRF_GPIOTE_POLARITY_HITOLO two times ?

RE: Wake up from GPIO pin

mmmark84 — Thu, 11 Oct 2018 12:52:06 GMT

Seems fine for an other pin I just tested, maybe its due to debugging and using a button which does allot of bouncing when pressing it or something.

RE: Wake up from GPIO pin

bjorn-spockeli — Thu, 11 Oct 2018 12:29:00 GMT

Ok, let me know if you run into any issues with shorter pulses. Hmm, is the sense configuration set to NRF_GPIOTE_POLARITY_HITOLO and not NRF_GPIOTE_POLARITY_TOGGLE? I guess you can add a check for which type of event that generated the interrupt?

RE: Wake up from GPIO pin

mmmark84 — Thu, 11 Oct 2018 11:35:50 GMT

Thank you! I tried port mode and that seems to work fine with the button. I hope its usable for our other devices which will generate a shorter pulse.

The event handler seems to work fine as well now with port mode (however I also get an event when going low->high...).

RE: Wake up from GPIO pin

bjorn-spockeli — Thu, 11 Oct 2018 11:26:20 GMT

as Turbo J has pointed out, using the IN event to detect a pin change will lead to an increase in the current consumption. This is because the IN event requires the HF clock to be running, i.e. adding about 250uA. The PORT event on the other hand does not require the HF clock to be running and is therefore better suited for low power applications.

You should only have to change NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(true) to NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(false) in the first code snippet and you should see the current consumption drop significantly.

Best regards

Bjørn

RE: Wake up from GPIO pin

Turbo J — Thu, 11 Oct 2018 11:00:11 GMT

Look at the errata sheet: The GpioTE IN events pull a lot more current.

Workaround: Use the "port" event (sense bits in PIN_CNF[x] registers), and the NRF_GPIO -> LATCH register to detect which I/O triggered the event.