STM32CubeIDE/MX restricts timer period/arr to 12-bit values when using dithering

[jacobq]

I am using STM32CubeIDE (v1.15.1) to develop firmware for an STM32G431 MCU and attempting to configure

TIM8 to use dithering. I have defined the following constants:

TIM8_KHZ = 20

TIM8_PRESCALER = (1-1) = 0

TIM8_PERIOD = (((16*170000/TIM8_KHZ)/2)/(TIM8_PRESCALER+1)) = 68000

TIM8_INT_PERIOD = (TIM8_PERIOD >> 4) = 4250

TIM8_FRAC_PERIOD = (TIM8_PERIOD & 0xF) = 0

The first sign of trouble is that the period/ARR parameter gets marked as invalid with a red X:

Evidently, the software believes that this register is supposed to be limited to 12 bits, but this is not correct, as shown by the reference manual RM0440:

If I proceed to generate code anyway, it produces

htim8.Init.Period = TIM8_INT_PERIOD; // somewhat misleading
...
__HAL_TIM_SET_AUTORELOAD(&htim8, 68000); // same as TIM8_PERIOD

Everything appears to work OK except that STM32CubeIDE shows that error/warning about the period being larger than 0x0FFF. Why does the configuration software limit this value to 12 bits? Shouldn't it still be 16?

STM32CubeIDE 1.15.1
STM32CubeMX 6.11.1
STM32CubeFW_G4 V1.5.2

[Semer CHERNI · Accepted solution]

Hello @jacobq 

First let me thank you for posting.

Indeed, this is a misbehavior from CubeMX tool. The ARR register size should be in line with the Ref manual content.
As a temporary solution, you can change the value manually after the code generation.
The issue is raised to the dev team for analysis (169221 : this is an internal ticket number).

BR,
Semer.

[BarryWhit]

I logged in to report the same issue and found this thread. I'm still using CubeIDE 1.14.1 (with STM32G4 pack), so this issue has been there for a while. There are several problems:

1. In the CubeMX GUI "Fractional" is incorrectly spelled as "Fractionnal".

2. The CubeMX GUI misrepresents the way dithering mode works. It provides fields that when dithering is ON, the ARR register's bits are split into 12 bits of "Integer" and 4 bits of "fractional" components. In fact, the ARR register is expanded with extra bits to become 20 bits, only the semantics of the 4 lower bits are different (hence the dithering).

3. The code generated is nonsensical:

```

htim3.Init.Period = INTEGER_VALUE;

<...>

if (HAL_TIM_Base_Init(&htim3) != HAL_OK)

<...>
HAL_TIMEx_DitheringEnable(&htim3);

/* rewrite ARR register when dither mode active */
__HAL_TIM_SET_AUTORELOAD(&htim3, FRACTIONAL_VALUE);

```

HAL_TIM_Base_Init is first called and sets the AUTORELOAD register to the integer value, then the

this register is overwritten with the (ostensibly wrong) Fractional value.

I understand your code generator might do things this way to simplify the templates, but combined with the misleading UI this becomes a complete hodgepodge (mess).

I can offer a better workaround than what Semer suggested. In the CubeMX UI:

1. Set the "Integer Counter Period" field to 0. it is effectively ignored by the generated code.

2. Turn on "Disable checking" for the "Fractional Period" field, and set it to the proper 20-bit value you've chosen for 

the dithered AUTORELOAD value. Additionally, I've made a habit of placing defined names into such fields (possible, when you disable checking). For example "MY_AUTORELOAD_VALUE1". and then simply defining those values at the top of my source file. This way, you don't have to regenerate the code in order to tweak some register value.

Semmer, Is there an update on internal ticket 169221?

[jacobq]

FWIW This problem appears to still be present in STM32CubeG4 v1.6.0 / MxCube v6.12.0.

I am using STM32CubeIDE v1.16.0 (Build: 21983_20240628_1741 on Windows 11)

@Semer CHERNI Is there a way that we can view the status of the internal ticket (169221)? Can you provide any updates?

[jacobq]

In case it is of interest, I also submitted a suggestion for fixing `IS_TIM_PERIOD` so that it takes dithering into account here: https://github.com/STMicroelectronics/stm32g4xx_hal_driver/issues/18