Hi, going through the code of portZynq7000 I have noticed that configASSERT calls the vTaskEnterCriticalFromISR function regardless of the interrupt priority. In fact, unlike other task/queue fromISR APIs, vTaskEnterCriticalFromISR lacks the control on the priority of the calling interrupt (portASSERT_IF_INTERRUPT_PRIORITY_INVALID). While this has never created a problem during the tests with the Zynq-7000 SMP demo function prvTimerHandler, I wanted to ask if it can have undesired effects.
Since the intent here is to just enter an infinite loop with interrupts disabled, the only possible undesired effect would be if vTaskEnterCriticalFromISR checked the priority level and asserted if invalid, as that would create an assert loop that would overrun the ISR stack, destroying context.
Right, thank you. I just wanted to verify if calling such function without checking the interrupt priority complied with the following statement:
Interrupts assigned a priority above the configMAX_API_CALL_INTERRUPT_PRIORITY setting will not be effected by RTOS critical sections, and will nest, but cannot call any FreeRTOS API functions .
I was not suggesting to check the priority inside vTaskEnterCriticalFromISR, I would have implemented a separate non-asserting control function in the port.
A key point to note is that the “cannot” isn’t a physical inability, but a functional prohibition, after all, the compiler doesn’t know the priority of the ISR the code is running in to give a compilation message.
Since this is code that only runs when the system is dying, many of the rules are less applicable.
1 Like