[bug] Issue generating code for freeRTOS using CubeMX 6 (I think)

Forum|Forum|6 years ago
July 24, 2020
6 replies
1784 views

I think there is a bug in the new CubeMX 6.0 when generating code using freeRTOS. It may just be when migrating from an older CubeMX project to a newer one, I'm not sure.

I updated a project that was built using CubeMX 5.3 to CubeMX 6 and rebuilt all the files. While there was an issue with the Call to HAL handlers being unchecked under the NVIC controls so that all the interrupt handlers no longer called the HAL files, that was at least easily fixable. However, I did notice a change to the SysTick interrupt with regards to freeRTOS

Below is the code generated by CubeMX 5.3

void SysTick_Handler(void)
{
 /* USER CODE BEGIN SysTick_IRQn 0 */
 /* USER CODE END SysTick_IRQn 0 */
 HAL_IncTick();
#if (INCLUDE_xTaskGetSchedulerState == 1 )
	if (xTaskGetSchedulerState() != taskSCHEDULER_NOT_STARTED)
	{
#endif /* INCLUDE_xTaskGetSchedulerState */
		xPortSysTickHandler();
#if (INCLUDE_xTaskGetSchedulerState == 1 )
	}
#endif /* INCLUDE_xTaskGetSchedulerState */
 /* USER CODE BEGIN SysTick_IRQn 1 */
 /* USER CODE END SysTick_IRQn 1 */
}

When it was generated with CubeMX 6, the freeRTOS part was missing:

#if (INCLUDE_xTaskGetSchedulerState == 1 )
	if (xTaskGetSchedulerState() != taskSCHEDULER_NOT_STARTED)
	{
#endif /* INCLUDE_xTaskGetSchedulerState */
		xPortSysTickHandler();
#if (INCLUDE_xTaskGetSchedulerState == 1 )
	}
#endif /* INCLUDE_xTaskGetSchedulerState */

INCLUDE_xTaskGetSchedulerState is still being defined as 1, but more importantly that call to xPortSysTickHandler() is no longer being generated. That's used for incrementing the tick within freeRTOS and deciding if context switch needs to take place based upon that. I can't figure out why this wouldn't be including when generating code. I've searched through CubeMX and did a diff between the old .ioc file and the new .ioc file and don't see any changes related to freeRTOS. If I'm including freeRTOS, this seems like a necessary call for it to work.

This topic has been closed for replies.

Best answer by Nesrine.JLASSI

Hello,

A new STM32CubeMX release will delivered to correct this issue as soon as possible.

Best regards,

Nesrine

P

Panchev68

Senior

Confirm FreeRTOS fask scheduler does not start after CubeMX6

JKaz.1Author

Associate III

I'm not certain what this means. Are you asking me if osKernelStart() is being called after all the MX_***_Init() code? Because it does and that's how CubeMX generated my main.c file. I'm also not sure how that would affect something in an interrupt handler that is no longer being called from said interrupt handler?

Oh yea, I'm using an H7 processor, which might make a difference.

Edit: I took a much older L4 project and updated it to CubeMX6 and regenerated the files. It's SysTick_Handler has the call to xPortSysTickHandler so this seems like an H7 bug?

P

Panchev68

Senior

Upgraded project of F446. Then he did not leave. I put a breakpoint in StartDefaultTask. After starting , he never made it to her. I thought that these childhood diseases of STM32CubeMX have long been overcome. There were similar problems with the initial versions. What struck me was that the priorities of the interrupts are 0 (in the previous version it was 5). I went back to STM32CubeMX 5.6.1. I will wait for new release.

this is at CubeMX 6.0