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

[Ligo George]

We are in the process of porting from nRF SDK v15.3.0 to v17.1.0.

After updating, we’ve noticed that the device sometimes gets stuck. Investigation shows this is related to GPIO interrupt handling.

The nRF52840 supports two wakeup detect modes: Default detect (non-latch) and Latch detect (LDETECT). In our use case the interrupt source is not an edge but a signal that can stay active (high or low).

SDK v17 introduces new latch handling in the GPIO library. For nRF52840, this is always enabled through NRF_GPIO_LATCH_PRESENT macro.

We never explicitly enable latch mode (via NRF_GPIO->DETECTMODE = GPIO_DETECTMODE_DETECTMODE_LDETECT << GPIO_DETECTMODE_DETECTMODE_Pos;), however the ISR still uses latch detect clearing mechanisms even when this is not enabled.

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.

We tested by commenting out #define NRF_GPIO_LATCH_PRESENT, and then everything works fine without latch handling — but this is not expected behaviour. We don’t want to modify the SDK just to achieve this. Is there a supported way to disable latch detect without patching the SDK?

[Vidar Berg]

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.

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.

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

Is the input signal free of glitches?

Best regards,

Vidar

[Ligo George]

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.

[Vidar Berg]

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?

[Ligo George]

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

[Vidar Berg]

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.

[Ligo George]

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

[Vidar Berg]

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.

[Ligo George]

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. 

[Vidar Berg]

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)?

[Ligo George]

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.

[Vidar Berg]

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?

[Ligo George]

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.