cancel
Showing results for 
Search instead for 
Did you mean: 

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()

Brian Khuu
Associate III

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

8 REPLIES 8
Katzenberger.Michael
Associate III

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

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

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

Alexander Smurov
Associate

Same problem.

STM32CubeMX 5.5.0

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

ADunc.1
Senior

I have the same problem on TIM17 ...

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

Torben1
Associate II

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

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

YStei.1
Associate

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