CubeMX 6.15.0 generates wrong HRTIM deadtime prescaler macros for STM32G474

[ELEC_moon]

Software Versions:

- STM32CubeMX: 6.15.0

- MCU: STM32G474QET6

- Firmware Package: STM32G4xx HAL Library V1.6.1

Bug Description: CubeMX 6.15.0 generates incorrect HRTIM deadtime prescaler macro definitions. These macros do NOT match the register bit definitions described in the STM32G4 reference manual (RM0440). This is a code generation bug in CubeMX, not a HAL library issue.

 

Old Correct Macros (Previous Version):

#define HRTIM_TIMDEADTIME_PRESCALERRATIO_MUL8 (0x00000000U)

#define HRTIM_TIMDEADTIME_PRESCALERRATIO_MUL4 (HRTIM_DTR_DTPRSC_0)

#define HRTIM_TIMDEADTIME_PRESCALERRATIO_MUL2 (HRTIM_DTR_DTPRSC_1)

#define HRTIM_TIMDEADTIME_PRESCALERRATIO_DIV1 (HRTIM_DTR_DTPRSC_1 | HRTIM_DTR_DTPRSC_0) #define HRTIM_TIMDEADTIME_PRESCALERRATIO_DIV2 (HRTIM_DTR_DTPRSC_2)

#define HRTIM_TIMDEADTIME_PRESCALERRATIO_DIV4 (HRTIM_DTR_DTPRSC_2 | HRTIM_DTR_DTPRSC_0) #define HRTIM_TIMDEADTIME_PRESCALERRATIO_DIV8 (HRTIM_DTR_DTPRSC_2 | HRTIM_DTR_DTPRSC_1) #define HRTIM_TIMDEADTIME_PRESCALERRATIO_DIV16 (HRTIM_DTR_DTPRSC_2 | HRTIM_DTR_DTPRSC_1 | HRTIM_DTR_DTPRSC_0)

 

New Wrong Macros Generated by CubeMX 6.15.0:

#define HRTIM_TIMDEADTIME_PRESCALERRATIO_DIV8 (0x00000000U)

#define HRTIM_TIMDEADTIME_PRESCALERRATIO_DIV4 (HRTIM_DTR_DTPRSC_0)

#define HRTIM_TIMDEADTIME_PRESCALERRATIO_DIV2 (HRTIM_DTR_DTPRSC_1)

#define HRTIM_TIMDEADTIME_PRESCALERRATIO_DIV1 (HRTIM_DTR_DTPRSC_1 | HRTIM_DTR_DTPRSC_0) #define HRTIM_TIMDEADTIME_PRESCALERRATIO_MUL2 (HRTIM_DTR_DTPRSC_2)

#define HRTIM_TIMDEADTIME_PRESCALERRATIO_MUL4 (HRTIM_DTR_DTPRSC_2 | HRTIM_DTR_DTPRSC_0)

#define HRTIM_TIMDEADTIME_PRESCALERRATIO_MUL8 (HRTIM_DTR_DTPRSC_2 | HRTIM_DTR_DTPRSC_1)

#define HRTIM_TIMDEADTIME_PRESCALERRATIO_MUL16 (HRTIM_DTR_DTPRSC_2 | HRTIM_DTR_DTPRSC_1 | HRTIM_DTR_DTPRSC_0)

 

Problem Summary:

1. Old macros are correct and match the reference manual.

2. New macros generated by CubeMX 6.15.0 are completely reversed and wrong.

3. This bug causes incorrect deadtime clock configuration and abnormal PWM output.

4. All STM32G4 series devices using HRTIM are affected.

 

Please fix the HRTIM deadtime prescaler generation logic as soon as possible. 

[TDK]

The new values match the reference manual. The old ones do not. This was the correct fix.

Or am I missing something?

 

[ELEC_moon]

Thank you for your reply. I fully understand the confusion here: the issue is the mismatch between **period (t) in the manual** and **frequency (f) in the code macros**.

### 1. Core Physical Relationship

Frequency and period are reciprocal: `f = 1 / t`

- Manual Table 237 defines **period ratio**: `t_DTG = t_HRTIM / 8` when DTPRSC=000

- This **must correspond to frequency ratio**: `f_DTG = 8 * f_HRTIM` (MUL8), NOT `f_DTG = f_HRTIM / 8` (DIV8)

### 2. New Macro Definition Error

The new macros generated by CubeMX 6.15.0 have **wrong macro names for the register values**:

- Register 000 (manual: `t_DTG = t_HRTIM / 8`) is incorrectly named `DIV8` (should be `MUL8`)

- Register 111 (manual: `t_DTG = 16 * t_HRTIM`) is incorrectly named `MUL16` (should be `DIV16`)

- All DIV/MUL macro names are reversed, which causes users to get the opposite frequency configuration of what they selected.

### 3. Conclusion

The old macros were correct: they matched the manual's period definition **after converting to frequency**.

The new macros are wrong: their names do not match the actual frequency ratio, leading to incorrect deadtime configuration and PWM output.

 

This is a critical bug in CubeMX 6.15.0's HRTIM deadtime prescaler macro generation. Please fix the macro names to align with the actual frequency ratio.

[TDK]

The macro, and the registers, say it's a deadtime prescaler, not a clock prescaler. So it should be based on time not frequency.

This was just changed in the most recent update.

 

If anything, this is a CubeMX bug, not a HAL bug. Have you tried the latest CubeMX version to see if it works correctly there?

[Ghofrane GSOURI]

Hello @ELEC_moon 

Actually, the HAL update has already been discussed in this thread: Solved: STM32G4 HRTIM deadtime prescaler defines swapped - STMicroelectronics Community

@TDK could you please clarify what the exact CubeMX bug is in this context, and how it manifests?

THX

Ghofrane

 

 

 

[ELEC_moon]

I fully understand @TDK 's point.

I agree that the root issue now lies with CubeMX: the configuration should be based on **time** rather than frequency, which will bring the description in RM0440, the code generated by the HAL library, and the options provided by CubeMX into complete alignment.

I also noticed the previous ticket #0060562 in this thread:STM32G4 HRTIM Deadtime Prescaler incorrect setting after driver update , which raised the requirement for CubeMX modification. Once the CubeMX update is completed, there will be no major issues left.

 

However, I observed that the comments in the code generated by the HAL library still describe the prescaler in terms of **frequency**. Is this correct and consistent with the new time-based design?

[chriesch]

Hi everyone,

Just came across this problem when updating STM32CubeMX. This change that you made is annoying because it breaks existing code during the update, but I understand the reasoning behind it. But please fix the comments in the HAL, they are wrong, as pointed out by @ELEC_moon above, and also the Prescaler configuration option in STM32CubeMX 6.17.0 still refers to frequency and not time.

Thanks, Christian