STM32CubeIde Bug: SysTickIrq priority and subpriority not update

[Kamil Duljas]

Hi,

I found two bugs related to priority group in STM32CubeIde 12.0 and newer. When try change priority group in NVIC tab, for example from NVIC_PRIORITYGROUP_4 to NVIC_PRIORITYGROUP_2, HAL_Init() function always use NVIC_PRIORITYGROUP_4:

HAL_StatusTypeDef HAL_Init(void)
{
  /* Configure Instruction cache through ART accelerator */ 
#if (ART_ACCELERATOR_ENABLE != 0)
  __HAL_FLASH_ART_ENABLE();
#endif /* ART_ACCELERATOR_ENABLE */

  /* Configure Flash prefetch */
#if (PREFETCH_ENABLE != 0U)
  __HAL_FLASH_PREFETCH_BUFFER_ENABLE();
#endif /* PREFETCH_ENABLE */

  /* Set Interrupt Group Priority */
  HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);

  /* Use systick as time base source and configure 1ms tick (default clock after Reset is HSI) */
  HAL_InitTick(TICK_INT_PRIORITY);

  /* Init the low level hardware */
  HAL_MspInit();

  /* Return function status */
  return HAL_OK;
}

 Next bug is related to subpriority of SysTick_IRQn. Below function have hardcoded subpriority for sys tick timer:

__weak HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority)
{
  /* Configure the SysTick to have interrupt in 1ms time basis*/
  if (HAL_SYSTICK_Config(SystemCoreClock / (1000U / uwTickFreq)) > 0U)
  {
    return HAL_ERROR;
  }

  /* Configure the SysTick IRQ priority */
  if (TickPriority < (1UL << __NVIC_PRIO_BITS))
  {
    HAL_NVIC_SetPriority(SysTick_IRQn, TickPriority, 0U);
    uwTickPrio = TickPriority;
  }
  else
  {
    return HAL_ERROR;
  }

  /* Return function status */
  return HAL_OK;
}

[KDJEM.1]

Hello @Kamil Duljas ,

The HAL_Init function is used to Reset of all peripherals, Initializes the Flash interface and the Systick.

This function is described  in stm32f7xx_hal.c drivers as follow: 

* @brief This function is used to initialize the HAL Library; it must be the first

* instruction to be executed in the main program (before to call any other

* HAL function), it performs the following:

* Configure the Flash prefetch, and instruction cache through ART accelerator.

* Configures the SysTick to generate an interrupt each 1 millisecond,

* which is clocked by the HSI (at this stage, the clock is not yet

* configured and thus the system is running from the internal HSI at 16 MHz).

* Set NVIC Group Priority to 4.

* Calls the HAL_MspInit() callback function defined in user file

* "stm32f7xx_hal_msp.c" to do the global low level hardware initialization

So, in the stm32f7xx_hal_msp.c generated file you can find the priority in void HAL_MspInit(void)

In your case:

void HAL_MspInit(void)
{
  /* USER CODE BEGIN MspInit 0 */

  /* USER CODE END MspInit 0 */

  __HAL_RCC_PWR_CLK_ENABLE();
  __HAL_RCC_SYSCFG_CLK_ENABLE();

  HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_2);

Could you please give more detail about the second issue?

Kaouthar

[Piranha]

Could you please give more detail about the second issue?

For HAL timebase interrupt the NVIC subpriority is always set to 0 regardless of the setting in CubeMX. What more detail do you need?

In addition here is another "better" one. The code sets interrupt priority after it has enabled the interrupt. It means that in between those lines the interrupt can happen and be executed with an inappropriate (default is the highest) priority. And it has been like that since the beginning of HAL in 2014...

Both issues are present whether SysTick or other timer is selected as a HAL timebase.

Also the uwTickFreq actually is not a frequency, but a period in milliseconds. Almost every other sanely designed system in the world counts ticks, not milliseconds incremented by steps of several at once. So how can we set the HAL timebase frequency to, for example, 800 Hz? Oh, wait, we cannot! 

Post edited to adhere community guidelines.

[KDJEM.1]

Hello @Kamil Duljas ,

I reported the second issue to our STM32CubeMX team.

Ticket number: 157850 (This is an internal tracking number and is not accessible or usable by customers).

Thank you.

Kaouthar

[Piranha]

The second paragraph in my previous post reports another (third) bug, which is also closely related to the two initially reported ones. 

Post edited to adhere community guidelines.

[KDJEM.1]

Hello @Piranha ,

Thank you for your reporting this HAL/Cube issue and sorry for this inconvenience.

This issue is already reported here.

Internal ticket number: 141253(This is an internal tracking number and is not accessible or usable by customers).

Thank you.

Kaouthar

[Piranha]

The link you gave and the ticket 141253 is about period/frequency issue, which is a bad design, but it's not a bug. And it was described in the 4th paragraph in my particular post, not the second. The second (and third) paragraph is this:

In addition here is another "better" one. The code sets interrupt priority after it has enabled the interrupt. It means that in between those lines the interrupt can happen and be executed with an inappropriate (default is the highest) priority. And it has been like that since the beginning of HAL in 2014...

Both issues are present whether SysTick or other timer is selected as a HAL timebase.

And let's be honest - you missed it two times, because you don't actually understand the issue here. Am I right? 

Post edited to adhere community guidelines.