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?

[ELEC_moon]

The reason why I initially thought this was a HAL library issue is:

1. All other prescaler settings in the library are described and configured based on **frequency**.

2. The comments in the code are also written based on **frequency**.

3. I believe the current frequency‑based configuration in CubeMX is also understandable, and I can handle the conversion between frequency and period during use.

Therefore, I have the following additional questions:

1. Regarding HRTIM_Prescaler_Ratio and HRTIM_Chopper_Frequency, is it necessary to unify the setting convention across all prescalers to ensure **all prescaler settings in the HAL library are based on frequency**?

2. Will the current usage habits of CubeMX (frequency‑based) be taken into consideration and maintained?

[Ghofrane GSOURI · Accepted solution]

Hello @ELEC_moon 

FYI Ticket #0060562, referenced in the thread Solved: Re: STM32G4 HRTIM Deadtime Prescaler incorrect set... - STMicroelectronics Community  is essentially about improving the CubeMX GUI so that it describes DTPRSC primarily as a dead‑time time‑step (tDTG)(t​DTG​​) multiplier, consistent with the Reference Manual.

tDTG  = (tHRTIM / 8)--> (DTPRSC = 0, fDTG = 8 × fHRTIM)
tDTG  = 2 × (tHRTIM / 8)--> (DTPRSC = 1, fDTG = 4 × fHRTIM)
tDTG  = 4 × (tHRTIM / 8)--> (DTPRSC = 2, fDTG = 2 × fHRTIM)
tDTG  = tHRTIM -->(DTPRSC = 3, fDTG = fHRTIM)
tDTG  = 2 × tHRTIM -->(DTPRSC = 4, fDTG = fHRTIM / 2)
tDTG = 4 × tHRTIM -->(DTPRSC = 5, fDTG = fHRTIM / 4)
tDTG  = 8 × tHRTIM -->(DTPRSC = 6, fDTG = fHRTIM / 8)
tDTG  = 16 × tHRTIM -->(DTPRSC = 7, fDTG = fHRTIM / 16)

This way, the GUI clearly shows both the time‑step scaling and the corresponding frequency relationship, fully aligned with the RM and avoiding the DIV/MUL confusion.

@ELEC_moon @TDK Is there anything else on the STM32CubeMX side that I might have missed and that also needs to be corrected?

THX

Ghofrane

[ELEC_moon]

Hi,

Thank you for providing this detailed description of the proposed improvement in Ticket #0060562. I fully understand the logic behind aligning the CubeMX GUI with the reference manual by using time-step (tDTG) as the primary description, while still showing the corresponding frequency relationship.

I have a few follow-up questions regarding the current status:

1. I would like to confirm: **Has this specific improvement for the CubeMX GUI (as described in Ticket #0060562) already been implemented in the latest release?**

2. Regarding the HAL library code comments: Currently, the comments still describe the ratio in terms of frequency (e.g., fDTG = ...). **Are these comments considered incorrect and need to be updated to reflect the time-step scaling, or is this just a documentation discrepancy that I have misinterpreted?**

[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