GPIOTE PORT (Low-accuracy) interrupt detection with multiple pins

[droberson]

Hello,

I know there are dozens of threads on this topic already but they don't seem to quite answer all my questions.

Some background:

SDK: 15.2

SoftDevice: s140_nrf52_6.1.0

Facts about GPIOTE that I am aware of (Please correct me if I am wrong):

• There are 8 GPIOTE pin event channels on the nRF52840 (High-accuracy)
• The HF Clock is running if any pin is configured as a pin event (High-accuracy)
• If multiple pins are configured as low-accuracy (port event), events from other pins are ignored so long as an event is active on a given pin due to all pins having a shared DETECT signal (They are OR'd together in hardware). For example, Signal A is set to interrupt on HITOLO. Signal B is set to interrupt on HITOLO. If signal A is driven low, generates an event, and remains low, an interrupt event will never be received if signal B is then also driven low.

I have seen some other threads mention that if you set all PORT event pins to TOGGLE, that you can then receive interrupts from other pins even if one of them remains in the active state.

Source: https://devzone.nordicsemi.com/f/nordic-q-a/47740/what-is-the-difference-between-high-accuracy-and-signal-mode-in-gpiote/189361#189361

I have tested this myself by setting two pins as TOGGLE and I am able to receive interrupts from both regardless of what state the pin is in.

Question 1: Is setting all PORT (low-accuracy) pins to TOGGLE a good solution?

Question 2. If all PORT pins are set to TOGGLE, is it possible to miss an interrupt from one of the pins if both pins are asserted at the same time?

Question 3: I noticed that newer SDK's have additional logic to handle pins configured as PORT interrupts (port_event_handle() in nrfx_gpiote.c, SDK 17.1). Is there any added benefit to upgrading to this SDK that will mitigate or resolve any potential issues with receiving multiple interrupts at the same time on pins configured for low-accuracy (PORT event)?

Source: https://devzone.nordicsemi.com/f/nordic-q-a/78504/correct-way-to-handle-gpiote-port-event/325905#325905

Thanks,

Derek

[Simonr]

Hi Derek

2. Sorry. Yes, missing an interrupt from pins is something that could occur in this instance if it's not handled correctly. I discussed the snippet you sent with a colleague, and a toggle like this should call the gpio_int_callback() twice as they will fire separate events from separate GPIOs. 

3. Well, if you take the time to add the same logic and functions in your version of v15.2 of the SDK you'll achieve the same functionality, but I think it would be easier and faster to follow our migration guides and move the application to SDK v17.1. But this is entirely up to you, you might not need it at all, but please note that we recommend moving to the latest version.

Migration guide from SDK 15 to 16: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/migration.html 
Migration guide from SDK 16 to 17: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/migration.html 

Best regards,

Simon

[droberson]

Hey Simon,

Regarding #2, if you are certain that gpio_int_callback() will be called for each pin if they interrupt at the same time even though they share a common DETECT signal (Low accuracy), then that answers my question and no interrupt should be missed and I can remain on SDK 15.2 for now. Regarding your comment "missing an interrupt from pins is something that could occur in this instance if it's not handled correctly". Is there a preferred "correct" way I should be handling it other than what is shown in the code snippet below?

static void gpio_int_callback(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
   UNUSED_PARAMETER(action);
   
   // Only care about high to low transition for button
   if(pin == PB_INT_PIN && !nrf_gpio_pin_read(PB_INT_PIN))
   {
      // Debounce button and notify app
   }
   else if(pin == HALL_OUT_N_PIN)
   {
      // Debounce hall sensor and notify app
   }
}

Thanks,

Derek