Our device communicates with a third-party chip over SPI. Sometimes we need to reset that third-party chip. In our device, there are 3 tasks that use a recursive mutex. This recursive mutex is to control which task can communicate with the third-party chip over SPI.
When we reset that third-party chip, we don’t know which task holds the recursive mutex. But we need the recursive mutex is released to start fresh. That’s because we found the mutex can’t be got sometimes after the chip is reset. This caused the communication between our device and the chip can’t be conducted. I’m wondering if there is a way to force all of the tasks to release this recursive mutex.
Set a global variable that all the tasks that use the mutex check periodically, and have them then release it.
Likely you want to use that variable to mark that you need to reset the chip, and let the task that is doing the operation do it (or give the mutex to let task trying to take it get it).
One key for this is none of those tasks should use indefinite delays, so they don’t get stuck.
Hi Richard,
Thank you for you quick response. I’ll give it a try.
One more question, is it okay to “give” a recursive mutex even if the current task doesn’t own it?
If you really need that functionality, you need to use an ordinary binary semaphore, and give up the priority inheritance.
Of course, then you still end up with broken code, as the task that thinks it has the SPI Channel may still access that hardware after someone else thnks they have been given exclusive control of it.
This is one reason it doesn’t make sense to try to give it from some other task, just taking the mutex doesn’t prevent the conflict, but only limiting your access to the resource when you have the mutex, and that can’t be obeyed if someone can take it from you behind your back.
Is it possible for you to have one of the tasks that hold the mutex perform the reset while holding the mutex, or have the task performing the reset take the mutex to do so?