himem page change delays isr

[this.wiederkehr]

I just observed, that when changing the page in the himem api with esp_himem_unmap and esp_himem_map these two calls influence the timing of an isr which is triggered by a pin level change. What is going on here?

Actually I'd like to understand what is going on and probably someone can shed some more light on this. I think it goes like this:

The above mentioned himem api calls do underneath call cache_sram_mmu_set. This call is documented to do

It uses the SPI cache guards to make sure the MMU is idle

So I guess that all memory access going through the cache is somehow delayed by that call, right?
I did place the isr into IRAM_ATTR but not all the memory accessed by the isr is in dram. Will the above cache guards thus delay the execution of the isr because memory access is delayed by the cache guard?

As the call to cache_sram_mmu_set is performed from a low prio task. Cloud it be, that it the task is switched while the cache guard is in place which will enlarge the time the cache guard is in place?

Sorry to bother but I really do not understand the effect of that cache guard and for how long it is in effect.

[ESP_Sprite]

The cache guards can't know if you're trying to access something in flash or PSRAM; it will crash if your interrupt happens to read or write that. (Accessing DRAM or other internal memory is fine; your data doesn't have to be in IRAM, just in internal RAM.)

What you may be running into is that when himem changes a mapping, it needs to flush the cache to make sure all changes are stored back in PSRAM; this not only nixes your performance while that is running but also means that afterwards every bit of data in external memory (flash and PSRAM) that you access needs to be reloaded from the actual chips first.

[this.wiederkehr]

@ESP_Sprite
Thank you for your answer with the explanation about the cache being flushed. I indeed think that this is actually impacting my isr.

Any chance, that I can change my isr in such a way that there is no impacted by the cache having been flushed? Did I understand correctly, that when placing the isr and the data it does access into internal ram I should be fine?

[this.wiederkehr]

To give a rough estimate. the delay due to cache reload is about 3 to 4 ms. Is that expected?

[ESP_Sprite]

Well, the cache is 64K; if it's entirely dirty and needs to be flushed, and if you include refilling it afterwards (which happens gradually when data is requested, so this is a worst-case scenario), it's entirely dependent on the flash/PSRAM SPI speed and bus width. For instance, for the ESP-IDF default of dio and 40MHz, it would take (64K*8 (cache bits) /2 (dio is 2 bits per clock) /40MHz=)6.5ms. You could speed that up by a factor of 4 by switching flash to qio and both flash and psram to 80MHz, but the time will still be in the order of magnitude of a ms or so.

If you place your interrupt in IRAM *and* pass the IRAM flag to the interrupt allocator when the interrupt is allocated, I think it can still run when all this is happening, but I'm not entirely sure how hardware and software interact in this situation. Could be that the entire thing runs in a critical region, in which case the interrupt would *not* be ran, but I don't think so.