ESP32 Forum

Is there a way to get reliable GPTimer interrupts in the ~50µs range which are not blocked by WiFi? I've a project which relies on accurate timings and I would prefer to handle those in an "per interrupt" fashion and not using the RMT peripheral or similar. However once WiFi is enabled and data is transmitted the interrupts can be blocked up to several milliseconds! So basically with the default settings of having WiFi on core0 you can kiss any realtime behavior goodbye...
Things get better when moving WiFi and TCP/IP to core1 by using:
CONFIG_ESP32_WIFI_TASK_PINNED_TO_CORE_1=y
CONFIG_LWIP_TCPIP_TASK_AFFINITY_CPU1=y

but the jitter is still insane... This is supposed to be a 50µs toggle... Any suggestions how to drastically improve this?

I'm not sure if this will help, but try disabling Wi-Fi power saving mode by calling esp_wifi_set_ps(WIFI_PS_NONE) before esp_wifi_start(). That has helped me before with interrupts on specific ESP32 pins.

A6ESPF wrote: ↑

Sat Dec 17, 2022 10:28 pm

I'm not sure if this will help, but try disabling Wi-Fi power saving mode by calling esp_wifi_set_ps(WIFI_PS_NONE) before esp_wifi_start(). That has helped me before with interrupts on specific ESP32 pins.

Thanks but sadly this didn't help.

This did though:
https://docs.espressif.com/projects/esp ... #iram-safe

By default, the GPTimer interrupt will be deferred when the cache is disabled because of writing or erasing the flash. Thus the alarm interrupt will not get executed in time, which is not expected in a real-time application.

There is a Kconfig option CONFIG_GPTIMER_ISR_IRAM_SAFE that will:
[*] Enable the interrupt being serviced even when the cache is disabled
[*] Place all functions that used by the ISR into IRAM 2
[*] Place driver object into DRAM (in case it is mapped to PSRAM by accident)

This will allow the interrupt to run while the cache is disabled, but will come at the cost of increased IRAM consumption.