2024-01-17 02:01 AM
Hello,
I met a HAL_Delay() block. The board worked with internal RCC, and I checked the uwTickFreq when debugging,
it always equal to 0.
Attached the ioc file.
2024-01-17 05:43 AM - edited 2024-01-17 05:43 AM
Hello @lilyGUO, welcome to ST Community,
This could be due to the initialization of the uwTickFreq variable
if the initialization of the HAL_InitTick fails, the frequency remains unchanged whereas uwTickFreq is changed. This could lead to incorrect counting of ticks.
Please make sure that that the HAL_InitTick is successfully initialized and not generating a HAL Error
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2024-01-17 05:37 PM
Sarrs.S ,thank you.
I checked that the HAL_InitTick return OK.
The tickStart can't get the right value to, It always equal to 0 or 0xffffffff..
And in order to check the Internal Clock, I try to run a 50ms TIM2, but it stilled failed.
2024-01-17 05:47 PM
Additional Info:
HAL_Delay() stuck at
while ((HAL_GetTick() - tickstart) < wait)
{
}
and uwTick always equal to 0,
__weak uint32_t HAL_GetTick(void)
{
return uwTick;
}
2024-01-18 12:55 AM
Hello again @lilyGUO
I just came to notice that you're using ThreadX and LevelX, some RTOSs take over the SysTick timer for their own use, so basically, ThreadX "steals" the SysTick interrupt from the HAL
Please try to use a different timer for HAL_Delay() and show us the code (the timer must be started before using HAL, because it will replace the systick)
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2024-01-18 09:08 PM - edited 2024-01-18 09:09 PM
Actually, this issue here refer to the setting of "TrustZone".
If I negative this option when starting the project, the HAL_Delay worked.
Why does this setting impact the Systick?