cpu/esp_common: fix FreeRTOS rmutex handling [backport 2025.10]

[benpicco]

Backport of #21926

Contribution description

This PR fixex issue #21919.

The reason for the issue was that the ESP-IDF WiFi interface wrapper library always calls xSemaphoreTakeRecursive and xSemaphoreGiveRecursive for mutexes, regardless of whether they are recursive or not.

It would certainly have been better in ESP-IDF to use functions xSemaphoreTake and xSemaphoreGive for all type of mutexes instead, as these functions already check the type of the mutex and then call the functions xSemaphoreTakeRecursive and xSemaphoreGiveRecursive in the case of a recursive mutex.

The fix fix now checks the type of the mutex also in recursive mutex functions and then calls the functions for normal mutexes if the mutex is not recursive.

Testing procedure

Flash e.g. examples/networking/gnrc/networking on any board from the ESP32 family:

BOARD=esp32s3-devkit make -C examples/networking/gnrc/networking flash

You should get an esp-now interface:

> ifconfig
Iface  10  HWaddr: 7C:DF:A1:E2:88:C5  Channel: 6 
          L2-PDU:249  MTU:1280  HL:64  RTR  
          RTR_ADV  6LO  Source address length: 6
          ...

Now try to change the channel with ifconfig 10 set chan 1. Without the PR, you will get an assertion.

> ifconfig 10 set chan 1
cpu/esp_common/freertos/semphr.c:177 => FAILED ASSERTION.

With the PR changing the channel should succeed:

> ifconfig 10 set chan 1
success: set channel on interface 10 to 1
> 
> ifconfig
Iface  10  HWaddr: 7C:DF:A1:E2:88:C5  Channel: 1 
          L2-PDU:249  MTU:1280  HL:64  RTR  
          RTR_ADV  6LO  Source address length: 6

Issues/PRs references

Fix of issue #21919

[riot-ci]

Murdock results

✔️ PASSED

e32942d cpu/esp_common: fix FreeRTOS rmutex handling

Success	Failures	Total	Runtime
10561	0	10561	13m:45s

Artifacts

• Documentation preview