I don’t want to re-open a solved issue, but I discovered you just need to add ICACHE_RAM_ATTR in front of your ISR function to solve this issue. It tells the compiler to keep the ISR function in memory and is required for ESP core 2.5.1 and later.
Hello my friend. I have the same problem but i dont know where to change the ICACHE_RAM_ATTR void ISRfunction() {} instruction you say. Im using a ESP01 ESP8266 with WifiManager and Blynk. Everything was working fine; i did an upgrade and i think im now on ESP core 2.5.2.
Blynk keeps reconnecting with that ISR not in IRAM! error and i dont know where to fix it. Thanks
Hi Rodrigo_Torres. I’m assuming you have an interrupt being called somewhere in your code which is why you’re getting the error. When attaching the interrupt, you call a function to happen when the interrupt is triggered. That function is referred to as the ISR. The example below is a typical attachInterrupt operation.
Amorphus Thanks a lot my friend. Those kind of help is perfect; im kinda new on this and you save me a lot of work. Now i downgrade the ESP core version but i’ll try that tip you say to make it work on latest one.
Thanks again for your time; i hope i can fix it.
Glad I could save you some time. I’m curious to know if it works for you. Let me know how it goes. Downgrading the library just seemed like a poor solution to me.
I generally agree Pete but I feel those issues should be taken on a case by case basis before downgrading. I would also not consider this particular error an “issue” as it’s just a change to how to do interrupts and it’s covered in section 2.1 of the core documentation. As I understand it, not doing it this way should never have been allowed and we will all need to be doing interrupts this way moving forward.
Excellent, Many Many Thanks, I try to use 2.4.2 as you said before and everithing works fine, the error was gone and solved…
You save me a lot of time, thank you!
Would it be possible for you to give an example of how to include a proper interruption with the new ESP Board Library. I know downgrading works, but this can’t be a permanent solution. If you have an idea on how to implement a simple interrupt, it would be greatly appreciated.
void MyInterruptHandler()
{
// do your interrupt handling stuff in here....
}
Alternatively, you can skip the pre-declaration and do it in the ISR handler like this:
void ICACHE_RAM_ATTR MyInterruptHandler()
{
// do your interrupt handling stuff in here....
}
When you take this approach, your ISR handler MUST appear before your void loop in the sketch, otherwise you’ll get a “not declared in this scope” error when you compile the code (at least when using the Arduino IDE).
Hi Pete, you seem very knowledgable. I am having issues with Blynk and ESP Board Library on anything above 2.4.2, is there a way to make this work with the newer libraries. I have read through your post here and it makes sense, it compiles and uploads, but when I run it, I get the ISR not in IRAM! Abort called and then constant reboots. Any idea?
The simplest way is if you post your code.
Ensure that you post it with triple backticks at the beginning and end though.
Triple backticks look like this:
```
Copy and past them if necessary.
Problem with ISR not IRAM in a WEMOS or ARDUION is that memory for that handle ISR interrupt must be reserved in a section DECLARATION for values in this way for example void ICACHE_RAM_ATTR ServiceLimitSwitchUpperShield_12_D6();
// There are solved for ATTACHINTERRUPT - you must declare this before function SETUP (very important )
In a section SETUP you can define attachInterrupt(digitalPinToInterrupt(12), ServiceLimitSwitchUpperShield_12_D6 , FALLING );
The method ServiceLimitSwitchUpperShield_12_D6 define for example [[ichache_IRAM_ATTR]]
void ServiceLimitSwitchUpperShield_12_D6()
Take attention what memory is need for your souce code . This value give compilator.With abouve 32 KB may also occur problem . Choice MMU from Tools
as 32 KB cache + 32 KB IRAM (balanced ). You can try other option
de sp9auv
ICACHE_RAM_ATTR is deprecated in the latest ESP8266 core versions and will lead to a compilation warning at present, and probably a compilation failure in later releases. You should use IRAM_ATTR instead.