Skip to main content
OGhis
Senior
February 10, 2020
Solved

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

  • February 10, 2020
  • 13 replies
  • 8154 views

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;

This topic has been closed for replies.
Best answer by Imen.D

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

13 replies

Technical Moderator
February 13, 2020

Hello @OGhis​ ,

Thanks for your contribution and reported issue.

Can you please share your ioc file for check the project settings and configuration. So, that it will be easier for us to reproduce the issue.

Best Regards,

Imen

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Thanks
OGhis
OGhisAuthor
Senior
February 15, 2020

hi,

Generate the code with cubeMx en set a breakpoint on "Error_Handler()" in main.c and start the debugger and you see the issue.

OGhis
OGhisAuthor
Senior
March 2, 2020

Not yet resolved in HAL lib V 1.2.0 of the STM32G4

OGhis
OGhisAuthor
Senior
March 2, 2020

for library version 1.2.0 for the STM32G4:

Cannot understand why there is an external decalation of the uint32_t uwTickPrio; ==> there is a function uint32_t HAL_GetTickPrio(void) to get the result of the uwTickPrio.

DarkTaipei
Associate II
April 13, 2020

I hit the same issue and took me a while to debug. The problem will also show up when you enable -DUSE_FULL_ASSERT on the FreeRTOS, ThreadCreate example.

All stm32**xx_hal_timebase_tim.c will have a line

HAL_NVIC_SetPriority(TIM1_TRG_COM_TIM17_IRQn, TickPriority, 0), where TickPriority = 1 << 4 => 16.

and in the stm32**xx_hal_cortex.c

void HAL_NVIC_SetPriority() function will check

assert_param(IS_NVIC_PREEMPTION_PRIORITY(PreemptPriority)). This line check if the priority is less than 16. and of course, 16 is not less then 16 so it asserted if you enable the assertion.

Still not fixed?

Tony

DarkTaipei
Associate II
April 13, 2020

I think uwTickPrio is the storage for the HAL library to get the tick priority when necessary. It's a variable initialized with an invalid value (16). Since HAL_INIT is (should be) the first function to call. Inside the HAL_INIT, it will initialized the tick priority according to TICK_INT_PRIO at the stm32_hal_conf.h by calling HAL_InitTick().

The problem here is that the function HAL_InitTick() in stm32**xx_hal_timebase_tim.c, There should add a line

uwTickPrio = TickPriority; after the HAL_NVIC_SetPriority(). so the uwTickPrio will be set to correct value.

Tony

Pavel A.
Super User
April 13, 2020

IIRC this was already reported for CubeMX templates in other STM32 family. And fixed.

-- pa

DUlia
Associate
August 4, 2020

The issue is still not fixed. CubeMX 6.0.0.

Technical Moderator
August 4, 2020

Hello @DUlia​ ,

There is a major issue related to STM32CubeMX 6.0.0: IRQ preemption priorities are set to 0 after project migration.

The correction is ongoing for this issue.

Thank you for your understand.

Best Regards,

Imen

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Thanks
September 11, 2020

In STM32WB the same situation in Cube 6.0.1 !!!

jnewcomb
Associate
January 2, 2021

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

Simon Sq
Associate II
November 4, 2020

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.DBest answer
Technical Moderator
November 4, 2020

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

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Thanks
Simon Sq
Associate II
November 4, 2020

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

JMein.1
Associate III
June 11, 2021

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