Skip to content

cpu/esp_common: fix FreeRTOS rmutex handling#21926

Merged
benpicco merged 1 commit intoRIOT-OS:masterfrom
gschorcht:cpu/esp_common/fix_freertos_mutex
Dec 2, 2025
Merged

cpu/esp_common: fix FreeRTOS rmutex handling#21926
benpicco merged 1 commit intoRIOT-OS:masterfrom
gschorcht:cpu/esp_common/fix_freertos_mutex

Conversation

@gschorcht
Copy link
Copy Markdown
Contributor

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

The ESP-IDF WiFi interface wrapper always calls `xSemaphoreTakeRecursive` and `xSemaphoreGiveRecursive` for mutexes, regardless of whether they are recursive or not. Instead of an `assert`, the fix now also checks the type of the mutex in the functions for recursive mutexes and then calls the functions for normal mutexes if the mutex is not recursive.
@github-actions github-actions bot added Platform: ESP Platform: This PR/issue effects ESP-based platforms Area: cpu Area: CPU/MCU ports labels Dec 2, 2025
@gschorcht gschorcht added Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Dec 2, 2025
@gschorcht gschorcht requested a review from benpicco December 2, 2025 14:07
@riot-ci
Copy link
Copy Markdown

riot-ci commented Dec 2, 2025

Murdock results

✔️ PASSED

323d263 cpu/esp_common: fix FreeRTOS rmutex handling

Success Failures Total Runtime
10950 0 10950 14m:36s

Artifacts

@benpicco benpicco added the Process: needs backport Integration Process: The PR is required to be backported to a release or feature branch label Dec 2, 2025
@benpicco benpicco enabled auto-merge December 2, 2025 16:37
@benpicco benpicco added this pull request to the merge queue Dec 2, 2025
Merged via the queue into RIOT-OS:master with commit 4d2cecd Dec 2, 2025
29 checks passed
@leandrolanzieri leandrolanzieri added this to the Release 2025.10 milestone Jan 13, 2026
@leandrolanzieri
Copy link
Copy Markdown
Contributor

Bisecting I came down to this PR, which is causing an issue upon booting gnrc networking on esp8266. @gschorcht any ideas?

> env BOARD=esp8266-esp-12x BUILD_IN_DOCKER=1 make clean all -C examples/networking/gnrc/networking
[...]
> env BOARD=esp8266-esp-12x PORT=/dev/ttyUSB1 flash-only term -C examples/networking/gnrc/networking

2026-01-22 11:18:47,676 # Fatal exception (29): 
2026-01-22 11:18:47,681 # epc1=0x40211e30, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
2026-01-22 11:18:47,686 # Fatal exception (29): 
2026-01-22 11:18:47,692 # epc1=0x40211e30, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
2026-01-22 11:18:47,692 # Fatal exception (29): 
2026-01-22 11:18:47,703 # epc1=0x40211e30, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000
2026-01-22 11:18:47,704 # Fatal exception (29): 
2026-01-22 11:18:47,714 # epc1=0x40211e30, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000

@gschorcht gschorcht deleted the cpu/esp_common/fix_freertos_mutex branch January 26, 2026 06:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: cpu Area: CPU/MCU ports CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Platform: ESP Platform: This PR/issue effects ESP-based platforms Process: needs backport Integration Process: The PR is required to be backported to a release or feature branch Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants