You protected a shared resource with a binary semaphore and a high-priority task occasionally misses its deadline. What's likely wrong?

A binary semaphore has no priority inheritance, so using it to guard a shared resource leaves you exposed to unbounded priority inversion, which is the likely cause of the intermittent missed deadlines. The pattern: a low-priority task takes the semaphore to use the resource, the high-priority task blocks on it, and medium-priority tasks preempt the low-priority holder so it can't release, extending the high task's blocking time by arbitrary medium work until it misses its deadline. It's intermittent precisely because it only manifests when the medium tasks happen to run during the low task's critical section. The fix is to use a mutex instead of a binary semaphore for resource protection, because FreeRTOS mutexes implement priority inheritance: the holder gets boosted while a higher task waits, so mediums can't preempt it and blocking is bounded to the critical-section length. Beyond switching primitives, you'd also keep the critical section as short as possible (so even bounded blocking is small), avoid blocking on slow operations while holding the lock, and account for one critical section of worst-case blocking in your schedulability analysis. The root lesson is the previous one's rule applied here: mutex to protect (with inheritance), semaphore to signal, guarding a resource with a semaphore is the misuse that reintroduces unbounded inversion.