Minimum GPIOTE "low accuracy" pulse width

RE: Minimum GPIOTE "low accuracy" pulse width

Håkon Alseth — Thu, 20 Jun 2024 10:48:04 GMT

Hi,

You are posting in a very old thread. Could you please create a new ticket on this matter?

Kind regards,

Håkon

RE: Minimum GPIOTE "low accuracy" pulse width

koldybin — Thu, 20 Jun 2024 09:11:27 GMT

Please tell me why the interrupt may not work? If GPIOTE_CONFIG_IN_SENSE_LOTOHI(true) everything works correctly, but the current consumed is 20 microamps more. If GPIOTE_CONFIG_IN_SENSE_LOTOHI(false), then the interrupt does not occur. Increasing the pulse duration to 100 milliseconds did not bring any results. Apart from this, nothing changes in the code. What could be the reason?

Configuration:

NRF52832
Softdevice S132
SDK 17.0.0_9d13099

thanks in advance

RE: Minimum GPIOTE "low accuracy" pulse width

Julie H — Fri, 16 Jun 2017 15:28:29 GMT

Kristin -

Thanks. That's what I'd suspected, but with other development tasks on my plate I'd not gotten around to it.

RE: Minimum GPIOTE "low accuracy" pulse width

FormerMember — Fri, 16 Jun 2017 07:03:59 GMT

The updated answer explains why a longer pulse is required for PORT events, it is related to the GPIOTE IRQ handling in nrf_grv_gpiote.

RE: Minimum GPIOTE "low accuracy" pulse width

Julie H — Thu, 15 Jun 2017 15:02:33 GMT

Kristin - I'm using this code to configure the pin -- GPIOTE_CONFIG_IN_SENSE_LOTOHI(false). That sets SENSE to NRF_GPIOTE_POLARITY_LOTOHI, which is the correct value for what you're asking.

I don't believe the problem is the chip, but the SoftDevice / SDK code.

RE: Minimum GPIOTE "low accuracy" pulse width

FormerMember — Thu, 15 Jun 2017 11:47:41 GMT

The purpose of the example was to test the minimum pulse width required to wake up the chip.

Another way, perhaps the best way to test the minimum pulse width needed for waking up the chip, is to use the NRF_GPIO->LATCH register. For a pin set in SENSE mode, the latch register will register when there has been a signal that will wake up the chip. This can be used to determine the shortest pulse width required to wake up the chip.

Could you test that, and check if up 60 us is required?

RE: Minimum GPIOTE "low accuracy" pulse width

Julie H — Tue, 13 Jun 2017 15:55:46 GMT

3.3 volts with a 40ns or so rise time.

Please keep in mind - we're not trying to output a signal and I suspect the GPIOTE PORT interrupt -> PPI silicon path length is probably better handled and more responsive.

I don't have the page in front of me, but I do recall that there are comments regarding "low accuracy" mode which indicates it may have issues with short duration signals.

RE: Minimum GPIOTE "low accuracy" pulse width

FormerMember — Tue, 13 Jun 2017 12:34:51 GMT

What is the voltage from the external device when generating a wake-up signal?

RE: Minimum GPIOTE "low accuracy" pulse width

FormerMember — Tue, 13 Jun 2017 09:32:26 GMT

I have updated my answer.

RE: Minimum GPIOTE "low accuracy" pulse width

Julie H — Fri, 09 Jun 2017 15:12:48 GMT

No. The main loop does have the chip executing WFI, but since GPIOTE is based on a PORT interrupt, the chip should awaken from WFI and service PORT interrupt.

As an aside, the pin is being triggered on the rising edge, so the GPIOTE driver should be able capture the state of the port and defer processing if the soft device were in the middle of something.

As for 50-60uS, allowed to run long enough, some interrupts were requiring over 120uS for the transition to be captured.

RE: Minimum GPIOTE "low accuracy" pulse width

FormerMember — Fri, 09 Jun 2017 14:29:02 GMT

Okay, I see. In low accuracy mode, is the chip in system OFF? If so, the chip will have to wake up. However, 50-60 uS sounds like quite a bit.

RE: Minimum GPIOTE "low accuracy" pulse width

Julie H — Thu, 08 Jun 2017 13:37:04 GMT

Kristin -

Thanks for the response, but this is for handling an input signal from an external device, not for generating an output signal.

I have an external chip which performs data acquisition. Once every 100ms it asserts its own, external to the nRF52840, "Ready" signal. That signal is connected to a GPIO pin. When that signal is asserted, data must be retrieved or it will be lost.

The issue is that if I use "high accuracy", which consumes more power, the "Ready" signal pulse can be as short as 2uS and the interrupt will be posted to the ISR typically within 10uS. In "low accuracy" mode, which uses "PORT" interrupts instead of "PIN" interrupts and consumes less power, the "Ready" pulse must be more than 50 or 60uS long just to guarantee that the 0 -> 1 transition on that GPIO pin will even be recognized and generate an interrupt at all.

RE: Minimum GPIOTE "low accuracy" pulse width

FormerMember — Thu, 08 Jun 2017 07:39:15 GMT

Updated answer 16.06.2017: The reason why a longer pusle width is required for GPIOTE PORT events compared with PIN events is the following: When using port events, GPIOTE_IRQHandler in nrf_drv_gpiote.h checks the status of each gpio to figure out which gpio that was trigged when the PORT event occurred.

Since the radio has higher priority than GPIOTE when using the softdevice, software processing of the GPIOTE interrupt is delayed until the radio has finished its operations.

Therefore, since the GPIOTE handler checks the state of each pin for PORT events, the triggered pin has to stay high (or low) until that operation is finished.

If you only need to know that a PORT event occurred it is not necessary to check the status of each gpio.

I would recommend you to modify GPIOTE_IRQHandler so that it fits your application and doesn't check the status of each gpio, just reports that a PORT event occurred.