HAL_Delay running too fast in STM32N6 Application with TIM2 timebase

[bwelte1]

Hi all,

I've created a new default project for the STM32N6 Discovery Kit, and set up a simple blinking application using the BSP LED functions.

 /* USER CODE BEGIN 2 */
 BSP_LED_Init(LED_GREEN);
 while(1)
 {
	 HAL_Delay(1000);
	 BSP_LED_Toggle(LED_GREEN);
 }
 /* USER CODE END 2 */

I've noticed that in the Application, HAL_Delay() runs roughly 2× too fast. For example, HAL_Delay(1000) only delays for ~500 ms. I can see this because the LED is blinking too quickly.

In this Application, TIM2 is used as the timebase source (I presume because of ThreadX using SysTick).

I looked at the TIM2 setup in HAL_InitTick() (inside stm32n6xx_hal_timebase_tim.c). The relevant snippet is:

 /* Compute TIM2 clock */
 uwTimclock = HAL_RCC_GetPCLK1Freq();

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

 /* Initialize TIM2 */
 htim2.Instance = TIM2;

 /* Initialize TIMx peripheral as follow:
 * Period = [(TIM2CLK/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
 */
 htim2.Init.Period = (1000000U / 1000U) - 1U;
 htim2.Init.Prescaler = uwPrescalerValue;
 htim2.Init.ClockDivision = 0;
 htim2.Init.CounterMode = TIM_COUNTERMODE_UP;

From the debugger:

• uwTimclock = 200 MHz (APB1 peripheral clock)

• TIM2 registers for Period and Prescaler are set as expected

• HAL_IncTick() is only called once per TIM2 interrupt

So all of the math kind of seems correct (I think?), but despite this, uwTick increments much too quickly, causing HAL_Delay() to run faster than expected.

Observations:

• In my own project, the tick was 4× too fast

• In this default project, it is 2× too fast

• In the FSBL, HAL_Delay() is accurate

Has anyone encountered this behavior? Could this be related to the TIM2 clock configuration or some STM32N6-specific behavior with APB1 timers?

Thanks in advance!

[Gyessine]

hello @bwelte1 
I tried replicating your case using this example , and I did not find any problem in the HAL_delay() function behavior.
Can you base your project on it and see if it solves your problem?
BR
Gyessine

[bwelte1]

Hey, thanks for the response!

The HAL_Delay() function behavior was normal when testing that example outright. I'll make a comparison between that and my project and get back to you soon.

[Gyessine]

hello @bwelte1 
just asking about any feedback, Does the problem still persist, or has it been resolved?
Gyessine

[waclawek.jan]

Well, I guess the culprit here is the timer's kernel clock not being equal to its APB clock... a variant of this classic problem, but on steroids, as the 'N6 clocks' complexity went through the roof.

The definitive way to find out the truth is, as always, in reading out and checking content of relevant registers, here, in RCC.

JW

[bwelte1]

Hey @waclawek.jan, thanks for the reply.

I've read through what you've said, but I'm still unsure of how to configure my clocks within STM32CubeMX.

I have tried several different configurations, but cannot seem to get any to work without any modification in code. 

I have been getting around this by doubling uwTimclock in code within HAL_InitTick();.

uwTimclock = HAL_RCC_GetPCLK1Freq() * 2;

I haven't encountered too many issues caused by this in code, other than some inaccuracies in timing (FPS calculations, etc.).

Is anyone out there not experiencing this, and can share your clock configuration around these peripherals? :)

Thanks!

[waclawek.jan]

I don't use the 'N6 and I don't use CubeMX, but reading out the relevant registers' content is the ultimate way to determine, what's going on.

uwTimclock = HAL_RCC_GetPCLK1Freq();

I don't use Cube/HAL, but I am quite sure there will be some dedicated function to return the Timers' kernel clock (which as I've explained above may be different from the APB/PCLK1 clock). They should be timer-related examples in Cube, so try to find there; or, ultimately, as Cube is open source, you can simply have a look at the soruces to try to find the appropriate function yourself.

Or maybe somebody who uses Cube/HAL chimes in with a ready-made solution. 

JW