Delay in sense interrupt

RE: Delay in sense interrupt

Kenneth — Thu, 11 Jun 2020 07:44:26 GMT

[quote user="Alex Crombie"]I will have a look at the example[/quote]

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

RE: Delay in sense interrupt

Alex Crombie — Thu, 11 Jun 2020 07:23:25 GMT

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

RE: Delay in sense interrupt

Kenneth — Wed, 10 Jun 2020 12:37:44 GMT

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?

RE: Delay in sense interrupt

Alex Crombie — Wed, 10 Jun 2020 10:48:23 GMT

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

RE: Delay in sense interrupt

Alex Crombie — Wed, 10 Jun 2020 09:03:00 GMT

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

RE: Delay in sense interrupt

Kenneth — Wed, 10 Jun 2020 08:41:18 GMT

Some question that may help me understand;

- If you are not using LDETECT, then I assume the result is the same.
- If you are using logic high fast ramp up (<1us) on input, do you see the same delay then?
- Do you have any oscilloscope trace of the input?
- What GPIO pin# are you using as an input here?

Best regards,
Kenneth

RE: Delay in sense interrupt

Alex Crombie — Tue, 09 Jun 2020 13:07:02 GMT

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().

RE: Delay in sense interrupt

Kenneth — Tue, 09 Jun 2020 11:31:01 GMT

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?