[Bug]: Macro Definition Error

[razortail-qzxvk]

Bug Summary

Change the good to the wrong.

Detailed Description

STM32CubeMX 6.17.0 & FW_G4 V1.6.1 -> FW_G4 V1.6.2

Expected Behavior

No response

Actual Behavior

No response

Environment

No response

Severity

None

[MKISTM]

Hello @razortail-qzxvk,

First all thank you for your report; after checking i believe the new change is correct and it is normal behavior.

You can find in G4 Reference Manual in the Deadtime resolution and max absolute values table (Table 237), the description of each value of the DTPRSC[2:0] bits corresponding to any operation (DIV or MUL).

BR,
Mohamed Chaker.

[razortail-qzxvk]

Hello Mohamed.

Thank you for reviewing the issue. However, I believe there is a fundamental misunderstanding here regarding the relationship between Time Period (t) and Frequency (f).

While you are absolutely correct about the Reference Manual (Table 222/237) stating that for DTPRSC[2:0] = 000, the period is: tDTG = tHRTIM / 8

If we convert this period relationship into a frequency relationship f = 1 / t, the math is as follows:
fDTG = fHRTIM * 8

This mathematically proves that the dead-time generator clock frequency is multiplied by 8, not divided.

Now, please take a look at the Doxygen comment placed directly above these macros in the HAL source code:
@brief Constants defining division ratio between the timer clock frequency (fHRTIM) and the dead-time generator clock (fDTG)

The comment explicitly explicitly states that the macros describe the frequency fHRTIM and fDTG, NOT the period tHRTIM and tDTG.

Therefore:
The old V1.6.1 macro ..._MUL8 was perfectly aligned with the Doxygen comment, because fDTG = 8 * fHRTIM.
The new V1.6.2 macro ..._DIV8 only makes sense if we are talking about the period t, which directly contradicts the existing @brief comment.

If the intention of this V1.6.2 update is to name the macros based on the period equation tDTG = tHRTIM / 8 to match the visual representation in the Reference Manual table, then the Doxygen @brief comment must be updated to reflect that it is describing the period tHRTIM and tDTG instead of the frequency. Otherwise, having a DIV8 macro under a "frequency" description is mathematically incorrect and highly misleading for developers.

Could you please re-evaluate this contradiction? Thank you!

[MKISTM]

Hello @razortail-qzxvk,

Thank you for your detailed report. You are right; according to the macro's description, the old version is correct if we calculate in frequency but if we calculate in time the new implementation is correct.

So, let's agree that both behaviors are correct, but we must either change the description if we keep the last change to avoid confusion or revert to the previous behavior.

I'll keep you informed once we make a decision.

BR,
Mohamed Chaker

[MKISTM]

ST Internal Reference: CDM0060714