TickPriority not assigned to uwTickPrio

[Rajeev Arora]

Hello,

Issue 1: assert_failed() triggered

I had observed an issue wherein the file stm32h7xx_hal_timebase_tim.c generated by STM32CubeMX for STM32H753BIT6 has

HAL_InitTick()

implementation different from what is provided on the GitHub repository of STM32CubeH7 (One may refer to file stm32h7xx_hal_timebase_tim_template.c to check a sample implementation).

I am concerned that the STM32CubeMX generated code calls only below inside HAL_InitTick():

/*Configure the TIM2 IRQ priority */
  HAL_NVIC_SetPriority(TIM2_IRQn, TickPriority, 0);
 
  /* Enable the TIM2 global Interrupt */
  HAL_NVIC_EnableIRQ(TIM2_IRQn);
 
  /* Enable TIM2 clock */
  __HAL_RCC_TIM2_CLK_ENABLE();

(where TIM2 is the timer being used by FreeRTOS).

I believe the code should be modified to:

/*Configure the TIM2 IRQ priority */
  if (TickPriority < (1UL << __NVIC_PRIO_BITS))
  {
    HAL_NVIC_SetPriority(TIM2_IRQn, TickPriority ,0U);
 
    /* Enable the TIM2 global Interrupt */
    HAL_NVIC_EnableIRQ(TIM2_IRQn);
    uwTickPrio = TickPriority;
 
    /* Enable TIM2 clock */
    __HAL_RCC_TIM2_CLK_ENABLE();
  }
  else
  {
    return HAL_ERROR;
  }

Please check the line number 8 above (i.e. uwTickPrio = TickPriority;) which is crucial for the code to execute and not result in a call to assert_failed() when macro USE_FULL_ASSERT is defined.

Please share your views.

I have had discussion with STM32CubeH7 team about above (via raising issue number 71 on the respective GitHub issues link). The team has asked me to connect with STM32CubeMX team and share my observations.

Issue 2: value assigned to macro TICK_INT_PRIORITY

Assuming the Issue 1 is not fixed, and the coder assigns

uwTickPrio = TICK_INT_PRIORITY;

before making a call to

SystemClock_Config()

The coder then calls below function inside the FreeRTOS timer interrupt

osMessageQueueGet()

Where, osMessageQueueGet() is wrapper around

xQueueReceiveFromISR()

The observed issue is that as TICK_INT_PRIORITY = 0, the ASSERT / config ASSERT

configASSERT( ucCurrentPriority >= ucMaxSysCallPriority );
 
is triggered inside function vPortValidateInterruptPriority()

Please suggest what should be the value for macro TICK_INT_PRIORITY or whether above line 1 needs a fix.

Thanks,

Rajeev

[Rajeev Arora]

TICK_INT_PRIORITY value defined in one of the STM32CubeH7 tempalate

https://github.com/STMicroelectronics/STM32CubeH7/blob/beced99ac090fece04d1e0eb6648b8075e156c6c/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_hal_conf_template.h#L167

[Rajeev Arora]

Hello @Khouloud ZEMMELI​  ,

Is there a solution for my above concern, I am unable to continue development because of reported issue.

Please help.

Thanks,

Rajeev

[Khouloud ZEMMELI · Accepted solution]

Hello @Rajeev Arora​ ,

About your Issue 1 , the point is internally raised to add the missed line of code.

We are deeply sorry for any inconvenience this may have caused..

Best Regards,

Khouloud

[Rajeev Arora]

Hello @Khouloud ZEMMELI​ ,

Thanks for the update.

May someone look at the concern with xQueueReceiveFromISR(). With uwTickPrio = TICK_INT_PRIORITY and STM32CubeMX assigning value ZERO to macro TICK_INT_PRIORITY, an ASSERT is being triggered, when xQueueReceiveFromISR() / osMessageQueueGet() is called inside the TIMER 2 Timer Interrupt with Timer 2 being used as the FreeRTOS timer.

Please refer to the code line

configASSERT( ucCurrentPriority >= ucMaxSysCallPriority );

inside function vPortValidateInterruptPriority().

Thanks,

Rajeev

[Rajeev Arora]

Hello @Khouloud ZEMMELI​ ,

There is one more observation, that the examples / test FreeRTOS codes shared by STM32CubeMX are assigning 0XF to macro TICK_INT_PRIORITY, where as the STM32CubeMX generated code assigns 0x0 to macro TICK_INT_PRIORITY.

Is there a setting with STM32CubeMX to change the Tick Init Priority value?

Please help.

Thanks,

Rajeev

[Rajeev Arora]

Hello @Khouloud ZEMMELI​  ,

I observe Issue 1 is Fixed in STM32CubeMX released version 6.1.0

Issue wit regards to the two configASSERT() present inside function vPortValidateInterruptPriority() still exists.

The issues are observed when the software interrupt is triggered, with the software interrupt function either reading or writing to the Queue (from ISR).

Regards,

Rajeev

[Rajeev Arora]

Hello @Khouloud ZEMMELI​  ,

Is it possible that the STM32CubeMX provides a way to set macro `1 <= TICK_INT_PRIORITY <= 15`?

Above request if implemented should help fix the `issue 2`.

Thanks,

Rajeev