Bug Report: STM32G474 Vienna Rectifier – TIM7 16-bit ARR overflow causes wrong interrupt frequency

[k_nedelchev]

Title: Bug Report: STM32G474 Vienna Rectifier firmware – TIM7 16-bit ARR register overflow (Wrong interrupt frequency)

Hi everyone,

I want to share my experience and a bug I recently discovered while working with the vienna_stm32G474 reference software (generated via ST eDesignSuite).

🔍 The Problem

The interrupt frequency for TIM7 was measured at 8734 Hz instead of the configured 2000 Hz.

⚙️ Cause of the Bug

The issue stems from the generic timer initialization function used across the project:

c

void DPC_MISC_ApplTimer_Init(TIM_HandleTypeDef AppTIM, uint32_t APPL_Freq_Desidered);

 

This function assumes it is always dealing with 32-bit timers (like TIM2). However, TIM7 is a 16-bit basic timer.

When calculating the Auto-Reload Register (ARR) value for the desired 2000 Hz frequency at a 170 MHz clock, the following math occurs:

c

Timers_ClockARR = (170000000 / 2000) - 1; // 85000 - 1 = 84999
AppTIM.Init.Period = Timers_ClockARR;     // Assigning 84999 to a 16-bit register

 

Because TIM7->ARR is only 16-bit, the value 84999 (0x14C07) overflows and gets truncated to 19463 (0x4C07).
As a result, the actual hardware frequency becomes:
Actual Frequency = 170000000 / (19463 + 1) = 8734 Hz.

Note: There is another minor oversight in this initialization function—it fetches the peripheral clock using HAL_RCC_GetPCLK2Freq() (APB2), even though TIM7 resides on the APB1 bus. Luckily, in this specific clock configuration, both buses run at the same frequency (170 MHz).

🛠️ The Fix (Workaround)

You can easily fix this with a minimal change in the .ioc file using STM32CubeMX:

1. Open the project configuration and navigate to: Pinout & Configuration > Timers > TIM7.
2. Under Configuration > Parameter Settings > Counter Settings, change the Prescaler value from 0 to 1.
3. Click to update the project.

By setting PSC = 1, the timer clock is halved, and the initialization function will compute an ARR value of 42499. Since this is well below the 16-bit limit (65535), it loads perfectly without overflow.

After applying this change, TIM7 successfully triggers at the intended 2000 Hz. Hope this helps anyone scratching their head over unexpected telemetry or timing issues in this application!