STM32C5 FreeRTOS low-power example hitting ASSERT_DBG_STATE

[DLech.2]

I was playing around with CubeMX2 (Version: 1.1.1) and some examples.

I took the current STM32CubeC5 FreeRTOS low-power example (git tag cadccf7), generated the CMake project, compiled it in STM32Cube for VSCode and started debugging it… which worked fine initially.

I then wanted to enable the “Debug” options inside “HALE System Init” in CubeMX2.

After re-generating the project code and compiling it, it did not run properly anymore.

It always became stuck inside “ASSERT_DBG_STATE(htim->global_state, HAL_TIM_STATE_ACTIVE);” in “HAL_TIM_Stop_IT” located in “stm32c5xx_hal_tim.c”.

The callstack was like this:
mx_freertos_app.c → app_freertos_post_sleep → mx_pwr_exit_low_power → mx_rcc_init → HAL_UpdateCoreClock → HAL_InitTick (in stm32_hal_timebase_tim.c ) → HAL_TIM_Stop_IT

 

My actual questions:

• Is this just a “bug” in the example? If so, how should the code inside “app_freertos_post_sleep” or around it actually look like?
• If this is a problem somewhere else - How can I fix it or when will it be fixed in the drivers/HAL?

   

 

[Saket_Om]

Hello ​@DLech.2 

Thank you for bringing this issue to our attention.

I reported this internally.

Internal ticket number: CDM0066195 (This is an internal tracking number and is not accessible or usable by customers).

[Saket_Om]

Hello ​@DLech.2 

The issue comes from the HAL_InitTick() function in stm32_hal_timebase_tim.c.

In the FreeRTOS low-power example, an HAL_SuspendTick() is called before entering stop mode. So, a first HAL_TIM_Stop_IT() is called and the TIM handle global state becomes HAL_TIM_STATE_IDLE.

Then, after exiting the stop mode, a mx_rcc_init() is performed. When the HAL_InitTick() is called, HAL_TIM_Stop_IT() is called again and the ASSERT_DBG_STATE is trigged as the state isn't HAL_TIM_STATE_ACTIVE.

The check of current HAL_TIM_STATE_RESET is to prevent an assert when the TIM is already running and an HAL_TIM_SetConfig() is called (assert trigged as the state is active).

 

The solution is to prevent the HAL_TIM_Stop_IT() when the state isn't ACTIVE.

Update HAL_InitTick() in stm32_hal_timebase_tim.c as follow :

if (HAL_TIM_GetState(timebase_gethandle()) == HAL_TIM_STATE_RESET)
{
  /* For the first call, initialize the timer timebase */
  if (timebase_init() == NULL)
  {
    return HAL_ERROR;
  }
}
else if (HAL_TIM_GetState(timebase_gethandle()) == HAL_TIM_STATE_ACTIVE)
{
  /* For any other call, if the timer is started, stop it */
  HAL_TIM_Stop_IT(timebase_gethandle());
}
else
{
  /* Nothing to do */
}

The fix will be available in the upcoming releases.