Crash with framework-arduinoespressif32 Version 2.0.2

[FrankBoesing]

Version/revision of the library used

2.8

Describe the bug

ESP32, Platformio, receive on PIN 34,
framework-arduinoespressif32 @ https://github.com/espressif/arduino-esp32.git#2.0.1
Enabled log prints the warning:

[ 8179][W][esp32-hal-timer.c:271] timerAttachInterrupt(): EDGE timer interrupt does not work properly on ESP32! Setting to LEVEL...

Worse with framework-arduinoespressif32 Version 2.0.2:
Same warning, but even crashes - ESP32 reboots, with unusable callstack-print on first interrupt.

[crankyoldgit]

Well, that's a bummer.

Can you please try older versions of the framework-arduinoespressif32 e,g, https://github.com/espressif/arduino-esp32/releases/tag/1.0.5 for now.

I think this is related to our horrible hack in #1350

Looks like the way they've done the hardware timers has changed in IDF 2.0+

We will have to change how we support hardware timers for the ESP32 for ESP32 IDF < 2.0 (existing) and >= 2.0 (not yet supported)

[FrankBoesing]

Oh, it works perfectly - despite of the "EDGE timer interrupt does not work properly" message with 2.0.1

But it crashes with 2.02.

[crankyoldgit]

That's because 2.0.2 changed how the timers are handled in https://github.com/espressif/arduino-esp32/pull/5931/files
and we have a horrible hack to work around an issue in < 1.5. That hack relies on the previous way timers worked internally.

I'll have to change our code to use the hack for 2.0.1 and not use the hack for 2.0.2.
It will take some time and testing to come up with a working solution.

[NiKiZe]

Can/should we add/have a temporary #error "Timers in 2.0.2 is not yet supported"
And while add it add something similar for some other unsupported platforms ? (those that we get questions about from time to time)

[crankyoldgit]

Can/should we add/have a temporary #error "Timers in 2.0.2 is not yet supported" And while add it add something similar for some other unsupported platforms ? (those that we get questions about from time to time)

I've been working to try to find how to determine via predefined compiler #define for what version arduino-esp32 framework is in use so we can do a greater than/less than comparison. If someone know that off the top of their head, I'd appreciate it.

[FrankBoesing]

Hi, #defines should be in https://github.com/espressif/arduino-esp32/blob/idf-release/v4.4/cores/esp32/esp_arduino_version.h#L22

...But it looks like they are not updated... they still say 2.0.0

[crankyoldgit]

Sigh. I think I have a work around but for the life of me I can't seem to see the #defines exposed in esp_arduino_version.h
e.g.

#include <Arduino.h>  // Which should include esp_arduino_version.h

#if !defined(ESP_ARDUINO_VERSION_MAJOR)
#error ESP_ARDUINO_VERSION_MAJOR not defined
#endif

Results in: (Not from the exact same code as above, but effectively the same)

/home/david/git/IRremoteESP8266/src/IRrecv.cpp:69:2: error: #error ESP_ARDUINO_VERSION_MAJOR not defined
 #error ESP_ARDUINO_VERSION_MAJOR not defined
  ^

Any suggestions?

[crankyoldgit]

Yet,
doing the above for TWO_PI works as expected.

https://github.com/espressif/arduino-esp32/blob/caef4006af491130136b219c1205bdcf8f08bf2b/cores/esp32/Arduino.h#L45

[crankyoldgit]

Any suggestions?

I think my "problem" was assuming that esp_arduino_version.h existed in earlier versions of the framework. Looks like it's a recent addition. i.e. v2 or later

@FrankBoesing I've created a potential fix in branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/Issue1713
Can you please try it out with old and new versions of the library?

[FrankBoesing]

Hi, it works with 2.0.1 and 2.02 now, without warnings. Thank You!!

[FrankBoesing]

Sorry, the warning is still there. Did'nt see it the first time..

However - it works.

[crankyoldgit]

Is the warning exactly the same as before?

What I find interesting is we don't set the EDGE or LEVEL of the interrupt in the timer code.

We do use EDGE on the gpio interrupt. Thus I'm not sure why it's mentioning timers.

[crankyoldgit]

What I find interesting is we don't set the EDGE or LEVEL of the interrupt in the timer code.

Well, I was incorrect it seems. We were unintentionally requesting it. The timerAttachInterrupt() routine was doing the correct thing for us anyway, so the latest change to that branch should address the warning message and have no impact to the library at all.

@FrankBoesing Care to test it again please?

[FrankBoesing]

The warning is no longer shown. Many Thanx!

[FrankBoesing]

I think this can be closed now.

[crankyoldgit]

FYI, the changes mentioned above have now been included in the new v2.8.1 release of the library.