configASSERT failure in port.c when calling osMessageQueueGetSpace() from ISR context (CMSIS-RTOS2 + FreeRTOS v11)

Hi,

I’m using FreeRTOS v11.0.1 on an STM32H7 microcontroller with the CMSIS-RTOS2 abstraction layer (cmsis_os2.h). During development, I encountered a configASSERT() failure in port.c, specifically at this line:

configASSERT((portNVIC_INT_CTRL_REG & portVECTACTIVE_MASK) == 0);

This occurred when calling osMessageQueueGetSpace() from within an interrupt context (e.g., inside HAL_UART_RxCpltCallback()).

Upon investigation, I found that osMessageQueueGetSpace() internally calls uxQueueSpacesAvailable(), which is no longer safe to call from ISR context in FreeRTOS v11 due to the added assert above.

I initially tried replacing it with:

UBaseType_t space = uxQueueGetQueueLength(queue) - uxQueueMessagesWaiting(queue);

However, both uxQueueGetQueueLength() and uxQueueMessagesWaiting() also trigger the same assert in ISR context in v11.

Eventually, the problem was resolved by switching to:

UBaseType_t waiting = uxQueueMessagesWaitingFromISR(queue);
UBaseType_t  length = uxQueueGetQueueLength(queue);

Since there’s no public API to get the queue length from a QueueHandle_t in ISR-safe manner, the length must be tracked manually or defined as a macro.

Suggestion:
It might be helpful if osMessageQueueGetSpace() internally detects ISR context and uses uxQueueMessagesWaitingFromISR() when appropriate, to maintain CMSIS compatibility with FreeRTOS v11.

Has anyone else encountered this? Is there a plan to adjust the CMSIS layer accordingly for FreeRTOS v11?

Thanks in advance!

The CMSIS-RTOS wrapper comes from ARM. I’d recommend to open an issue on the GitHub repository.

This is mostly a documentation/convention issues, as there is nothing in uxQueueGetQueueLength() itself that will trigger an assert, and it should be ISR safe. (after all, it is just fetching a constant member of the structure).

TRACING it might not be, which could be your issue, if the trace macros use critical sections.