STM32F407G-DISC1. The project template doesn't work with RTOS (STM32CubeMX 6.0 + lib 1.25).

[NorfLoud]

Creating a template for the STM32F407G-DISC1 project in STM32CubeMX 6.0 (library 1.25). Adding FreeRTOS CMSIS-v1 to the project. Changing the size of the heap and stack to 0x2000/0x4000. Building a project for SW4STM32.

In the StartDefaultTask() task, I add HAL_GPIO_TogglePin(LD4_GPIO_Port, LD4_Pin) to the loop.

But the program always ends up in HardFault_Handler() after osKernelStart(). What am I doing wrong?

[KnarfB]

Same here on my NUCLEO_STM32F446RE. I tracked the hard fault down to the svc instruction in prvPortStartFirstTask. That is probably caused by wrong interrupt settings (BASEPRI 0x80).

This is because osThreadCreate calls xTaskCreate which allocates memory using pvPortMalloc.

pvPortMalloc is "thread safe" protecting itself with a vTaskSuspendAll() at the beginning and a xTaskResumeAll() at its end.

xTaskResumeAll protects itself by vPortEnterCritical and vPortExitCritical and here comes the bug: both functions use uxCriticalNesting which is initialized to 0xaaaaaaaa. So vPortEnterCritical disables interrupts and increments uxCriticalNesting. vPortEnterCritical decements uxCriticalNesting but doesn not re-enable interrupts (as uxCriticalNesting has not reached 0).

So it cannot work and cannot have been tested :(

[KnarfB · Accepted solution]

Okay, I read more on this, and disabling (some) interrupts is intentional.

After reading https://www.freertos.org/RTOS-Cortex-M3-M4.html I added a line to main:

/* USER CODE BEGIN 2 */
  HAL_NVIC_SetPriorityGrouping( NVIC_PRIORITYGROUP_4 );
  /* USER CODE END 2 */

and now my LED is blinking =) That's strange as I never needed that on my F7 boards before.

The same can be achieved by changing System Core > NVIC > Priority Grouping in the configuration (.ioc file).

[NorfLoud]

Interesting... need in "Priority Grouping" set "4 bit for pre-emption..."

STMtmicroelectronics is :pouting_face:

[NorfLoud]

Thank you for your help.

[Amel NASRI]

Hi @NorfLoud​ ,

This is an issue identified in STM32CubeMX 6.0.0 and was fixed in STM32CubeMX 6.0.1 as already confirmed in this discussion.

Please use this latest version in order to avoid updating code each time you generate it.

-Amel