ESP32 disabling ISR config options to save IRAM

[zazas321]

Hello. I have been optimising my project to save as much IRAM space as possible. I have selected the following settings:

CONFIG_FREERTOS_PLACE_FUNCTIONS_INTO_FLASH=y
CONFIG_ESP32_WIFI_IRAM_OPT=n
CONFIG_ESP32_WIFI_RX_IRAM_OPT=n
CONFIG_SPI_MASTER_ISR_IN_IRAM=n
CONFIG_SPI_SLAVE_ISR_IN_IRAM=n
CONFIG_UART_ISR_IN_IRAM=n

What I am mostly concerned about is the SPI and UART performance since I have disabled these 3 options:

CONFIG_SPI_MASTER_ISR_IN_IRAM=n
CONFIG_SPI_SLAVE_ISR_IN_IRAM=n
CONFIG_UART_ISR_IN_IRAM=n

In my project, I am frequently saving some data to the SPI flash memory and also I am using UART interface to communicate with other devices. I am wondering whether disabling these 3 options will have a negative effect. Has anyone had any experience with these 3 options and whether they are necessary to have a reliably working SPI and UART

[ESP_Sprite]

It'll possibly have a negative effect, as interrupts cannot be serviced while writing/erasing flash. The amount of impact depends on a fair amount of factors, though: data rates you need to sustain, specific protocol details for your peripherals, duration and frequency of flash accesses, even the flash chip in your module and how old it is may impact this.

It would help if you could sketch out your specific use case a bit more: what are you trying to build?

[zazas321]

Thanks for the response. The project is a temperature controller with BLE and WiFi capability. There are certain parameters that I have to save to SPI flash memory but it does not happen very often actually. The configuration is loaded into flash memory and then is not changed unless the user wants to change some settings which I imagine will not be frequent.

Once the device is configured and initialised, the controller main task is to starts measuring and maintaining the temperature of the unit. As I mentioned, I also use 2 UARTs on the ESP32. First UART is for the display that connects to my device and it displays various parameter values, the other UART is used for serial communication via the USB cable. That is pretty much the whole project summed up.



Since I use WiFi and BLE, these are quite heavy on the IRAM memory. I had 89% of the IRAM used up before I performed the optimisations that I have mentioned above. With the above modifications, I have manage to free up quite a bit of IRAM memory ( down to 69% from 89%)

[ESP_Sprite]

Honestly, sounds like you're not going to have much issues then... low data rates, not many flash writes, if something is written it's small (as in: not hundreds of Kbytes); my guesstimates say that should work just fine.

(For a bit more info: specifically for UARTs the way I can see non-IRAM interrupts being an issue is if your datarates are so high and your protocol squirts out so much data that it is possible to receive more than one hardware FIFO worth (iirc 128 bytes by default) without having an interrupt handle the data; you'd get a FIFO overrun then. That seems unlikely in your situation.)

[Ritesh]

Honestly, sounds like you're not going to have much issues then... low data rates, not many flash writes, if something is written it's small (as in: not hundreds of Kbytes); my guesstimates say that should work just fine.

(For a bit more info: specifically for UARTs the way I can see non-IRAM interrupts being an issue is if your datarates are so high and your protocol squirts out so much data that it is possible to receive more than one hardware FIFO worth (iirc 128 bytes by default) without having an interrupt handle the data; you'd get a FIFO overrun then. That seems unlikely in your situation.)

Thanks ESP_Sprite for your prompt response.

We are also facing same issue like lack of IRAM while enabling WiFi and BLE together as per project requirement and we also need to disable same CONFIG_SPI_MASTER_ISR_IN_IRAM to free up almost 4 KBytes of IRAM.

Actually, we are not performing much SPI Flash read and write operation into our application so that it would be helpful to free up IRAM by disabling that option.