Timebase Source TIM1: wrong initialization in MX code

[GModu.1]

I selected TIM1 as Timebase Source of HAL libraries. I think the generated code from MX tool is wrong.

HAL_InitTick() is called two times: the first during HAL_Init(), the second during SystemClock_Config(). However the first time is called as HAL_InitTick(TICK_INT_PRIORITY), the second time is called as HAL_InitTick(uwTickPrio).

uwTickPrio is normally updated during HAL_InitTick() defined in _hal.c, when Systick is used as timebase source. When TIM1 is used, HAL_InitTick() defined in _hal_timebase_tim.c doesn't update the variable, that still have the init value, an invalid priority.

So the second time HAL_InitTick() is called, an assert is fired during HAL_NVIC_SetPriority().

void HAL_NVIC_SetPriority(IRQn_Type IRQn, uint32_t PreemptPriority, uint32_t SubPriority)
{
  uint32_t prioritygroup = 0x00;
 
  /* Check the parameters */
  assert_param(IS_NVIC_SUB_PRIORITY(SubPriority));
  assert_param(IS_NVIC_PREEMPTION_PRIORITY(PreemptPriority));
 
  prioritygroup = NVIC_GetPriorityGrouping();
 
  NVIC_SetPriority(IRQn, NVIC_EncodePriority(prioritygroup, PreemptPriority, SubPriority));
}

[Dave Nadler]

@GModu.1​ Pozz - Make sure to upload your project and IOC files (or clean and ZIP the whole mess) so STM can easily reproduce the problem...

[Panometric]

@GModu.1 I think this is an unresolved bug: See: https://community.st.com/s/question/0D50X0000BGvYPsSQN

I am also fighting this issue, but I don't think the two calls is a problem at all, one is done very early in HAL_Init(), then the second is in SystemClock_Config after adjustments are made to RCC. I think both are valid, as the HAL needs to maintain a timeout method at all times.

The assert is an issue, which comes back to this definition:

uint32_t uwTickPrio = (1UL << __NVIC_PRIO_BITS);

It seems to me the assert is correct, and the definition is wrong. But I am not certain. What seems to work for me is to change it to:

uint32_t uwTickPrio = (1UL << __NVIC_PRIO_BITS) -1 ;

This results in 15, which seems to agree with my freeRTOS config of:

LIBRARY_LOWEST_INTERRUPT_PRIORITY 15

configLIBRARY_LOWEST_INTERRUPT_PRIORITY must be between 1 and 15.   

My assertion is that the HAL tick and the freeRTOS tick should be at the same priority and can and should both be hooked into the same timer.

Anyone see a flaw in my logic?

[GModu.1]

@Panometric​  I choosed to fix the issue in another way.

I noticed uwTickPrio variable is updated during HAL_InitTick() in _hal.c when SysTick is used a timebase source, but it isn't updated in HAL_InitTick() defined in _hal_timebase_tim.c. So I think the correct fix to this issue is to update the variabile in all HAL_InitTick() functions.