Mutex’s can’t work in an ISR. PERIOD. As a Mutex is ‘owned’ by the task that took it.
ISRs do use ‘locks’ of a form, and FreeRTOS itself build ‘critical sections’ inside many of the ‘FromISR’ functions when manipulating structures.
The key is that if you want to lock out between a task and an ISR, you can’t use something like a Mutex, where the second request ‘blocks’. as an ISR can’t block an let the program continue and then resume the ISR, but both sides need to use a critical section so the ISR can’t interrupt the code that needs the locking. This is a fairly ‘blunt’ tool, as it blocks ALL ISRs, not just the ones that might contend for the lock.
It is also possible to use a softer lock, (which could be a semaphore) where the ISR tries to take the lock, and if it fails, it sets up flags somewhere so that when whoever has the lock and releases it, it can see that some other request came in and possibly do the deferred action, or the ISR might do something else to mark the deferred operation. This is what happens if you suspend the scheduler, and an ISR wants to wake a task, since the scheduler is suspended, it can’t directly wake the task, so it adds the task to a list of tasks to wake up, and when the scheduler is resumed, it checks if there are any tasks that need to be woken before returning.