I added the above as a feature request (#89) But I’m thinking it’s a bug. I am developing on an ARM cortex M3 device, IAR C compiler.
The issue for me is that I have a very high speed UART driver, with it’s priority set above FreeRTOS deliberately. It tests __get_BASEPRI() to see if FreeRTOS is in a critical section, and if not may make a call to SemGiveFromISR(), but if it is in a critical section it posts some info to a queue and calls SemGiveFromISR() when it has left the critical section.
This works well on 7.4.0, with configASSERT enabled. On 7.5.2 however, I get an assert failure. The assert is checking for an interrupt priority above FreeRTOS and failing the test.
It seems to me that a better fitting test here would not to be the priority level, but if the interrupt is attempting to make a call to FreeRTOS from within a critical section. That would allow high priority interrupts to call FreeRTOS services when possible, while catching poorly set up NVIC configurations just as effectively.
For my case, the interrupt simply empties/fills char buffers at high speed, notifying application code at much lower priority only when the buffer is empty/full, which is a much less frequent event. Can’t use a DMA because control codes are embedded which need to be processed in the interrupt (it’s a muxer)
Is it reasonable to call this a bug?
Is there a better way of doing this?