Evaluate need for the IRAM_ATTR attribute

[josesimoes]

There are a number of functions decorated with this attribute.
According to ESP32 documentation this is only required for debugging and/or for specific ISR handlers.
Adding to this a function with this attribute seems to have a high negative impact in the code performance.

@AdrianSoundy, @MatthiasJentsch care to comment/act? 😉

[MatthiasJentsch]

I'm not sure why these functions have the IRAM_ATTR. But I can take a look at these functions next week. Maybe @AdrianSoundy have a hint why they are decorated with IRAM_ATTR.

[MatthiasJentsch]

I've removed all IRAM_ATTR and my simple blinky app is still working. So I've really no idea why 18 functions are decorated with IRAM_ATTR. I think we can remove all these attributes at least for production code. Maybe it helps with OpenOCD/JTAG debugging if some or all of these functions have the IRAM_ATTR set. http://esp-idf.readthedocs.io/en/latest/api-guides/jtag-debugging/index.html

[josesimoes]

It sure is a requirement for debug. But it looks like that's required for a few other situation, like some ISR.

[MatthiasJentsch]

For the debugging stuff you can use the two hardware breakpoints. You don't need the IRAM_ATTR. All the 18 functions that are decorated with IRAM_ATTR are not ISR's. I detail we have:

• nanoBooter / main.c / main_task - not an ISR
• nanoCLR / app_main.c / main_task and receiver_task - both not ISR's
• 3 HRESULT functions in nanoCLR / CLRStartup.cpp - also not ISR's
• 12 Library function - also not ISR's

Again, I think we can remove all the IRAM_ATTR attributes. I can't think a situation where we need it.

[josesimoes]

So I guess we all in agreement that those can go away. @AdrianSoundy?

[josesimoes]

Fixed with nanoframework/nf-interpreter#718.