HAL_NVIC_SetPriority assert issue and incorrect Preempt Priority value for the STM32F4 / STM32G4 /...

[OGhis]

i had used used cubemx 5.5 and in 'System Core' => 'SYS' configurated the 'Time Source' as TIM7 and enabled the option 'Enable Full Assert'

On running the project a had an assert that fails over the Preempt Priority value for the timer (TIM7)

The PreemptPriority value for the HAL_NVIC_SetPriority variate from 0-15, but when the HAL_RCC_ClockConfig function is called is this value 16. (max 4 bits long) .

The reason comes from the File STM32F4xx_hal.c where uwTickPrio is defined as follow:

uint32_t uwTickPrio  = (1UL << __NVIC_PRIO_BITS); /* Invalid PRIO */

In main.c with the function HAL_Init() is the PreemptPrioity value correct but with the SystemClock_Config() function is the PreemptPrioity value overridden by the uwTickPrio  value.

The issue comes from the WEAK function HAL_InitTick in the weak function is the uwTickPrio  initialized, but the HAL_InitTick is overridden in the stm32f4xx_hal_timebase_tim.c

So the only possible solution i had found is to add the following code before HAL_NVIC_SetPriority(TIM7_IRQn, TickPriority ,0); in the HAL_InitTick of the file stm32f4xx_hal_timebase_tim.c that was generated by cubemx.

uwTickPrio = TickPriority;

[Vyacheslav]

In STM32WB the same situation in Cube 6.0.1 !!!

[Simon Sq]

I am having the exact same problem with STM32CubeIDE v1.4.2 with CubeMX 6.0.1.20200810643 using the STM32H743.

I applied the fix suggested in the initial post and that did resolve the issue. Is this an appropriate solution? It makes sense to me, otherwise the value of uwTickPro is never changed from its initial (invalid) value of 16.

[Imen.D · Accepted solution]

Hello @Simon Sq​ ,

The proposal fix is to add the following code "uwTickPrio = TickPriority;" in stm32f4xx_hal_timebase_tim.c file before this line:

HAL_NVIC_SetPriority(TIM7_IRQn, TickPriority ,0); under /*Configure the TIM7 IRQ priority */

I'm checking with the development team on the status of this issue.

Our apologies for the delay.

Imen

[Simon Sq]

Thanks @Imen DAHMEN​  I will apply the proposed fix.

[jnewcomb]

EDIT: Fix is below -> I should have clicked the near-invisible 'more answers' link before posting!

[AKana.1]

This fix should be committed into the CubeMX generator,

But right now the user is forced to add somewhere in main():

uwTickPrio = TICK_INT_PRIORITY;

before calling SystemClock_Config(); in

USER CODE BEGIN 1

or

USER CODE BEGIN Init

blocks

[JMein.1]

Hello ST community,

I also enabled the "USE_FULL_ASSERT" and encouter the same problem on CubeMX 6.2.1 so what is here the best work around? Simply overwrite the default value in the define which initialized the uint32_t uwTickPrio = (1UL << __NVIC_PRIO_BITS); /* Invalid PRIO */ by -1 for the lowest priority?

The line

uwTickPrio = TICK_INT_PRIORITY;

sets the priority to the highest one. I guess, this is also not the best solution, or?

In my version, the only point I can find a line of the above one is in __weak HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority)

and this is not called anymore, because the function is now implemented in stm32mp1xx_hal_timebase_tim.c where this assignment is not used anymore.

Any better ideas?

Thank you for your help.

Best regards,

Jan-Otto

[AKana.1]

The code

uwTickPrio = TICK_INT_PRIORITY;

is just copied from __weak HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority)

Seems like generated new HAL_InitTick just miss the same default initialization

[FJahn.3]

Still an issue in version 1.7.0, but inserting "uwTickPrio = TickPriority;" as suggested above works for me

OR Insert the below in the autogenerated main.c file.

 /* USER CODE BEGIN Init */

 uwTickPrio = TICK_INT_PRIORITY; /// Work-around for when "Enable Full Assert" in CUBEMX

 /* USER CODE END Init */

[Charles Miller]

Greetings, ST and @Imen DAHMEN​. This issue continues in CubeMX v6.5 (using STM32F756), as of March 2022. Any status on a fix?