[TW#15819] GPIO 36 & 39 input interrupt continually fires for high input when ADC1 is also in use (IDFGH-3954)

[bpietsch]

I'm finding that when I use GPIO 36 or 39 as an input that when the input signal is high and ADC1 is in use on other pins that the GPIO interrupt repeatedly fires. Disabling use of ADC1 or using other GPIO inputs (such as 37 or 38) does not cause this issue to occur. The values read from 36 and 39 still appear to be correct, but the continual firing of the interrupt is an obvious inefficiency.

See also:
https://www.esp32.com/viewtopic.php?t=1472

[costaud]

Do you have any external pull-up resistor on the GPIOs? Since there are no internal pull-ups on input-only IOs.

[bpietsch]

I have an external pull-down resistor... must it be a pull-up? In any case, this is occurring when the pin is being held high by a constant 3.3v source (not floating).

[negativekelvin]

Bug list has been updated:

3.11. When the power switch which controls the temperature sensor, SARADC1 sensor, SARADC2 sensor, AMP sensor, or HALL sensor, is turned on, the inputs of GPIO36 and GPIO39 will be pulled down for about 80 ns.

[mirko]

All the comments (in code) as well as section 3.11 as part of https://www.espressif.com/sites/default/files/documentation/eco_and_workarounds_for_bugs_in_esp32_en.pdf only either state:
a) WiFi should not be used together with ADC
and/or
b) GPIO36/39 might toggle when RTC peripherals power up (workaround: ignore input in this init phase)

So, if I'm not using ADC I'm fine with using GPIO36/39, hm?
Unfortunately not.

And as far as I can see there's no official info about GPIO36/39 /not to be used at all/ in conjunction with WiFi - no matter if ADC is in use or not.
As a matter of fact, though, when pulling GPIO36/39 high, they toggle states and cause interrupts constantly when WiFi (and one of its power saving modes) is enabled.

This issue hit me really, really hard - and given all the docs and reports I'm aware of now, it's not covered by a single warning / errata entry. I would still not know about it if I didn't walk straight into it. So either I'm overlooking sth. or I'd really appreciate a big fat warning stating sth. alike: "Do expect frequent (internal) state toggles and (bound) interrupts on GPIO36/39 when using WiFi!"

[mirko]

And why on earth do GPIO36/39 only toggle states, when being pulled high? No interrupts triggered when left floating.

[terjeio]

Silicon bug or bad driver code? And it has nothing to do with the ADC, I do not use it.

[wreyford]

I ran into exactly the same issue. I've spent hours reading the documentation and trying to figure out why.
I'm using GPIO36 set up as an input pin for interrupt on falling edge (GPIO_INTR_NEGEDGE), to sense a Capacitive Touch Panel Interrupt, and was getting multiple interrupts being triggered while not touching. At first I thought it was my code.
Eventually I commented out all the other code, and noticed that it worked properly when no Wifi was enabled.
I pulled the IO36 high by wiring it to VCC, then ran the code without Wifi, and got no spurious interrupts, but as soon as Wifi was enabled, I got spurious interrupts in spite of the IO36pin being pulled high by direct connection to Vcc. Perhaps this is a shielding problem with the antennae being so close to IO36, or Wifi is using this pin in an undocumented manner. I hope we get an answer to this problem from Espressif.

[igrr]

Hi folks, sorry we forgot to update this issue when we closed #4117. The issue you are observing is a hardware bug, as mentioned in section 3.11 of https://espressif.com/sites/default/files/documentation/eco_and_workarounds_for_bugs_in_esp32_en.pdf. The workaround for this issue has been recently merged into master branch. A note has been added in the docs on how to enable this workaround in the application: d890a51.

[mirko]

@igrr As mentioned by more than just me in this ticket, 3.11 doesn't cover the issue - at least not sufficiently.
It's not only happening when powering up peripherals and it's not only happening when using ADC.

It's happening without using ADC and during operation, way after peripherals where powered up.
It's also, as I mentioned before, only happening if e.g. GPIO36 is externally pulled high - even when shortcut with VCC, but not when left floating.
3.11 is not just ambiguous about that but (still) not covering those cases at all.

Apart from that, it does not mention WiFi at all. It mentions SARADC1+2, which in fact is related to WiFi, as WiFi power saving uses the ADC, but one has to know that.

EDIT:

Apart from that, it does not mention WiFi at all. It mentions SARADC1+2, which in fact is related to WiFi, as WiFi power saving uses the ADC, but one has to know that.

Ok, that's at least addressed by d890a51, but still not part of the PDF listing the erratas.

[stuartpittaway]

And why on earth do GPIO36/39 only toggle states, when being pulled high? No interrupts triggered when left floating.

Agree - I'm also seeing this issue, no problem when floating, but GPIO36 triggers "fake" interrupts when pulled high and WIFI enabled (I'm not using the ADC or any power saving features)

[HarmOtten]

Is the problem only the fact that interrupts keeps firing?
In that case a workaround could be: Polling GPIO36/39 in the loop.
Am I right?

[mirko]

Why this ticket got closed and/or what's the relation to the issue mentioned here. Is it an acknowledged bug?
If in HW, is it (finally) documented?
If in SW, is it fixed - and if so, when (revision) and where (file / diff)?

[C-Enjoyer]

Hi!
I'm facing similar problems with bluetooth. The moment i call esp_bt_controller_enable(ESP_BT_MODE_CLASSIC_BT) interrupts start to fire constantly on pin 36 and 39.
They are both configured as external interrupts on the falling edge.
Also important to mention: They are pulled up in hw.

[C-Enjoyer]

I figured out a workaround that does the job for me.
In my case the actual pins in hardware are working fine. Eventhough i get incorrect interrupts on the pins, the actual level doesn't change.
I noticed that it's possible to read the correct pin levels via gpio_get_level().
If there is a real exti on the pins, an interrupts get's triggered correctly, too.

So on every interrupt i compare the pin level with the previous pin level and that's how i can figure out if a real interrupt happended.

Pseudo code would be something like that (I don't know how to write proper pseudo code):

int pinLevels[GPIO_PIN_COUNT];

void init(void)
{
    configExti(); // configure all used pins as GPIO_INTR_ANYEDGE
    readPinLevels(); // read pin levels of all exti pins to "int pinLevels[GPIO_PIN_COUNT]"
}

void onExti(gpio_num_t pin)
{
    gpio_ex_extiEvent_t event;
	
    if (!getEvent(&event, pin))
    {
        return;
    }

    // use pin and event here
}

bool getEvent(gpio_ex_extiEvent_t* event, gpio_num_t pin)
{
    int level = gpio_get_level(pin);
    int prevLevel = pinLevels[pin];
	
    pinLevels[pin] = level;
	
    if (prevLevel == 0 && level == 1)
    {
        *event = GPIO_EX_EXTI_RISING;
        return true;
    }
    else if (prevLevel == 1 && level == 0)
    {
        *event = GPIO_EX_EXTI_FALLING;
        return true;
    }
	
    return false;
}

[felixcollins]

I'm seeing this issue with phantom interrupts too. It was working fine then I updated to ADF v2.5-82-gbcad553 and IDF v4.4.4-698-gcc71308e2f and the issue appeared. Before that I was on IDF #3C86C2213C from 20 March 23, so in that time someone broke something in the GPIO interrupts.... The GPIO I'm having issues with is 39. I am running wifi and adc but I set a flag to ignore interrupts during adc operations and when enabling WIFI. My workaround is to set the ints to any edge. Then I set a flag to ignore and further rising ints until I've seen a falling one. Weird how I can get multiple rising edges without seeing a falling edge, but that is what appears to happen.