Minimum pulse width for GPIO interrupt on nRF52840

[dwanninger]

Are there definitive specifications on the minimum pulse duration necessary to trigger GPIO DETECT events and PORT events?
I have a sensor that fires a logic-low interrupt pulse with a duration of 1.8us - 3.4us.  It is the only interrupt on the port, so I am using a PORT event to keep current low.  I modified the nrfx_gpiote_irq_handler() function in nrfx_gpiote.c so that it doesn't check each pin in the port to determine the source.

This works, but my measured pulse width is 2.4us.  This is going to go into high volume production, so I need to know it will work if I have a batch of sensors on the lower side at 1.8us.

There are a number of posts touching on the topic, but none seems definitive or accurate.  They are also not always clear about whether or not it's a hardware or firmware limit.

This post suggests 2us for DETECT events, 50-60us for PORT events.  (This is also where modifying the nrfx_gpiote_irq_handler() function was suggested)
devzone.nordicsemi.com/.../88993

This post suggests 20us for a port event:
devzone.nordicsemi.com/.../minimum-pulse-width-for-sense-on-nrf52832

This post claims 250ns for a DETECT event:
devzone.nordicsemi.com/.../gpiote-interrupt-resolution

This post claims 10uS for a DETECT event:
devzone.nordicsemi.com/.../minimum-pulse-length-to-detect-low-level-with-gpio-sense-for-nrf52


What's the official word from Nordic?

[Kenneth]

The reasoning behind the different answers is due different use cases, for instance what state the nRF52 is in (e.g. system off, on idle, power down or constant latency mode), it also depends on whether you need to wakeup to read the state of the GPIO or not (this will include delay due to turning ON regulators and clocks, before cpu is executing, and interrupt latency through for instance the softdevice before reading the pins). So I think all the values you are pointing to are correct for the specific use cases. 

If I understand your requirements you are basically in system ON idle and only have one pin that you need to wakeup on, and you don't need to read which pin that triggered the wakeup, since it's only one pin that can trigger the PORT event in any case. In this case you will be fine using PORT event to handle short pulses of only a few us, the most relevant answer in your case is then:
https://devzone.nordicsemi.com/f/nordic-q-a/27346/gpiote-interrupt-resolution