xQueueTakeMutexRecursive not supported from an ISR

jon-gordon wrote on Thursday, October 13, 2016:

Using Tracealyzer for FreeRTOS, I’m trying to call a vTracePrintF from inside an ISR.
The code works fine for non-ISR and I see my event printed but inside the ISR, I end up with an assert failure because in xQueueTakeMutexRecursive, there is a call to xQueueGenericReceive without checking whether the “fromISR” alternative should be called instead.
Is this an oversight or am I missing something?


edwards3 wrote on Thursday, October 13, 2016:

The trace recorder is source code so you can edit the code to check if you are in an interrupt, but also check if vTracePrintF is ok to call from an interrupt. You would not normally want to call the library printf() from there because its slow, stack heavy and not reentrant.

richard_damon wrote on Thursday, October 13, 2016:

Generally it doesn’t make sense to use a mutex in an ISR, as the ISR has no way to ‘wait’ for the shared resource to become available.

As MEdwards said, ‘printing’ something in a ISR is almost certainly a bad idea,

jon-gordon wrote on Monday, October 17, 2016:

I had figured it was using its own derived version of a printf routine but alas, no, it uses my compiler’s version which attempts to be thread safe by using a mutex - hence the problem.

I’ll stick to SEGGER’s RTT for printing in an ISR then. Would just have been nice to have the interrupt behaviour observed in Tracealyzer but I must be missing something else there.