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

1. Is there a specific reason you want to set them all to low accuracy and TOGGLE? What are you planning on using the PORT pins for?

2. I guess, but you should implement some kind of queueing to make sure that something like this won't happen. So if an event occurs during an interrupt the next will be queued to go after the first interrupt is finished.

3. Yes, we would always recommend moving to the latest SDK version when there are updates to the specific peripheral, driver or library you're looking to use. As it often includes bug fixes or improvements, and in this case the updates seem to help the GPIOTE handle PORT interrupts better.

Best regards,

Simon

[droberson]

1. Because we have a dozen or so interrupt lines in our system. 8 of them are high-accuracy, the rest are low-accuracy.

2. What do you mean "I guess"? Let me rephrase my question with some example code:

nrf_drv_gpiote_in_config_t gpioConfig = GPIOTE_CONFIG_IN_SENSE_TOGGLE(false);
gpioConfig.pull = NRF_GPIO_PIN_PULLUP;

APP_ERROR_CHECK(nrf_drv_gpiote_in_init(PB_INT_PIN, &gpioConfig, gpio_int_callback));
APP_ERROR_CHECK(nrf_drv_gpiote_in_init(HALL_OUT_N_PIN, &gpioConfig, gpio_int_callback));

// Enable interrupts for the button and hall sensor
nrf_drv_gpiote_in_event_enable(PB_INT_PIN, true);
nrf_drv_gpiote_in_event_enable(HALL_OUT_N_PIN, true);

If both the PB_INT_PIN and HALL_OUT_N_PIN are asserted low at the same time, will the gpio_int_callback() be called twice (once for each pin) or will it only be called once?

3. All I really want to know regarding this is can I achieve the same functionality in SDK 15.2, I just don't want to miss interrupt callbacks for pins set as PORT events.

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

[Simonr]

Hi again Derek

Yes, the callbacks should be called for each pin, but you should still do some testing on your end to make sure your application does what you want it to do in corner cases you can think of as well.

I'd recommend checking out how our example projects/drivers handle this. For example the pin_change and GPIOTE examples as well as the GPIOTE library.

Best regards,

Simon