Wrong tick period and can't modify config file

hi everyone
i’m just at the first tests with freeRTOS on a stm32f446re board, using CubeMX to configure the system and developing on AtollicTrueStudio.
i’ve noticed some weird facts:
first, is that the tick period result about 0.98ms.
doing osDelay(1000) and measuring with an oscilloscope the period of a digital pin toggling, the period is actually about 980ms.
with osDelay(100)->98ms.

i’ve configured the clock at 180MHz using the HSE, but here another problem, if from PLL source MUX i select HSE, 1 tick become 3.2ms instead of 1ms. so i suppose that the systemcoreclock in the config file is wrong (not 180MHz?).
Selecting HSI from PLL source MUX, tick period become 0.98ms.

last thing, is that chancing frequency and clock parameters in the FreeRTOSconfig.h file, don’t affect the behavior of the program (e.g. changing tick frequency to 500Hz vTaskDelay(1000) the delay is still 1 second)

Apologies if you receive a reply to this twice - I posted my first reply at exactly the same time that the forums went into read only mode.

Ref the delay accuracy. I suspect osDelay() calls vTaskDelay() - which means the delay period is relative to when the function is called. If you use vTaskDelayUntil()
then the delay period is relative to the last time the task called vTaskDelayUntil().

Ref the clocks. It sounds like ST are not using the constants in the FreeRTOSConfig.h file so you need to look at your setup to see how the tick interrupt is
being generated. If the constants in the FreeRTOSConfig.h file are being used then, at least in the code we provide, configCPU_CLOCK_HZ must be set to the frequency of the clock that is used to generate the tick interrupt.

i use the Timer1 as system clock, this should be the configuration.
as soon as i’ll try to use the systemdelayuntil method, even if with osDelay or vTaskDelay i expect to have a delay of: osDelay+Tcomputation, so a constant error not proportional as in my case. even if i don’t think that the computation time of a pin toggling could change something.

TIM_HandleTypeDef        htim1; 

HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority)
 RCC_ClkInitTypeDef    clkconfig;
 uint32_t              uwTimclock = 0;
 uint32_t              uwPrescalerValue = 0;
 uint32_t              pFLatency;

 /*Configure the TIM1 IRQ priority */
 HAL_NVIC_SetPriority(TIM1_UP_TIM10_IRQn, TickPriority ,0); 

 /* Enable the TIM1 global Interrupt */

 /* Enable TIM1 clock */

 /* Get clock configuration */
 HAL_RCC_GetClockConfig(&clkconfig, &pFLatency);

 /* Compute TIM1 clock */
 uwTimclock = 2*HAL_RCC_GetPCLK2Freq();

 /* Compute the prescaler value to have TIM1 counter clock equal to 1MHz */
 uwPrescalerValue = (uint32_t) ((uwTimclock / 1000000) - 1);

 /* Initialize TIM1 */
 htim1.Instance = TIM1;

 /* Initialize TIMx peripheral as follow:
 + Period = [(TIM1CLK/1000) - 1]. to have a (1/1000) s time base.
 + Prescaler = (uwTimclock/1000000 - 1) to have a 1MHz counter clock.
 + ClockDivision = 0
 + Counter direction = Up
 htim1.Init.Period = (1000000 / 1000) - 1;
 htim1.Init.Prescaler = uwPrescalerValue;
 htim1.Init.ClockDivision = 0;
 htim1.Init.CounterMode = TIM_COUNTERMODE_UP;
 if(HAL_TIM_Base_Init(&htim1) == HAL_OK)
   /* Start the TIM time Base generation in interrupt mode */
   return HAL_TIM_Base_Start_IT(&htim1);

 /* Return function status */
 return HAL_ERROR;

 void HAL_SuspendTick(void)
  /* Disable TIM1 update Interrupt */
  __HAL_TIM_DISABLE_IT(&htim1, TIM_IT_UPDATE);                                                  

void HAL_ResumeTick(void)
 /* Enable TIM1 Update interrupt */

/ ************************ (C) COPYRIGHT STMicroelectronics *****END OF FILE****/

I’ve solved.
In practice the problem was the too high clock frequency, at 180MHz seem that the system tick goes faster.
The maximum frequency without this problem is about 120MHz.

Someone can verify it on is own board?

One thing to look into is the results of the various calculations in the code. Sometimes you can run into issues at some clock rates that some of the numbers don’t fit into needed field widths (I don’t see an issue at first look).