IRAM_ATTR and IRQ handlers

[davepl]

I get that my IRQ handler must be in "fixed" memory, or perhaps on WIndows NT what I would have called "nonpaged pool" so that it's always present when the interrupt fires.

What I don't understand is why that's not also true of everything that the IRQ touches, like global variables perhaps. Or, once control is in the hands of the handler running in IRAM, can it touch anything it wants? It's as though the MMU can't be involved in getting the interrupt code but once loaded, the interrupt code can do whatever it wants with respect to invoking the MMU?

Thanks!
Dave

[WiFive]

Either the interrupt is iram/dram safe meaning it can run when flash/spiram caches are disabled or it isn't. If it isn't then it can use cache memory but will be disabled when cache is unavailable. When you register the interrupt you tell the system what kind it is by specifying flags.

[davepl]

I thought it was about the MMU, not caches. What has cache memory got to do with it? Can you explain? Your reply doesn't really answer my question, but I'm interested to hear what you're referring to.

I thought IRAM_ATTR ensured that the lower memory was paged in at all times, that's all. ie: marking your function with it ensures your code is in low DRAM so it's never paged out when the interrupt happens. No?

[WiFive]

IRAM_ATTR places the code into internal (nonpaged physical) IRAM as opposed to where code is placed by default which is into flash and then executed "in place" from the (paged virtual) cache which is controlled by the MMU.

[davepl]

Thanks! So what of the -variables- that the IRQ code must touch, such as a counter for example. Must they be marked IRAM_ATTR as well, or just the -code- and not the -data-?

[WiFive]

If it is a variable it will be placed in dram but if it is a constant:

https://dl.espressif.com/doc/esp-idf/la ... m-data-ram