esp_ota_begin (and friends) and RadioLib conflict on SPI bus

[MrSniffer]

I am developing on the Heltec WSL V3 (SW1262) board. I am using the ESP-IDF OTA functionality to update code residing in a ~4MB partition. I was opening the partition using
esp_ota_begin(newPart, OTA_SIZE_UNKNOWN, &update_handle);
which was taking 2700 msec (!) to complete. While this was underway, a higher priority task used RadioLib to transmit data, which lead to SPI conflicts (error codes -705 and -707 typically).
I have minimized this specific call by using
esp_ota_begin(newPart, OTA_WITH_SEQUENTIAL_WRITES, &update_handle);
instead (which doesn't erase the flash).
I also added a binary semaphore to gate access to the higher priority RadioLib transmit call until esp_ota_begin returns.

But there are lots of other esp_flash operations lurking around, e.g. esp_set_boot_partition which take significant real time. Do I need to use a semaphore on each one or is this some bug in ESP-IDF (V4.4.4)? Is this somehow a RadioLib issue with a workaround?

[jgromes]

I'm guessing that the flash in question is an external SPI flash connected to the same SPI bus as the radio. In that case, the SPI is a shared resouce, and since you are (probably) in a multi-threaded environment (FreeRTOS) you need to guard that resource with a mutex/semaphore. But I would be surprised if ESP-IDF didn't do that already, that would be a significant oversight - unless they expect the users to implement that themselves.

Are you using the Arduino ESP32 core or just plain IDF?

[HeadBoffin]

is this some bug in ESP-IDF (V4.4.4)? Is this somehow a RadioLib issue with a workaround?

Neither - two tasks trying to access the same hardware resource at the same time can't be anticipated by either provider. You need to design your system architecture to deal with the potential clash interactions.