Skip to main content
Brian Khuu
Associate III
July 8, 2019
Question

STMHAL STM32L152RETx - If you use TIM2 as the timebase source, it will assert in HAL_NVIC_SetPriority() due to uwTickPrio not being set in the TIM2 version of HAL_InitTick()

  • July 8, 2019
  • 7 replies
  • 2502 views

I set TIM2 as the timebase and then enabled full hal assertion via STM32cube.

It asserted in ../Drivers/STM32L1xx_HAL_Driver/Src/stm32l1xx_hal_cortex.c:197

Stack trace:

Thread #1 (Suspended : Signal : SIGINT:Interrupt)	
	assert_failed() at main.c:455 0x8002ff4	
	HAL_NVIC_SetPriority() at stm32l1xx_hal_cortex.c:197 0x8000782	
	HAL_InitTick() at stm32l1xx_hal_timebase_tim.c:50 0x80030ca	
	HAL_RCC_ClockConfig() at stm32l1xx_hal_rcc.c:956 0x8001546	
	SystemClock_Config() at main.c:279 0x8002f40	
	main() at main.c:185 0x8002f54

I think it's because HAL_InitTick() in .../Src/stm32l1xx_hal_timebase_tim.c does not set uwTickPrio unlike the original in .../Drivers/STM32L1xx_HAL_Driver/Src/stm32l1xx_hal.c

This topic has been closed for replies.

7 replies

Katzenberger.Michael
Associate III
August 10, 2019

It seems to be a bug which is independent of the selected timer.

I ran into the same trouble by only updating my F1 firmware from 1.7.0 to 1.8.0.

If we are using a timer TIMx instead of SysTick as time base source the function HAL_InitTick() of the module stm32f1xx_hal_timebase_tim.c is overwriting the weak defined function of module stm32f1xx_hal.c !!!

Unfortunately the HAL_InitTick() function of stm32f1xx_hal_timebase_tim.c does not set the global variable uwTickPrio and therefore the assert check fails because uwTickPrio is initialized in stm32f1xx_hal.c with an invalid value

/** @defgroup HAL_Private_Variables HAL Private Variables
 * @{
 */
__IO uint32_t uwTick;
uint32_t uwTickPrio = (1UL << __NVIC_PRIO_BITS); /* Invalid PRIO */
HAL_TickFreqTypeDef uwTickFreq = HAL_TICK_FREQ_DEFAULT; /* 1KHz */
/**
 * @}
 */

As a result module stm32f1xx_hal_rcc.c is calling HAL_Init_Tick() with an invalid uwTickPrio value as argument:

0690X0000098PJaQAM.png

As a workaround you can initialize uwTickPrio = TICK_INT_PRIORITY; in the generated main.c file like:

0690X0000098PK9QAM.png

Kilian Nötzold
Associate III
September 2, 2019

Same issu in the H7 1.5.0 Driver.

Fixed it by adding uwTickPrio = TickPriority; in HAL_InitTick of stm32h7xx_hal_timebase_tim.c 

ChristophR
Associate III
November 8, 2019

Same issue here after generating code for a STM32G071 with STM32CubeMX 5.4.0. I'm using TIM2 as timebase source.

Alexander Smurov
Associate
February 17, 2020

Same problem.

STM32CubeMX 5.5.0

STM32CubeF4 Firmware Package V1.24.2 / 06-december-2019

ADunc.1
Senior
March 10, 2020

I have the same problem on TIM17 ...

STM32Cube MCU Package for STM32H7 V1.7.0, STM32CubeMX V5.6.0

Torben1
Associate II
October 1, 2020

Same issue using TIM6 as system timer.

Used STM32CubeMX v6.0.1 to generate code and uwTickPrio never gets set anywhere beyond the default invalid value:

stm32f4xx_hal.c defines uint32_t uwTickPrio  = (1UL << __NVIC_PRIO_BITS); -- Invalid PRIO --

In the generated code uwTickPrio never gets assigned a proper value, causing crash when calling

SystemClock_Config()->HAL_RCC_ClockConfig()->HAL_InitTick(uwTickPrio)->HAL_NVIC_SetPriority()->assert!

Setting uwTickPrio to appropriate priority level before call to SystemClock_Config() in the /* USER CODE BEGIN Init */ block of the STM32CubeMX generated main() resolves the problem.

ChristophR
Associate III
January 31, 2022

Still same issue with CubeMX V6.4.0, FW G0 V1.5.0, TIM2 as timebase source

YStei.1
Explorer
May 11, 2022

Also still same issue with CubeMX V6.4.0, FW_L4 V1.17.x, TIM7 as timebase source