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