2020-07-24 01:16 PM
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.
Solved! Go to Solution.
2020-07-30 08:02 AM
Hello,
A new STM32CubeMX release will delivered to correct this issue as soon as possible.
Best regards,
Nesrine
2020-07-24 02:43 PM
Confirm FreeRTOS fask scheduler does not start after CubeMX6
2020-07-24 02:50 PM
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?
2020-07-24 10:57 PM
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
and this is the same project but at 5.6.1
2020-07-30 06:56 AM
Hello @Panchev68
Thanks for the feedback, issue reported to the tool development team that will plan the correction.
Best regards,
Nesrine
2020-07-30 08:02 AM
Hello,
A new STM32CubeMX release will delivered to correct this issue as soon as possible.
Best regards,
Nesrine
2020-08-19 04:25 AM
Hi @JKaz.1 ,
STM32CubeMX 6.0.1 release solving this issue is available now , you can get it from ST website .
We are sorry for the inconvenience and we are analyzing the issue to learn and improve our upcoming releases.
Best regards,
Houda