Page 1 of 1

esp-idf V4 GPIO ISR triggers continuously

Posted: Thu Nov 12, 2020 2:01 pm
by CharlesSeartech
Hello,

We are using a WROVER module, silicon revision 1.
I have changed from esp-idf V3.1 to V4.0/V4.1 and have an issue I can't understand.
I'm using GPIO pins 35, 36, 39 and others, not used now, as digital interrupt inputs. Pins 36 and 39 are not setup for ADC use.
My problem is that the gpio_isr_handler keeps getting triggered by IO 36 and 39.
Hardware wise they both have pullup resistors and are negative edge triggered, GPIO_INTR_NEGEDGE.
When I run the V3.1 code on the same HW it works correctly.
I tried the peripherals gpio_example_main.c example, changed the IO's to 36 and 39 and it works correctly.
I'm using many of the peripherals, I2C, I2S, SDMMC, WiFi and UART.
What I have seen is that depending on the CPU load they trigger more or less.
I added the tick time to a struct that saves the IO and pin state and I see that the ISR triggers +- every 102ms on both IO 36 and 39 with no load but the delta changes once I start loading the system.

Does anybody perhaps know why the GPIO interrupts are getting triggered?

Regards,
Charles

Re: esp-idf V4 GPIO ISR triggers continuously

Posted: Fri Nov 13, 2020 10:16 am
by CharlesSeartech
After enabling the another two GPIO interrupts, so there are now five interrupts enabled on GPIO 21, 32, 35, 36 & 39, still only GPIO 36 and GPIO 39 are triggering the gpio_isr_handler repetitively. As stated before the ADC on GPIO 36 and GPIO 39 isn't used. We're using the ADC on GPIO 34.
I have copied the code from the example to make sure there was no setup error introduced by my code.
All five interrupts trigger as expected when the IO state changes and I can handle them. I can see from the time delta I added that they trigger at different times to the +-102ms periodic interrupt. So the interrupts all work as expected if a valid interrupt is triggered.

Can anybody please help shed some light on this matter?

Any help will be greatly appreciated.

Regards,
Charles

Re: esp-idf V4 GPIO ISR triggers continuously

Posted: Fri Nov 13, 2020 12:09 pm
by boarchuz

Re: esp-idf V4 GPIO ISR triggers continuously

Posted: Mon Nov 16, 2020 10:16 am
by CharlesSeartech
Thanks for the update boarchuz.

So just for others with a similar problem:

After disabling most of the peripherals to try determine what is causing the IO 36 & 39 GPIO interrupts, I have found that it's the WIFI itself. Basically once esp_wifi_start() is called then the interrupts start. I added a delay before esp_wifi_start() is called and the interrupts don't trigger until esp_wifi_start() is called.

From "[TW#15819] GPIO 36 & 39 input interrupt continually fires for high input when ADC1 is also in use (IDFGH-3954) #1096" on Github:
All the comments (in code) as well as section 3.11 as part of https://www.espressif.com/sites/default ... p32_en.pdf only either state:
a) WiFi should not be used together with ADC unfortunately I don't see this in V2.3 of the doc!
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!"



My question is then why did it work in IDF V3.1 and not now?
I have also been using multiple edge triggered interrupts without an issue or at least that didn't bother me.

Regards,
Charles