This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Minimum GPIOTE "low accuracy" pulse width

I have a device with a programmable output pulse width for its data ready signal. I need to be able to reliable receive the pulse so I don't miss any interrupts, and I'd like to do that in the minimum possible time so I can send the device a "power down" command as quickly as possible.

I'm seeing interrupt latency as high as 60uS while the nRF52840 is "advertising". Is there any sort of maximum guaranteed latency for GPIOTE pins in "low accuracy" mode?

  • FormerMember
    0 FormerMember in reply to FormerMember

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

  • 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.

  • FormerMember
    0 FormerMember in reply to FormerMember

    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?

  • 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.

  • FormerMember
    0 FormerMember in reply to FormerMember

    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.

Related