Porting FreeRTOS to STM32 Discovery Board Using STM32CubeIDE

Kernel
21

I did some more debugging and found the following:

  • xTaskCreate() returns 1 , so the task is created successfully.
  • vTaskStartScheduler() is reached, and I stepped into it.
  • Execution then enters xPortStartScheduler(), where it stops at the following assertion:

configASSERT( pxVectorTable[ portVECTOR_INDEX_SVC ] == vPortSVCHandler );

image
image962×600 43.9 KB

From what I understand, this assertion is checking that the SVC vector in the interrupt table points to the FreeRTOS vPortSVCHandler.

Looking at my project, stm32f4xx_it.c contains the default CubeMX-generated handlers:

void SVC_Handler(void) { }
void PendSV_Handler(void) { }
void SysTick_Handler(void)
{
    HAL_IncTick();
}

Also, my FreeRTOSConfig.h does not contain the handler mapping macros:

Is this assertion failing because my interrupt handlers are not correctly routed to the FreeRTOS port handlers, or is there another integration step that I have missed?

22

You’re right it’s an issue with the FreeRTOS handlers.

First, use CubeIDE MX to move the HAL tick to another timer (not SysTick). (Search the forum on this issue if needed.)

Then, delete any of these three handlers that still linger in stm32f4xx_it.c.

Then add this to your FreeRTOSConfig.h:

#define vPortSVCHandler SVC_Handler
#define xPortPendSVHandler PendSV_Handler
#define xPortSysTickHandler SysTick_Handler
23

I configured to use TIM6 instead of SysTick,

image
image766×607 25.4 KB

defined three macro

image
image850×157 4.11 KB

commented other like below

image
image959×252 7.16 KB

Now code stop at HradFault handler

image
image790×627 23.5 KB

24

I have a CubeMX-generated FreeRTOS project that works. Can I use it as a reference when manually porting FreeRTOS, particularly for FreeRTOSConfig.h and the required initialization?

25

Yes, that is a good idea. Do you happen to have the callstack when you hit hard fault handler?

26

The call stack is:

image
image1317×497 44.3 KB

27

You should see what code in pvPortStartFirstTask is at 0x8008718 to see what is making the fault to understand what is the fault. You may need to look at the stack frame being loaded to start that first task.

28

It is likely SVC instruction that is causing the hard fault. Is your code changing SVC priority or priority grouping bits?

Here is a discussion for this issue: SVC call causing hardfault when there is no pre_emption priority.

29

finally found the issue. The problem was this line in stm32f4xx_hal_msp.c:

HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_0);

After disabling (or changing) it, the FreeRTOS scheduler started correctly and my LED task began running.

Your suggestion to look at the SVC call and priority grouping pointed me in the right direction. Thanks again to everyone who helped troubleshoot this with me!

30

Glad that it worked for you!