[Solved] [esp-idf] gpio_isr_handler_add Setting Incorrect Interrupt Conditions on ESP32

Hello

I have an unusual problem. The issue is that the gpio_isr_handler_add function is setting incorrect interrupt conditions, or esp32 is checking them incorrectly

.

1.Initially I set NEGEDGE interrupt trigger for gpio 0,2,18.
0 and 18 worked fine but gpio 2 triggered on low state (LOW_LEVEL)

2.I set POSEDGE interrupt trigger for gpio 0,2,18.
0 and 18 worked fine but gpio 2 started on high state (HIGH_LEVEL)

3.I set NEGEDGE interrupt trigger for gpio 0,2,18.
0 and 18 worked fine but gpio 2 triggered on high state (HIGH_LEVEL)

4.I replaced the lines as below. I uncommented gpio2 because it was causing problems earlier Effect was that gpio18 was working fine (triggering with falling edge) and gpio0 was triggering with both edges. Gpio2 obviously disconnected and when I pressed gpio2 and gpio0 it triggered level.
Gpio22 has always worked correctly. Pull-ups on all gpio using resistors

Checking the status of the pins works, this is unlikely to be a physical fault.
Something is going off just how to trace it. I wrote an issue on github but so far no response.
There was a similar problem there but with triggering on both edges and in my case it triggers above that with levels

I don't know if it matters, but on this chip the serial communication doesn't work, i.e. messages at boot up are sent but commands from the program are not
esp32 esp-idf v4.2

GPIO 0 - has internal pull-up if operating in GPIO_MODE_INPUT mode. If GPIO 0 is in the low state at startup, the ESP will not run code from the flash.
GPIO 2 - this is normally connected to the LED on the board, unless you are directly using the ESP module itself.
I suggest you swap GPIO 0 and 2 for a different set of pins.

I am using the ESP module itself on a proprietary PCB which I will no longer change. I purposely connected the buttons to GPIO0 GPIO2 so that holding the two buttons and starting the chip would enter download mode. It looks like I will have to make a mess, i.e. abandon the non-working interrupts and check the pushbutton states with a shuffle every 50ms.

NIXIE_123 wrote:

I use the ESP module itself on a proprietary PCB which I will no longer change.

.
Which doesn't change the fact that GPIO 0 has an internal pull-up.

NIXIE_123 wrote:

to give up not working interrupts

.
You are exaggerating a bit .

Well, I can't say that anything works as I set the trigger to the falling edge and the interrupt runs low all the time (key hold)
.

Which buttons are these specifically?

Classic micro switches. I shorted their leads with crocodiles to rule out non-contact.
Neither are the contacts vibrating, because the button is constantly pressed.
The funny thing is that I held it on the crocodile clips and watched. The interruption was non-stop, but not always.
It was twistedly dependent on the hour, minutes (because it is a watch). For example, 40-59 seconds of silence, a new minute comes and the triggering starts. Then again and so on many times. In the code, the variable storing the time is absolutely independent of the interrupt.
And I don't think it is normal that the triggering conditions depend on the order of the lines in the code. As I wrote in the 1st post, when I changed the order the conditions changed.

For me the options are three:
-defective framework
-Damaged esp
-TTM (this type has it)

NIXIE_123 wrote:

The funny thing is I kept it on the crocodiles and watched. The interrupt was triggering nonstop, but not always.

.
To start with, I suggest you install 10-100 nF ceramic capacitors in parallel with the buttons. Right next to the buttons.

Or: https://github.com/craftmetrics/esp32-button
I myself rather rarely operate the buttons directly via interrupts.

NIXIE_123 wrote:

it is probably not normal that trigger conditions are dependent on the order of lines in the code.

.
This is true. I have never encountered this.

Problem traced.
The interrupts work and all too well (sensitive detection). I short-circuited the button with a crocodile and when I removed the lamps the problem is virtually non-existent.
I insert one, it appears. I take one out, it disappears. Checked 5 times. The more lamps I insert, the more often they trigger.
It just so happens that the path from gpio2 runs closest to the cathode paths of the tubes. Interference from switching multiplexed tubes or from the inverter itself is probably induced there.
The interruption from gpio22 always worked because its path is much farther from the lamp cathode paths.
I will do the pushbutton operation in the tape as you advise and that's it.

NIXIE_123 wrote:

It just so happens that the path from gpio2 runs closest to the tube cathode paths. Interference is probably induced there from switching multiplexed tubes or from the inverter itself.

.
That's not good, this interference can still cause problems even if you use sequential button status reading (with debouncing) in the shuffle. I would suggest, however, to short GPIO 2 to ground with a ceramic capacitor (on the track layer side). This will delay the response slightly when the button is pressed, but this is unlikely to be a problem in this case.

You can also use esp-timer to operate the buttons.

Sequential detection in the shuffle works, does not interfere with it