vPortValidateInterruptPriority crash?

[duane-sd]

It a ppears that I am having this problem:

https://community.st.com/t5/stm32-mcus-embedded-software/stm32-freertos-vportvalidateinterruptpriority-assert-crash/m-p/80870#M2550

I understand the intent here.. Basically to do a "critical section" in freeRTOS you raise the current priority to (X), and any IRQ that is above/below (take your pick)(X) - can still occur but cannot call an RTOS api.  This allows highly critical IRQs to continue to occur even when the OS is in a quasi-critical section.

From what I see in the call stack:

a) There ETH_IRQHandler() is called, then HAL_ETH_TxCpltCallback, which calls: xQueueGiveFromISR() which is a FREERTOS API - which then fires the assert.

I can fully understand if I wrote this code and was doing things, yea totally my fault my problem.

But that is not the case here. I just installed CubMX - a week ago [mid-may-2026 for those finding this later via google]  I have not modified the generated app - just using it as is sort of "out of the box" and it fails like this.

To dig in and need to solve this with out of the box code seems just wrong.

What have I modified: A) used MX to generate an APP with Ethernet, USB DEVICE (CDC), SERIAL and a TIMER.

Build it with CUBE-IDE and load on the board and it crashes as described.

This implies the code generator is not generating working code. that seems wrong. Things "out of the box should just work" . Hence my ask.

[Pavel A.]

What is the ETH IRQ priority and configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY in your code?

>  Things "out of the box should just work" 

Yes this would be ideal. But it looks like even "real" AI coding agents require test-and-fix loop, rather than yielding working code at once. 

At least, the generated code builds and produces executable that can be debugged on the target.

[duane-sd]

    #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5

and

     HAL_NVIC_SetPriority(ETH_IRQn, 5, 0);

is what is what the generated code uses. - changing th ETH_IRQn to 7 - gets past that but ... then its the next assert in the same file

configASSERT( ( portAIRCR_REG & portPRIORITY_GROUP_MASK ) <= ulMaxPRIGROUPValue );

Perhaps they *DO* test things but they never test with "configASSERT" enabled in FreeRTOS which I do turn on.

I've tried tweaking a few things and its not helping :(

NOTE - I do not consider the code generated by the STM32 MX tool to be "AI GENERATED" - but perhaps I am wrong, and ST has lowered it self to that level of slop.

[duane-sd]

So I gave up on that - and tried a different WebServer demo in the MX tool - it works :) I can move forward

Still frustrating as hell.

For details:  the WEB SERVER demo (example) for the STM32F4 - works.

If you try to use the components and put something together - thats another problem.

[Pavel A.]

@duane-sd Of course, the CubeMX is not AI yet. Sorry if it was not clear. /* But that's the direction the world is moving */

IRQ at priority 5 should be able to call RTOS with  configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY = 5

> then its the next assert in the same file

> configASSERT( ( portAIRCR_REG & portPRIORITY_GROUP_MASK ) <= ulMaxPRIGROUPValue );

This is strange. ulMaxPRIGROUPValue must be initialized in xPortStartScheduler(), and indeed it should be not 0 on STM32H7.  Can it be that ETH interrupt occurs before the RTOS scheduler is started?