Skip to main content
therealergo
Associate II
November 8, 2019
Question

STM32CubeMX bug causing crash when using stm32h7xx_hal_timebase_tim for STM32H7

  • November 8, 2019
  • 3 replies
  • 1323 views

Hi. I'm using STM32CubeMX Code Generation for the STM32H745-DISCO (STM32H745XIHx chip). with firmware STM32Cube_FW_H7 V1.5.0.

When a timer is set as the timebase source for the M7 core, an assert is triggered in the call to 'HAL_NVIC_SetPriority(...)' in stm32h7xx_hal_timebase_tim.c's implementation of HAL_InitTick(...).

This is because HAL_InitTick is called with a TickPriority value of 16, which is invalid.

The default HAL implementation of HAL_InitTick sets the 'uwTickPrio' variable to its parameter 'TickPriority', while the stm32h7xx_hal_timebase_tim implementation does not. This was not a problem with previous firmwares (F7, at least) because the HAL_InitTick function was only called with TICK_INT_PRIORITY as a parameter. With the H7 implementation HAL_InitTick is inexplicably called with uwTickPrio as a parameter in HAL_RCC_ClockConfig(...). Since uwTickPrio is never set, HAL_InitTick is called with an invalid parameter.

A quick workaround is to manually set uwTickPrio to TICK_INT_PRIORITY in main.c.

Attached is a minimal example that demonstrates the problem.

This topic has been closed for replies.

3 replies

Pavel A.
November 11, 2019

This is strange. HAL_Init calls HAL_Init_Tick() with a constant parameter, TICK_INT_PRIORITY, which should be defined in your project's hal_conf.h

https://github.com/STMicroelectronics/STM32CubeH7/blob/e261d820b398846a94f22f4aeb32d86c29546efb/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c#L154

-- pa

therealergo
Associate II
November 12, 2019

Yes, it is strange. The call to HAL_Init_Tick in HAL_Init is correct. It is the generated call to HAL_Init_Tick in HAL_RCC_ClockConfig that has the issue.

Amel NASRI
ST Technical Moderator
November 12, 2019

Hello @therealergo​ ,

I assume this is the same issue as the one reported in https://community.st.com/s/question/0D50X0000BGvYPsSQN.

Please note that it is already tracked internally to be fixed in coming releases of STM32Cube FW packages.

-Amel

To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.
AKana.1
Visitor II
May 24, 2021

Not fixed yet.

The same, as https://community.st.com/s/question/0D50X0000C6duToSQI/halnvicsetpriority-assert-issue-and-incorrect-preempt-priority-value-for-the-stm32f4-stm32g4-?t=1621848277288

Manual fix is manually add somewhere in main()

uwTickPrio = TICK_INT_PRIORITY;

before calling SystemClock_Config();

In USER CODE BEGIN 1 or USER CODE BEGIN Init block