GPIO36/39 crosstalk (or still in sensor mode)

[philippe_44]

Hi - I have an issue with using GPIO 36&39 with is driving me nuts. I'm using multiple GPIO with interrupts for button. It's in a fairly large application and working fine. As I was a bit short on GPIOs, I added 36 & 39. I'm well aware they can only be inputs and they are also sensor vn/vp. Buttons have a pull-up of 33k (I've tried as low as 2k w/o success)

What happens is that there seems to be some crosstalk in the sense that it *only* GPIO39 is enabled for interrupts then when GPIO36 is pulled down, it also triggers an interrupt on 39.

I've read about the AMP/ADC spurious 80ns pull-down that happens when these blocks are activated, but that's not the case. It does not happen "randomly", but only when the 36 is pulled down. If I reverse the situtation, the same issue happens, just reverted.

I've been down to using just the gpio sample code to confirm the issue. The exact same "buttons" work with all other GPIOs

The only thing that seems to improve the situation is to filter with a pretty large cap (2.2uF) the GPIOs. So it seems that they still behave as if they were not GPIOs, but hall sensors/ADC.

I've tried to use rtc_gpio_deinit, gpio_config, gpio_pad_select, adc_power_off .. no luck

Any hint would be highly welcome!

[boarchuz]

Possibly this (and related issues):
https://github.com/espressif/esp-idf/issues/4585
Does esp_wifi_set_ps(WIFI_PS_NONE); have any effect?

[philippe_44]

The WIFI_PS_NONE removes the unsollicited interrupt that happen all the time otherwise. But it does not change the "crosstalk"

[ESP_Angus]

Hi phillippe,

This sounds like a frustrating problem. It doesn't match any known issue that I'm aware of.

The only thing that seems to improve the situation is to filter with a pretty large cap (2.2uF) the GPIOs. So it seems that they still behave as if they were not GPIOs, but hall sensors/ADC.

This makes it sound a bit like it might be an electrical issue, rather than anything in the digital logic domain. Is it possible it's actual electrical crosstalk? Are the buttons pulled up to the same 3.3V power supply that the ESP32 is powered from? When pressed, do they connect to the same ground as the ESP32? Are both those power connections solid?

Do you have a photo of the setup, by any chance?

If you're sure it's something inside the ESP32, do you have happen to have a simple piece of code that demonstrates this issue? Also, which ESP-IDF version are you suing?

[philippe_44]

Hi - Thanks for your help

This sounds like a frustrating problem. It doesn't match any known issue that I'm aware of.

It is indeed

This makes it sound a bit like it might be an electrical issue, rather than anything in the digital logic domain. Is it possible it's actual electrical crosstalk? Are the buttons pulled up to the same 3.3V power supply that the ESP32 is powered from? When pressed, do they connect to the same ground as the ESP32? Are both those power connections solid?

I agree it seems totally electrical, but what's surprising is that the exact same wiring on other GPIOs does not show that behavior at all. Moving the 2 wires from 36/39 to 4/5 (e.g.) makes the problem go away. All the code is https://github.com/sle118/squeezelite-e ... s/services in button.c. But I have the same result if I use the very simple espressif sample code for gpio and I replace inputs by 36/39 (ignoring the output gpio).

The setup is the wrover 3.3V connected to the push buttons with 33k pull-ups. Push buttons push to ground obviously. The wires are 15cm long and are twisted, which absolutely creates a cross-talk, but that should not matter in the digital domain. With a scope right at the wrover inputs, I can see a few mV (may be up to 20 mV) of cross-talk. So to me it looks like the issue is as if the pins were still acting as analogue (hall sensor) and the digital value is derived from using A/D conversion. That A/D conversion sees a differential glitch which should be filtered out but is not (or something like that ...)

Unfortunately, I'm using a pretty old version of esp-idf: 3.1.5. I will move at some point, but that's a complicated non-regression atm.

[jfrigo]

Hi, late answer, but may be useful for people reading this.
The S_VP (36) and S_VN (39) pins have a built in 270 pF capacitors to S_CAPP (37) and S_CAPN (38).
These capacitors may be the reason for some strange behavior.
I have found the info here: https://learn.sparkfun.com/tutorials/es ... e-overview

[o_0.pikot]

I have same problem) I have custom pcb with esp32 pico d4, and I use gpio34, gpio36, gpio39 with pull-up resistors, and gpio36 doesn't work I tried to read analog data and i see that grpio36 has some small value, but whan I push gpio34 button, gpio36 also became 0.

have you solved your problem?

extra info about connection scheme, which I found
here how to connect capacitor, but strange pull-up resistor

[ESP_Sprite]

If GPIO 36 is not connected and not pulled up or down, the analog value on it will be indeterminate and can indeed be influenced by random stuff like a nearby GPIO.

[o_0.pikot]

If GPIO 36 is not connected and not pulled up or down, the analog value on it will be indeterminate and can indeed be influenced by random stuff like a nearby GPIO.

Thanks for hint! bad chip connection to pulled-up pin (i tested it, and voltmeter on resister pad showed proper value 3.3V), can lead to this pin behaviour. I'l resolder esp32-chip and test it again!