Stm32H7, CubeMX, CMSIS V2, FreeRTOS: Interrupts disabled while creating new task, but not enabled again until scheduler is started.

[MzMCeotronicsAG]

When creating a new Freertos Task like this:

osThreadNew(StartDefaultTask, NULL, &defaultTask_attributes);

prvAddNewTaskToReadyList(...)

will be called and uses

taskENTER_CRITICAL()

to disable interrupts. This breaks down to the call of void vPortEnterCritical( void )

void vPortEnterCritical( void )

which increases uxCriticalNesting by one.

Before leaving

void vPortExitCritical()

is called. This function should decrease uxCriticalNesting and reactivate interrupts if uxCriticalNesting == 0.

However, uxCriticalNesting was previously initialized with  0xaaaaaaaa. So that uxCriticalNesting == 0 is not reached.

A later call of

osKernelStart();

finally sets uxCriticalNesting to 0 and reactivates all interrupts.

This results in deactivated interrupts between the first task creation and kernel start, which has undesirable side effects such as the systick timer being stopped, which results in a broken HAL_Delay() function.

[Walid ZRELLI]

Hello @Mathieu Münch-zur Megede​ 

This issue has been internally raised. I will keep you posted.

Thanks for your contribution.

BeST Regards,

Walid

[Walid ZRELLI]

Internal ticket number: 114615 (PS: This is an internal tracking number and is not accessible or usable by customers)

[Walid ZRELLI]

Hello @Mathieu Münch-zur Megede​ ,

This is intentional from the FreeRTOS maintainer. Please see this comment.

BeST Regards,

Walid

[Pavel A.]

> systick timer being stopped, which results in a broken HAL_Delay() function.

Let's see. vPortEnterCritical executes vPortRaiseBASEPRI which is raises basepri to configMAX_SYSCALL_INTERRUPT_PRIORITY.

So, interrupts of priority greater than configMAX_SYSCALL_INTERRUPT_PRIORITY will work before the scheduler starts.

These interrupts cannot call FreeRTOS functions anyway.

Just use a different timer for the HAL tick, as recommended by CubeMX/CubeIDE. Set it's priority high.