nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Ligo George — Wed, 27 Aug 2025 11:35:00 GMT

Thanks for the support, I think we are good.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Vidar Berg — Wed, 27 Aug 2025 11:03:07 GMT

SENSE is enabled in nrfx_gpiote_in_event_enable() after nrfx_gpiote_in_init().

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Ligo George — Wed, 27 Aug 2025 10:51:03 GMT

It's also redundant to run enable sense with nrf_gpio_cfg() when it's already done by the GPIOTE driver (in case of .high_accuracy=false).

Can you please let me me know where this wake up sense is already done in nrfx_gpiote_in_init() the case of .high_accuray=false ? I coudn't find it.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Ligo George — Wed, 27 Aug 2025 10:34:40 GMT

Yes, it works fine if we configure .high_accuracy = false before enabling wake up sense.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Vidar Berg — Wed, 27 Aug 2025 08:37:44 GMT

This should not occur if the pin has already been initialized and enabled in the GPIOTE driver, as that would cause execution to reach this code and release the DETECT signal:

It's also redundant to run enable sense with nrf_gpio_cfg() when it's already done by the GPIOTE driver (in case of .high_accuracy=false).

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Ligo George — Wed, 27 Aug 2025 07:57:24 GMT

And this is with .high_accuracy=true for that particular pin?

Based on my tests, it behaves same in this case with .hi_accuracy true / false.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Vidar Berg — Wed, 27 Aug 2025 07:50:18 GMT

[quote userid="134458" url="~/f/nordic-q-a/123923/nrf52840-how-to-disable-latch-detect-in-sdk-v17-gpio-interrupts/546846"]On power up we are doing,

nrf_gpio_cfg(pin, NRF_GPIO_PIN_DIR_INPUT, NRF_GPIO_PIN_INPUT_CONNECT, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_S0S1, NRF_GPIO_PIN_SENSE_LOW);

. It straight away goes stuck at port_event_handle() if the input is already low, with SDK 17. [/quote]

The DETECT signal is not going to be deasserted until either the SENSE or input level changes.

[quote userid="134458" url="~/f/nordic-q-a/123923/nrf52840-how-to-disable-latch-detect-in-sdk-v17-gpio-interrupts/546846"] It straight away goes stuck at port_event_handle() if the input is already low, with SDK 17. [/quote]

And this is with .high_accuracy=true for that particular pin?

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Ligo George — Wed, 27 Aug 2025 07:43:39 GMT

This is was the assumption I made when you said the signal came from a charger earlier, and is why I meant ask if the active level would change depending on the charger state at the time of entering system off. How were you handling this in the previous version? Also, were you using GPIOTE PORT events or GPIO IN events previously?

With SDK 15, currently both .hi_accuracy=true and NRF_GPIO_PIN_SENSE_LOW is enabled. So I assume it uses both GPIOTE PORT events and GPIO IN events.

Now with SDK 17, currently I am setting .hi_accuracy=false for pins which configure wakeup sense.

This indicates that the input pin has not been disabled in the GPIOTE driver. In any case, if you set the sense level to low and the input is low, the device will immediately wake up again if you try to enter system off.

On power up we are doing, nrf_gpio_cfg(pin, NRF_GPIO_PIN_DIR_INPUT, NRF_GPIO_PIN_INPUT_CONNECT, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_S0S1, NRF_GPIO_PIN_SENSE_LOW);. It straight away goes stuck at port_event_handle() if the input is already low, with SDK 17.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Vidar Berg — Wed, 27 Aug 2025 07:27:25 GMT

[quote userid="134458" url="~/f/nordic-q-a/123923/nrf52840-how-to-disable-latch-detect-in-sdk-v17-gpio-interrupts/546807"]For example, we use wake-up sense to detect charger input or button press. If the device starts with the charger already connected, the input is already LOW[/quote]

This is was the assumption I made when you said the signal came from a charger earlier, and is why I meant ask if the active level would change depending on the charger state at the time of entering system off. How were you handling this in the previous version? Also, were you using GPIOTE PORT events or GPIO IN events previously?

[quote userid="134458" url="~/f/nordic-q-a/123923/nrf52840-how-to-disable-latch-detect-in-sdk-v17-gpio-interrupts/546807"]causes the device to get stuck in the same port_event_handle()[/quote]

This indicates that the input pin has not been disabled in the GPIOTE driver. In any case, if you set the sense level to low and the input is low, the device will immediately wake up again if you try to enter system off.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Ligo George — Tue, 26 Aug 2025 17:39:40 GMT

For example, we use wake-up sense to detect charger input or button press. If the device starts with the charger already connected, the input is already LOW. Enabling wake-up sense on LOW at this time causes the device to get stuck in the same port_event_handle() ISR. It works fine if the charger is not connected (input HIGH) when enabling.

Similarly, if a button gets stuck/jammed and stays LOW, we could run into the same issue, making it harder to detect the actual cause.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Vidar Berg — Tue, 26 Aug 2025 14:48:45 GMT

Just to confirm, you only want the device to wake up when the signal goes from high to low? And in that case, is the issue that the signal is sometimes already low when you try to enter system OFF?

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Ligo George — Tue, 26 Aug 2025 13:43:05 GMT

It is always configured as sense on LOW. I could read the input first and then set the appropriate sense level, but that doesn’t sound very robust — if it’s missed once, the device can end up stuck.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Vidar Berg — Tue, 26 Aug 2025 13:35:46 GMT

Not sure what the input latch signal refers to in this context, but does the wake-up signal change between active low and active high? In that case, couldn’t you just read the input first and then set the appropriate sense level (low to high or high to low)?

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Ligo George — Tue, 26 Aug 2025 13:16:53 GMT

With this approach we still have an issue.

If the input latch signal is asserted while enabling WAKEUP sense, we still run in to the same problem.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Vidar Berg — Tue, 26 Aug 2025 13:10:19 GMT

Thanks for confirming that it works now. Ideally it seems like the driver should have ignored the latch bit for any input that was not initialized with .hi_accuracy=false. The assumption is probably that the application would not configure SENSE for other pins.

I don't think this is applicable to SDK 15 since it does not include the latch clearing logic.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Ligo George — Tue, 26 Aug 2025 13:07:08 GMT

It looks working now. Should we follow the same for SDK 15 as well or this is applicable only for SDK 17 ?

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Vidar Berg — Tue, 26 Aug 2025 12:54:46 GMT

The solution should be to ensure that SENSE and GPIOTE IN events are not enabled for the same input pin at the same time. You can reconfigure pins that are to be used for wakeup when preparing to enter System OFF after disabling the GPIOTE IN event.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Ligo George — Tue, 26 Aug 2025 12:50:41 GMT

We are using SENSE on some inputs to wakeup the mcu.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Vidar Berg — Tue, 26 Aug 2025 12:46:46 GMT

Yes, SDK 15 was not utilizing the latch register. Where are you configuring the pin with SENSE enabled, and what is the purpose of that?

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Ligo George — Tue, 26 Aug 2025 12:43:39 GMT

Yes, that is right.

GPIOTE inputs are initialized with .hi_accuracy=true and SENSE is enabled. This was working fine with SDK 15.

Do you have any official documentation mentioning the same ?

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Vidar Berg — Tue, 26 Aug 2025 12:35:31 GMT

[quote userid="134458" url="~/f/nordic-q-a/123923/nrf52840-how-to-disable-latch-detect-in-sdk-v17-gpio-interrupts/546754"].hi_accuracy is set to true for all our interrupts, but still port_event_handle() is getting called. Based on my testing, port_event_handle() is getting called especially in cases like “A PORT event is triggered if the DETECT signal was low before enabling the sense mechanism”, even if .hi_accuracy is set to true, and it is stuck in while loop. [/quote]

This suggests that you have pins configured with SENSE enabled, but this is not done by the GPIOTE driver when .hi_accuracy is set to 'true'.

[quote userid="134458" url="~/f/nordic-q-a/123923/nrf52840-how-to-disable-latch-detect-in-sdk-v17-gpio-interrupts/546754"]Will latch bit staying set matter if the detect mode is "non-latch" ?[/quote]

Yes.

[quote userid="134458" url="~/f/nordic-q-a/123923/nrf52840-how-to-disable-latch-detect-in-sdk-v17-gpio-interrupts/546754"]But for me the code execution never reaches here, as I mentioned before.[/quote]

Then the given pin has not been initialized with hi_accuracy=false.

GPIOTE inputs initialzied with .hi_accuracy=true should not be configured with SENSE enabled.

EDIT I can see now how this could lead to the driver becoming stuck in the ISR. The solution should be to make sure sense is not enabled for inputs initialized with .hi_accuracy enabled.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Ligo George — Tue, 26 Aug 2025 12:18:07 GMT

Port event is not enabled when .hi_accuracy is set to 'true'. If this is the configuration you are using for all your interrupt pins, then port_event_handle() should never have been called.

.hi_accuracy is set to true for all our interrupts, but still port_event_handle() is getting called. Based on my testing, port_event_handle() is getting called especially in cases like “A PORT event is triggered if the DETECT signal was low before enabling the sense mechanism”, even if .hi_accuracy is set to true, and it is stuck in while loop.

Is it always latched for the same pin?

Yes, but with .hi_accuracy is set to true, it continues with next iteration from if(m_cb.port_handlers_pins[i] == PIN_NOT_USED).

because the latch bit will still be set even if the DETECT signal has been deasserted.

Will latch bit staying set matter if the detect mode is "non-latch" ?

This case appears to have been considered based on the comment here:

But for me the code execution never reaches here, as I mentioned before.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Vidar Berg — Tue, 26 Aug 2025 12:04:30 GMT

Port event is not enabled when .hi_accuracy is set to 'true'. If this is the configuration you are using for all your interrupt pins, then port_event_handle() should never have been called.

[quote user="Ligo George"] as it is unable to find a matching latch bit set in following, if (nrf_bitmask_bit_is_set(pin, latch))[/quote]

Is it always latched for the same pin?

[quote user="Ligo George"]I’m not sure I fully understand — if LDETECT is not enabled, how does using the LATCH register make the interrupt handling more robust?[/quote]

because the latch bit will still be set even if the DETECT signal has been deasserted.

[quote user="Ligo George"]As per the nRF documentation I see: “A PORT event is triggered if the DETECT signal was low before enabling the sense mechanism”. If I understand correctly, the current port event handler doesn’t account for this case.[/quote]

This case appears to have been considered based on the comment here:

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Ligo George — Tue, 26 Aug 2025 10:45:32 GMT

Thanks for the quick response.

I don’t think the input signal is completely glitch-free, since it is triggered by the charger connector — that’s probably why the port event is firing.

From what I observe, it ends up calling port_event_handle, and then contuine; on the below check, so the level reconfiguration is not happening, continues again on the while loop non stop.

How to configure this properly ?

nrfx_gpiote_in_config_t interruptConfig = {
    .sense = NRF_GPIOTE_POLARITY_TOGGLE,
    .pull = NRF_GPIO_PIN_NOPULL,
    .is_watcher = false,
    .hi_accuracy = true,
    .skip_gpio_setup = true,
};

I tried configuring .hi_accuracy = false, to force use port events. But still the behaviour is similar, as it is unable to find a matching latch bit set in following, if (nrf_bitmask_bit_is_set(pin, latch))

I have not been able to find any other similar reports with this issue. The latch register is used to reduce the chance of missing pin events, which can occur more easily when multiple pins have sense enabled in applications where the GPIOTE IRQ may be blocked or preempted by other interrupts.

The driver doesn't enable the LDETECT mode, so the latch register bits are not going trigger the PORT event either. The driver will always uses the LATCH register as long as it's supported by the HW (indicated by the presence of the NRF_GPIO_LATCH_PRESENT symbol). This was not designed to be configurable as there are no known drawbacks of using it. It should only make the interrupt handling more robust.

I’m not sure I fully understand — if LDETECT is not enabled, how does using the LATCH register make the interrupt handling more robust?

As per the nRF documentation I see: “A PORT event is triggered if the DETECT signal was low before enabling the sense mechanism”. If I understand correctly, the current port event handler doesn’t account for this case.

RE: nRF52840: How to disable latch detect in SDK v17 GPIO interrupts?

Vidar Berg — Tue, 26 Aug 2025 10:00:14 GMT

Hello,

I have not been able to find any other similar reports with this issue. The latch register is used to reduce the chance of missing pin events, which can occur more easily when multiple pins have sense enabled in applications where the GPIOTE IRQ may be blocked or preempted by other interrupts.

The driver doesn't enable the LDETECT mode, so the latch register bits are not going trigger the PORT event either. The driver will always uses the LATCH register as long as it's supported by the HW (indicated by the presence of the NRF_GPIO_LATCH_PRESENT symbol). This was not designed to be configurable as there are no known drawbacks of using it. It should only make the interrupt handling more robust.

[quote user=""]Because our interrupt signals can stay active, the latch never resets → the MCU ends up stuck in the loop inside port_event_handle(uint32_t * latch) (called from interrupt context). This effectively makes every GPIO interrupt susceptible to the same issue if the input signal stays asserted.[/quote]

Note that the sense level is reconfigured in the ISR to prevent exactly this:

Is the input signal free of glitches?

Best regards,

Vidar