Porting STM32L4 vs STM32L5

Hi all,

Until now I had been working with FreeRTOS with a STM32L4, now I am going to start working with an STM32L5.

My first problem has been the different implementation of Porting regarding the SystickHandler.

With the STM32L4 the Systick_Handler was used in the stm32l4xx_it.c and in it the TickCounter of the HALs could be increased with the HAL_IncTick() function and call the porting function xPortSysTickHandler() for the FreeRTOS tick increment,
but now in the porting of STM32L5 this is not possible since the Systick_Handler() is implemented directly inthe port.c file.

Why the change? Is there a way to continue using it as before without modifying the Porting?

For now what I have done has been in the port.c file, change the Systick_Handler() to xPortSysTickHandler() and inplement my Systick_Handler() in the same way as in STM32L4. But I don’t know if this could have other implications.

Any comments are welcome

Best Regards,

Sergio

Sergio, this is indeed a bit confusing.

In a stand-alone ( bare metal ) project, the HAL library uses the system tick to count the time.

void SysTick_Handler(void)
{
  HAL_IncTick();
}

Now when you use FreeRTOS, it wants to use the same interrupt for its clock tick.

What you can do is the following, change the HAL function:

void SysTick_Handler(void)
{
  HAL_IncTick();
  xPortSysTickHandler();
}

and make sure that your FreeRTOSConfig.h does not not define xPortSysTickHandler.

I would recommend not to change any of the FreeRTOS kernel code, like port.c That could cause troubles when you upgrade the kernel.

If you decide to give the interrupt directly to the kernel, your FreeRTOSConfig.h will have this define:

    #define xPortSysTickHandler SysTick_Handler

The HAL function HAL_GetTick() is declared weak, so you can override it:

HAL_GetTick(void)
{
  return xTaskGetTickCount();
}

and make sure that the HAL version of SysTick_Handler() is not compiled ( set between /* */ )

I wrote:

uint32_t HAL_GetTick(void)
{
  return xTaskGetTickCount();
}

Mind you, some of the HAL init functions have loops with a time-out, as measured by HAL_GetTick(). As long as the kernel is not running, those loops become endless.

This could be a solution:

uint32_t HAL_GetTick(void)
{
uint32_t ulReturn;
	if( xTaskGetSchedulerState() == taskSCHEDULER_RUNNING )
	{
		ulReturn = ( uint32_t ) xTaskGetTickCount();
	}
	else
	{
		static uint32_t ulCounter = 0U;
		static uint32_t ulTicks = 0U;

		ulCounter++;
		if( ulCounter >= 1000U )
		{
			/* Increment the tick counter every 1000 calls. */
			ulCounter = 0U;
			ulTicks++;
		}
		ulReturn = ulTicks;
	}
	return ulReturn;
}

Hi,

Thank you very much, in fact that was my problem that many HAL functions use the HAL_GetTick() before launching the scheduler, and with the redefiniton of the HAL_GetTick function I can use it, but not with the precision of the timeout.

Best Regards,

Sergio

If you want HAL_GetTick() to return a precise tick value, I would use the systick handler of HAL and define:

void SysTick_Handler(void)
{
  HAL_IncTick();
  if( xTaskGetSchedulerState() == taskSCHEDULER_RUNNING )
  {
    xPortSysTickHandler();
  }
}

in which case xPortSysTickHandler shall not be #defined.

Hi,

This is what I had to do, but in order to do it I had to modify the port.c, because in the STM32L5 porting, is defined Systick_Handler() in this file, not xPortSysTickHandler()

Best Regards,

Sergio

Hi Sergio,

Instead of changing port.c, you could put the HAL tick on another timer (other than systick). In fact this method is recommended by ST now. CubeMX generates a warning if you try to put the FreeRTOS tick and the HAL tick both on the systick timer.

I agree with @jefftenney that changing the HAL to use a different timer than SysTick is the right solution. The following image shows how to change HAL timer in STM32Cube IDE or CubeMX:

Thanks.

Hi,

Thank you very much for yours comments @jefftenney @aggarg

Best Regards

Sergio

Instead of changing port.c, you could put the HAL
tick on another timer (other than systick).

Yes, very much agreed, that is a perfect solution.