Latest Core - crash at boot with ISR not in IRAM error

[rexlee666]

Basic Infos

• [X ] This issue complies with the issue POLICY doc.
• [X ] I have read the documentation at readthedocs and the issue is not addressed there.
• [X ] I have tested that the issue is present in current master branch (aka latest git).
• [X ] I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• [X ] I have filled out all fields below.

Platform

• Hardware: ESP-12 NodeMCU & others
• Core Version: 2.5.2
• Development Env: Arduino IDE
• Operating System: LinuxMint

Settings in IDE

• Module: [Generic ESP8266 Module|Wemos D1 mini r2|Nodemcu|other]
• Flash Mode: [qio|dio|other]
• Flash Size: [4MB/1MB]
• lwip Variant: [v1.4|v2 Lower Memory|Higher Bandwidth]
• Reset Method: [ck|nodemcu]
• Flash Frequency: [40Mhz]
• CPU Frequency: [80Mhz|160MHz]
• Upload Using: [OTA|SERIAL]
• Upload Speed: [115200|other] (serial upload only)

Problem Description

I upgraded to the latest core this morning from the previous core. Two of my sketches
which use external interrupts, crash at boot up with an errors of ISR not in IRAM
(I have seen this with ESP32 before, but not with ESP8266)
Adding the IRAM_ATTR viz. void IRAM_ATTR test_interrupt(), causes a compiler error
expected initializer before 'test_interupt'

The IRAM_ATTR is not highlighted indicating that it is not supported!

[devyte]

Here it's called ICACHE_RAM_ATTR.
Closing.

edit from @d-a-v: IRAM_ATTR is now also defined in this core

[rexlee666]

Thanks! I could not find any reference in the docs for ESP8266..

[nardev]

What would be the fix?

[devgiants]

Hi,
Got also this on boot error with a simple toggle volatile byte in ISR. Is there anything to do?

[nardev]

I fixed the platform to:

platform = espressif8266@2.0.4

It helped for now.

[d-a-v]

The fix is: add ICACHE_RAM_ATTR just before all functions called from an interrupt (attach_interrupt)

[nardev]

@d-a-v i don't have time to check what changes are in newer arduino core but what i don't like is that pio upload tool doesn't have upload status signaling. You have no idea if it is uploading or not or how much more you need to wait.

[yheynema]

Hi, I'm working on a project involving a WEMOS D1 mini pro board (ESP8266-based). The Arduino IDE been upgraded (to 1.8.9) and so the ESP8266 core (to 2.5.2). In this project I use an RFM69 module and library from LowPower. I got the ISR not in IRAM issue at RFM69 module initialization and fix using the RFM69 library with a proposal by @torntrousers with LoRa library... but RFM69 maintainer sees that more as an ESP bug instead of fixing the RFM69 library. That setup used to work just fine before upgrading the ESP8266 core (I had 2.5.0, I think). How do you guys see that?

[devyte]

In the ESP, all ISRs must be in iram, and all functions called from all ISRs must be in iram, and so on. This has always been a requirement, and not complying has been an endless source of issues akin to "I get a crash after updating" or "I changed code X and now it crashes, I don't know why". Users don't know, or forget about this.
Non compliance means that it may or may not work depending on luck, and unrelated code changes could change that luck. In a recent core version, we are now enforcing that at least the top level ISR function is in IRAM. If it is not, panic with a msg to let you know.
To be absolutely crystal clear, not specifying the iram attr for an ISR is a bug by the user. Enforcement of the top level ISR is now uncovering a whole bunch of such user-side bugs where the attr is missing.

[torntrousers]

Thanks @devyte , I'd wondered about the other functions called by the ISR. In that LoRa library mentioned in a previous comment the ISR uses all this code, so I also need to add the ICACHE_RAM_ATTR to those 3 functions, but are all the ESP8266 core functions used in that code like the digitalWrite and SPI functions already using ICACHE_RAM_ATTR ?

[devyte]

Is that code doing an spi transaction from an ISR??? There are strict timing requirements on the exec time of an ISR in the ESP. Blocking operations are a big no no, and in general ISRs shouldn't take more than a few us. At a glance, I don't think that code will work, at least not with wifi running.
I would advise an ESP user to set a flag in the ISR and execute from the loop, or use the scheduled function api (runs a cb as though it were in the loop).