STM32F407平台CMSIS-FreeRTOS互斥锁跨线程释放问题咨询

Great question—this is a tricky edge case that pops up when mixing CMSIS abstractions with FreeRTOS's underlying mutex behavior on STM32 devices. Let's break down what's happening and how to track down the root cause:

The Problem Recap #

• Hardware: STM32F407 development board
• Software: CMSIS-wrapped FreeRTOS
• Setup: Two threads sharing access to a hardware radio over UART, using radioAccessMutex to enforce exclusive access
• Bug: SWO logs show Thread 1 successfully acquires the mutex via osMutexWait(radioAccessMutex, 400), but later Thread 2 is seen releasing the same mutex—this should never happen with proper mutex usage.

Likely Root Causes & Fixes #

1. Mutex Handle Corruption or Misinitialization #

This is the most common culprit. Double-check:

• Is radioAccessMutex a global variable (or accessible to both threads via a shared header)? If one thread declares a local variable with the same name, it'll overwrite the global handle, leading to invalid release calls.
  Example of this mistake:

  // Thread 2's faulty code
  void Thread2(void *argument) {
      osMutexId_t radioAccessMutex; // Oops—local handle shadows the global one
      while(1) {
          // This releases an uninitialized local handle, corrupting memory
          osMutexRelease(radioAccessMutex);
      }
  }
  

• Did you validate the return value of osMutexNew()? If it returns NULL (initialization failed), any subsequent osMutexWait/osMutexRelease calls will operate on invalid memory.

2. Illegal Mutex Operations in Interrupt Context #

FreeRTOS mutexes (non-recursive ones) cannot be released from an ISR—they rely on priority inheritance, which doesn't work in interrupt context. If Thread 2's "release" is actually triggered from a UART ISR callback (e.g., you put osMutexRelease in the UART IRQ handler), it'll look like Thread 2 is releasing the lock, but it's really the ISR doing an invalid operation.

• Fix: Check all UART interrupt callbacks—remove any mutex release calls from ISRs. If you need to signal a thread from an ISR, use a binary semaphore instead.

3. Thread Stack Overflow Corrupting the Mutex Handle #

If Thread 2's stack size is too small, stack overflow can overwrite adjacent memory (like the global radioAccessMutex variable). This makes Thread 2's osMutexRelease call target the wrong mutex object, creating the illusion it's releasing Thread 1's lock.

• Quick checks:
  • Increase Thread 2's stack size in its osThreadAttr_t config (try doubling it first)
  • Enable FreeRTOS stack overflow detection: In FreeRTOSConfig.h, set configCHECK_FOR_STACK_OVERFLOW = 2—this triggers a hook function (vApplicationStackOverflowHook) when overflow happens, so you can catch it immediately.

4. Mixing CMSIS & Native FreeRTOS APIs #

If you're using a mix of CMSIS calls (osMutexWait/osMutexRelease) and native FreeRTOS calls (xSemaphoreTake/xSemaphoreGive) on the same mutex, you'll break the internal state of the mutex. FreeRTOS mutexes are recursive semaphores under the hood, and CMSIS wraps them with extra checks—mixing APIs bypasses those checks.

• Fix: Stick to one API set for all operations on radioAccessMutex: either use only CMSIS functions, or only native FreeRTOS recursive semaphore functions (xSemaphoreTakeRecursive/xSemaphoreGiveRecursive).

Quick Validation Trick #

Add a sanity check before every osMutexRelease call to catch illegal releases early:

// Include this at the top of your file to access native FreeRTOS APIs
#include "FreeRTOS.h"
#include "semphr.h"

// In your thread code before releasing the mutex
if(xSemaphoreGetMutexHolder(radioAccessMutex) == xTaskGetCurrentTaskHandle()) {
    osMutexRelease(radioAccessMutex);
    printf("[INFO] Thread %p released mutex\n", xTaskGetCurrentTaskHandle());
} else {
    printf("[ERROR] Thread %p tried to release mutex held by %p\n",
           xTaskGetCurrentTaskHandle(),
           xSemaphoreGetMutexHolder(radioAccessMutex));
}

This will log exactly which thread is trying to release a mutex it doesn't own, and who actually holds it—super helpful for narrowing down the bug.

内容的提问来源于stack exchange，提问作者David K.