Delay in sense interrupt

[Alex Crombie]

Our setup is using a NRF52832 with SDK15.0.0.

While working with a time sensitive external circuit where we both sample the state of the GPIO and enable LDETECT on it, we noticed that the sampling code detects a transition in pin state much faster than the sensing. In this particular case we were setting the sense level to high.

In order verify that the delay we were seeing is real we implemented a fast polling system, 8 samples per millisecond, that would read the pin value from IN register. We also had sense enabled to measure the delay. From our results we are seeing that there is a 24-25ms delay in the sense interrupt compared to the detection by reading the pin value at the aforementioned sampling rate.

The rising edge is quite slow rising with potential jitter. We would expect it to take between 6 and 22 milliseconds for it to reach logic level high.

Is this expected behaviour? And if so is there any way to reduce this delay?

Otherwise do you have any ideas as to what might be introducing this delay?

P.S. The sense interrupt is configured with priority 0

[Kenneth]

What library or driver are you using to setup sense? I do not think any of the libraries are using LDETECT due to backwards compatibility.

Have you looked at: \examples\peripheral\pin_change_int\ for comparison?

[Alex Crombie]

LDETECT is being setup directly by writing to the registers:

NRF_P0->DETECTMODE = LATCH_DETECT_MODE;
NRF_GPIOTE->INTENCLR = GPIOTE_INTENCLR_PORT_Msk;

The pins are configured using the nrf_gpio library. Specifically we are configuring the pin using nrf_gpio_cfg_sense_input().

The interrupt handler is directly implemented using GPIOTE_IRQHandler().

[Alex Crombie]

1) Because our devices have multiple inputs we do not really have the option to not use the Latched Detection method as we need to know which pin was the one that triggered the interrupt. Having said that when writing a timed polling of the pin, where we read the value directly from the registers we notice it going high ~24ms before the interrupt arrives.

2) We have not measured this case as previously we did not have any external circuit where precise timing was a requirement and a delay of ~25ms in button detection is not noticeable. I can try and measure this for you.

3) I can get a new trace for you. We have traces from previous products using the same circuit which is how we know the expected behaviour

4) The GPIO is pin 16

[Alex Crombie]

Unfortunately due to the lockdown situation it turns out I can't actually get the oscilloscope trace. My apologies for the wrong information 

[Kenneth]

Maybe you need to try to modify a simplified example like \examples\peripheral\pin_change_int\ to see if you can observe the same. 

Do you know if the polling show a consistent logic high signal during the ~24ms period. I am just thinking maybe it is sporadic high during ramp up of pin, while sense may require a few clock cycles consistent high before it trigger the interrupt.

If you have an RTC running, you could just try to log whenever there is a change in polling, and see if it is intermittently high during the pin ramp-up.

Is it possible that the gpiote interrupt handler is processing another gpio here at the same time?

[Alex Crombie]

During the ~24ms it does show a consistent high value, there does not appear to be any jitter in the signal. The sampling period is 125uS so maybe this period is too long to notice any jitter.

The GPIOTE interrupt handler does process all of our inputs however it is designed to execute as fast as possible and only adds an event into the event queue for each input. In addition to this there should have been no changes in the other inputs as they were not being handled. Furthermore this behaviour is consistent across each cycle (100ms) of the pulse detection in the external circuit.

I will have a look at the example

[Kenneth]

Alex Crombie said:

I will have a look at the example

If you are able to recreate the same by modifying \examples\peripheral\pin_change_int\ , please share the program so I can recreate it here also to look into it further.

Best regards,
Kenneth