2016-01-23 11:27 PM
Hello everybody,
When I use FreeRTOS, the cubemx generates following code forSysTick_Handler()
:void SysTick_Handler(void)
{ /* USER CODE BEGIN SysTick_IRQn 0 */ /* USER CODE END SysTick_IRQn 0 */ osSystickHandler(); /* USER CODE BEGIN SysTick_IRQn 1 */ /* USER CODE END SysTick_IRQn 1 */ } Therefore,HAL_Delay()
doesn't work. When we use LSI, HAL library will callHAL_Delay(1)
function while initializing clock inSystemClock_Config()
and the program will go to infinite loop. So I added this code toSysTick_Handler()
:void SysTick_Handler(void)
{ /* USER CODE BEGIN SysTick_IRQn 0 */ /* USER CODE END SysTick_IRQn 0 */ osSystickHandler(); /* USER CODE BEGIN SysTick_IRQn 1 */ HAL_IncTick(); /* USER CODE END SysTick_IRQn 1 */ }I hope this problem solve in next CubeMX versions.
Bests, Misagh2016-01-24 04:30 AM
I am having the exact same issue. But I am surprised that the removal of HAL_IncTick() is intentional as described in the release notes of STM32CubeMX V4.12.0: ''[MX-FreeRTOS/NVIC] HAL_IncTick must be removed and systick prio must be the lowest
when FreeRTOS is activated''So what would be the correct way to implement the SysTick_Handler?
2016-01-25 02:25 AM
Hi,
Thank you for your feedback. The issue is already tracked and reported internally.-Syrine-2016-01-25 10:15 AM
Dear user,
This is an issue. Also, for configurations using freeRTOS, the user shall systematically change the default HAL time-base (systick) to an hardware time-base. HAL time base relative functions are weak to allow the user to select another hardware time-base. In next CubeMX 4.13 version, under the SYS peripheral, it will be possible to select a different timing source for the HAL (tim1, tim2, rtc,...) and automatically generate the functions overloading the weak HAL time base relative functions. This way, RTOS and HAL time-base will be completely disassociated. Note also, that user code placed in the HAL user callbacks should use safe FreeRTOS APIs only. Best regards