What might be the cause of this assertion?
Why does uxMutexesHeld == 0 not return osErrorResource directly when osMutexRelease is called, but instead triggers an assertion here
These error codes and APIs are not from us. Are you talking about CMSIS wrapper? Can you not use native APIs?
Thank you for your answer.
Yes，is a cmsis wrapped interface； It ultimately calls the xSemaphoreGive interface；
This assertion is happening here：
Are you calling osMutexRelease from an ISR? Can you share your code snippet?
I can’t be sure about this one, because there are so many places to call, I guess it shouldn’t go interrupt, this one is only used in application code！
Do you know in which scenarios this assertion is triggered?
I tried calling the osMutexRelease function twice in a row, but it returns osErrorResource directly on the second call; it doesn’t enter this assertion.
If you try to release a mutex from any other task (or interrupt) than the one holding the mutex.
Here, to determine if it is the current TCB.，If another thread releases it triggers this assertion；
configASSERT( pxTCB == pxCurrentTCB );
Can you paste the callstack when you get this assertion?
Looking at the callstack, a call to fs_mutex_lock leads to osMutexRelease, is that expected? Can you check which task is calling this function? You want to find out if the task that acquired the mutex is releasing it.
In the code fs_mutex_lock is a wrapper around the osMutexAcquire function.
fs_mutex_unlock is a wrapper for the osMutexRelease function.
Then fs_mutex_lock should not end up calling osMutexRelease. Either there is a bug in the code, or it may be memory corruption.
Okay, thank you very much!