cancel
Showing results for 
Search instead for 
Did you mean: 

STM32U5 HAL_Delay block

lilyGUO
Associate II

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.

 

5 REPLIES 5
Sarra.S
ST Employee

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.

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. 

 

 

lilyGUO
Associate II

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;
}

 

Sarra.S
ST Employee

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.

lilyGUO
Associate II

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?