ESP.getcyclecount() instruction in ISR causes fatal error: cache disabled but cached memory region accessed on ESP32

[ianwillianb]

I found out that even though the ISR is store in IRAM, by default the instruction ESP.getcyclecount() is stored in flash, so if the access to flash is temporary disabled and an interrupt of type rxbitsISR() occurs the ESP32 ends up crashing.
I understand this is an issue out of the scope of the library, but this fact doesn't make it stable without adding IRAM_ATTR to the function ESP.getcyclecount() on ESP32.
Is there a way to change the way the ISR gets the number of cycles of the CPU, without compromising performance and functionality of the library?

[dok-net]

One could duplicate the inline assembly instructions into the ISR handler... but no, thanks ;-) I'll try to get PR accepted with the ESP32 Arduino team - keep your fingers crossed and wish me good luck with that.
Otherwise, a great many thanks for pointing this out, while I've never seen a crash on the ESP32 myself.
Allow me a question: have you actually done what you said, adding the IRAM_ATTR, and resolved those crashes, or is it a theoretical fix at this time?

[ianwillianb]

Yes, adding the IRAM_ATTR solves the crashes. It is running stable for over 24 hours now, before adding this modification crashes occurred in the the first few minutes of execution.
Doing operations on NVS (only at startup, before calling SoftwareSerial::begin() ), or even having multiples tasks running on both cores could be the cause of the issue in my case, since you've never experience a crash of this kind.
I have to thank you guys for providing this wonderful library :)

[dok-net]

@ianwillianb Could you try my approach in PR espressif/arduino-esp32#3165, which is to inline the machine code in question instead placing the function in IRAM?

[dok-net]

The patch for this issue got accepted at https://github.com/espressif/arduino-esp32.git the other day.