Shouldn't FreeRTOS calls ...FromIsr be IRAM ?

[vortex314]

I was wondering if the FreeRTOS routines which are invoked from an interrupt shouldn't be in the section IRAM ? This to guarantee that they are in RAM memory and don't need to be loaded from Flash during an interrupt ?

Maybe I'm missing a piece of the IRAM/ROM puzzle. Just asking this because I'm working with an external interrupt handler and after random time it breaks , no clear crash dump to analyze. Just garbage on the serial line , probably at 74600 baud.

[ourairquality]

My understanding is that the only code that must be in iram is code touched by the NMI handler (part of the binary sdk), and code that runs when the Flash is not usable for program storage (when flashing). The NMI handler might run even when the Flash is not usable for storage, so need to be in iram.

There might be some interaction with the memory fault handler, the non-aligned access handler, that requires the stack to be in dram, and not in iram.

Optimizing placement of code and data in dram/iram/flash seems application specific, so I generally avoid pinning code to iram unless really necessary or if it is a really hot and small path. The spare iram should be usable for program data in future, but at a cost that unaligned accesses, or non 32-bit accesses hit the fault handler (not such a big issue given that accesses to data in flash already hit this).

[vortex314]

I notice that a lot of forums and sites indicate that ISR's and routines called there should be in IRAM. https://github.com/esp8266/Arduino/issues/1388 https://github.com/esp8266/Arduino/issues/3337 https://github.com/esp8266/Arduino/issues/3416 ... and so on. Just look google for "ESP8266 interrupt IRAM". Is there something different in esp-open-rtos that this doesn't apply ?

[ourairquality]

Esp-open-rtos appears to disable all maskable interrupts when accessing the flash so it does not appear necessary to place maskable interrupt handlers in iram. The first link you supplied above explains that their code uses FLASH_INT_MASK which did not appear to disable all maskable interrupts and that caused their trouble, and suggested adding to that mask or alternatively placing code in iram, so that seems consistent. It mentions that adding to that mask causes the chip to lock up, but perhaps they are using a different approach to mask interrupts. That link also explains that the WiFi interrupt that is not masked.

Now it we are not masking all the maskable interrupts when access the flash then that would be a problem, and any interrupt handlers not masked would need to be in iram, but is that the case?

Btw it may well be possible to expand the iram, reducing the icache, as an option if you need more iram for an application and that might only require some small changes.

[vortex314]

@ourairquality thanks for the elaborate and swift response ! At this stage I've reduced my interrupthandler by a call to xTaskNotifyFromISR() and portEND_SWITCHING_ISR(). Just activating a task at priority 15, which executes all the rest of the logic. The delay between the ISR and the task kicking in is about 20 usec. Keeping my fingers crossed that it remains stable ( 3 hours so far, no heap memory leakage, no stack overflow,.. )

[vortex314]

I thought the interrupt issue was coming from the fact that you wouldn't be able to load code from flash during an interrupt, but the real issue is that loading code from flash could fail because this activity got another interrupt. So the problems can be avoided by 2 approaches : 1/ disable all other interrupts during flash load, 2/ put all interrupt handler code in IRAM.