external interrupt jitter

[FL0WL0W]

Hi,

I am having trouble with the external interrupt latency being very inconsistent.

My code for testing the interrupt is as follows

Code: Select all

	void app_main(void)
	{
		gpio_install_isr_service(ESP_INTR_FLAG_LEVEL3 | ESP_INTR_FLAG_IRAM);
		gpio_set_direction(static_cast<gpio_num_t>(35), GPIO_MODE_INPUT);
		gpio_set_intr_type(static_cast<gpio_num_t>(35), GPIO_INTR_ANYEDGE);
		gpio_intr_enable(static_cast<gpio_num_t>(35));
   		gpio_isr_handler_add(static_cast<gpio_num_t>(35), DigitalInterrupt, 0);
   	}

	void IRAM_ATTR DigitalInterrupt(void *arg) 
	{
        	gpio_set_level(static_cast<gpio_num_t>(5), true);
        	gpio_set_level(static_cast<gpio_num_t>(5), false);
	}

I only have 1 interrupt setup to trigger on any edge and I am seeing anywhere from 2us to >50us of latency. I am not using wifi or bluetooth yet so i believe they are disabled. What could be causing the inconsistent latency?

Picture of what i am seeing on the scope. (blue: pin5, purple: pin35)
https://photos.app.goo.gl/K9TW8mLbxzA9aD1t9

Thank you,

[tommeyers]

Can you describe it show the circuit for the source of the interrupt.

And maybe the scope image of the interrupt when not connected to gpio.

Tom

[Victoria Nope]

...
What could be causing the inconsistent latency?

Task switching, because your interrupt input is quite heavily bouncing (from what we can see on your purple colored scope line).

[FL0WL0W]

The circuit is just another microcontroller generating a series of pulses. Pulse width of about 200us.

The input is not heavily bouncing. I just have the scope triggering on both rising and falling edges. Here is another picture with the scope only triggering on the rising edge. Same problem. https://photos.app.goo.gl/VPy8vkNWqpvSC8ob8

Why would task switching be a higher priority than Level 3? This is all done inside the interrupt. How do I lower the priority of task switching?

[tommeyers]

What we are getting at is called Ringing.

It occurs when one signal tries to set the value high and another to set it low. Do you have that?

Is the other processor setting it high and your code setting it low? It looks like it.

Tom

[FL0WL0W]

What we are getting at is called Ringing.

It occurs when one signal tries to set the value high and another to set it low. Do you have that?

Is the other processor setting it high and your code setting it low? It looks like it.

No, You can see in the code that the input is on pin 35 (purple), and the output is on pin 5 (blue).

[ESP_Sprite]

It probably helps to say you have 'persistence' turned on on the scope, as in, the scope image is the result of multiple traces overlaid, not one single trace. I think are lot of people thinking it's ringing or bounce or whatever are mis-interpreting that.

I see nothing particular in your code that should lead to such large jitter... is there any chance you can post your entire project, so we can try to reproduce it?

[FL0WL0W]

Hi ESP_Sprite,

Yes you are correct, i have persistence set to infinite on the scope so i can capture all of the pulses to see the worst case. I've had it running on the bench all day and it looks like worst case is 48us latency, and best case is 2us which has been mentioned in some other posts.

Here is my entire project https://github.com/FL0WL0W/EFIGenieESP32
after you clone the repo, run the gitinit script to setup submodules

right now i currently have the callback disabled and am only outputing to pin 5 for an interrupt coming in on pin 35.

Tomorrow I can create a completely seperate project with only the interrupt being setup and see if that has the same effect

[FL0WL0W]

I created an example project with just the interrupt in it, and a blink task. getting between 2-9us so there is still interrupt jitter. Any idea what could be causing this?

https://github.com/FL0WL0W/ESP32InterruptExample

[ESP_Sprite]

I tried replicating it here; I get about the same behaviour as you. The jitter gets 1/3th less when I increase the CPU speed to 240MHz, so I assume it's due to FreeRTOS task switching critical sections etc.

As to a solution, you could use high-level interrupts to get around this, but these traditionally are written in assembly. I seem to remember recent ESP-IDF versions have some allowances to also run C high-level interrupts, but I don't have the details on that.

Alternatively, it may be enough to run the gpio_install_isr_service call on a task that is pinned to CPU1. As most of the base stuff runs on CPU0, CPU1 has fewer things to mess with the latency.