STM32 FreeRTOS vPortValidateInterruptPriority assert crash

[FrankNatoli]

Have twin STM32H7B3I Eval systems.

Had I2C between the two working perfectly, using HAL_I2C_***_IT functions, callback on transmit or receive complete calling osEventFlagsSet to notify waiting thread that transmit or receive is complete, no problem.

Also had ADC generating half complete and full complete callbacks, also calling osEventFlagsSet, no problem.

Now have SPI connection between two systems, and suddenly, erratically, have vPortValidateInterruptPriority asserting ucCurrentPriority has a problem with ucMaxSysCallPriority.

Call stack says TouchGFX signalVSync call to osMessageQueuePut is the problem.

This problem was happening at company lab, then went away, then brought systems to home office, and problem has recurred.

What might explain this bizarre behavior?

Edit: edited FreeRTOS file port.c function vPortValidateInterruptPriority to simply return and not check interrupt "validity" and EVAL seems to be running just fine.

Would still like to know what this function is doing.

[Walid ZRELLI]

Hello @FrankNatoli​ ,

FreeRTOS will assert fail if you use an ISR call where your ISR priority is lower than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY parameter. I think that your assumptions about priorities may not be accurate.

Otherwise, if you disable asserts, you are not thread-safe in FreeRTOS. In general, it can still work.

I hope this helps you.

BeST Regards,

Walid

[FrankNatoli]

Walid: thank you for your time and reply.

My understanding is that FreeRTOS permits non-blocking function calls in ISRs, e.g., osMessageQueuePut or osEventFlagsSet.

But there are restrictions on other functions, e.g., osEventFlagsWait, for which the documentation says:

"May be called from Interrupt Service Routines if the parameter timeout is set to 0."

Whereas the documentation for osEventFlagsSet says:

"This function may be called from Interrupt Service Routines."

And for osMessageQueuePut:

"May be called from Interrupt Service Routines if the parameter timeout is set to 0." [which it is]

Am I to understand that the call validity is not as simple as the documentation suggests?

[Pavel A.]

> My understanding is that FreeRTOS permits non-blocking function calls in ISRs

Only in ISRs with priority lower (numerically greater) than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY .

No freeRTOS calls allowed at higher priority.

The "CMSIS RTOS" wrapper can hide and distort things...

> This problem was happening at company lab, then went away, then brought systems to home office, and problem has recurred

Maybe there's some problem when you synchronize between these environments (locally changed files? different version of shared libs?)