Bug in HAL_SetTickFreq function (F4 v1.23.0, 1.24.0)

[Jungle]

I've already contacted support, so this post is just for community.

There's a bug in HAL_SetTickFreq function (stm32f4xx_hal.c)

---8<---

HAL_StatusTypeDef HAL_SetTickFreq(HAL_TickFreqTypeDef Freq)

{

 HAL_StatusTypeDef status = HAL_OK;

 assert_param(IS_TICKFREQ(Freq));

 if (uwTickFreq != Freq)

 {

  uwTickFreq = Freq;

  /* Apply the new tick Freq */

  status = HAL_InitTick(uwTickPrio);

 }

 return status;

}

--->8---

If HAL_InitTick fails, the frequency remains unchanged whereas uwTickFreq is changed. E.g. I have stm32f407vgt6 working on 168MHz with 1kHz SysTick . I want to set SysTick to 10Hz, so I call HAL_SetTickFreq( HAL_TICK_FREQ_10HZ ). Eventually SysTick_Config fails because (16800000 - 1) is bigger than SysTick_LOAD_RELOAD_Msk (0xFFFFFFUL). But uwTickFreq is already == HAL_TICK_FREQ_10HZ, so the ticks are now counted incorrectly. HAL_SetTickFreq function should be changed to something like this:

---8

...

 if (uwTickFreq != Freq)

 {

  /* Apply the new tick Freq */

  status = HAL_InitTick(uwTickPrio);

  if (HAL_OK == status) {

   uwTickFreq = Freq;

  }

 }

...

--->8---

[Imen.D]

Hello @Jungle​ ,

Thanks for highlighting this issue.

We will check it internally, then we will come back to you with update.

Kind Regards,

Imen

[Imen.D]

Hello @Jungle​ ,

We confirm this issue and passed it along to our development team for fix.

Thanks for your contribution.

Kind Regards,

Imen

[Remi.G]

It appears that the implementation has picked up the proposed fix (I am using U5A5, CubeMX 6.14.0, pack v1.7.0), but that implementation is incorrect.

HAL_InitTick() uses the value of uwTickFreq. Since the "fix" only sets that after the call, the tick frequency never changes.

The correct fix would set uwTickFreq before the call, and restore it if the call fails. Better yet, add frequency as a parameter to HAL_InitTick(), or add a HAL_ChangeTick().