Problems in implementing HAL_TIM_PeriodElapsedCallback() function

[alexysob]

Posted on February 21, 2016 at 16:00

Problem is actual in STM32CubeMX (Version 4.13.0 SMT32Cube V1.0) with toolchain IAR EW ARM. When trying to generate code with FreeRTOS with timebase source tuned to TIM3 (or other timer) resulting project has ''HAL_TIM_PeriodElapsedCallback()'' function embedded in ''stm32l1xx_hal_timebase_TIM.c'' module. This module and fuction in it does not contains user code sections, and user can not implement handling of their own interrupts for other timers. Is there any workaround for this problem?

#!timebase #!stm32 #!cubemx

[alexysob]

Posted on February 21, 2016 at 16:19

In addition HAL_TIM_PeriodElapsedCallback() function implemented in stm32l1xx_hal_timebase_TIM.c is

/**

  * @brief  Period elapsed callback in non blocking mode

  * @note   This function is called  when TIM3 interrupt took place, inside

  * HAL_TIM_IRQHandler(). It makes a direct call to HAL_IncTick() to increment

  * a global variable ''uwTick'' used as application time base.

  * @param  htim : TIM handle

  * @retval None

  */

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)

{

  HAL_IncTick();

}

and have no checking of Callback source, thus any other timer interrupt (if enabled) can lead to the call of this function. It is more correct to use if-condition, like below

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)

{

  if(htim->Instance == TIM3) HAL_IncTick();

}

 

[Tesla DeLorean]

Posted on February 21, 2016 at 18:54

I'd go with your latter example where you quantify the source.

[Jeanne Joly]

Posted on May 05, 2017 at 10:01

Hi,

Sorry for the late reply.

This issue was fixed in CubeMX4.15.

We advise you to upgrade with the latest CubeMX release if not already done!

BR. Eric