Skip to main content
Visitor II
August 26, 2022
Solved

STM32F429ZI ETH_MACMIIAR CR: max value?

  • August 26, 2022
  • 4 replies
  • 3408 views

STM32F429ZI Ethernet @180MHzRM0090 33.8.1 page 1197, ETH_MACMIIAR CR: max value is 100 150-168MHz HCLK/102

Is this a print error (other micros in the family can only reach 168MHz) or the controller is not specified to work at 180MHz ?

Thx

    This topic has been closed for replies.
    Best answer by Piranha

    The CR field is not some magic number - it just sets a divisor for MDC clock on MDIO interface. As per IEEE 802.3 the MDC frequency must not exceed 2,5 MHz. But there is a catch - HCLK can be derived from HSI, which can go up to +4,5% above the nominal frequency, or some other inaccurate clock source. Therefore it needs some margin. It seems that the formula they used to calculate the maximum HCLK frequencies, is:

    • Fmax = 2,5 MHz * div - 5 MHz

    Obviously applying a constant offset is a very dumb and flawed way to calculate a frequency margin. For example, at 150 MHz an offset of 5 MHz gives a margin of just a 3,3%, which is not enough for an universal approach. I recommend choosing such a divider that MDC frequency does not exceed, for example, 2,3 MHz, which gives 8,7% margin.

    Again, instead of explaining how things work, the documentation writer tried to think for the developer... and failed. Though, as the frequency numbers are the same also in TI and Espressif Systems manuals, the source of this "great" formula most likely is Synopsis. The reference manuals for H7 series has a more detailed description, but still suggests the same poorly chosen frequency limits.

    @Community member​.

    @KDJEM.1​, how about adding a decent explanation of the MDC frequency in reference manuals?

    4 replies

    Technical Moderator
    August 29, 2022

    Hi @scaprile​ ,

    Thank you for bringing this issue our attention.

    I confirm that in ETH_MACMIIAR CR and for max value is 100 the correct values are 150-180 MHz  HCLK/102.

    So, the clock range in ETH_MACMIIAR will be updated accordingly.

    I reported this issue internally.

    Internal ticket number: 133712 (This is an internal tracking number and is not accessible or usable by customers).

    Kaouthar

    PiranhaAnswer
    Graduate II
    August 30, 2022

    The CR field is not some magic number - it just sets a divisor for MDC clock on MDIO interface. As per IEEE 802.3 the MDC frequency must not exceed 2,5 MHz. But there is a catch - HCLK can be derived from HSI, which can go up to +4,5% above the nominal frequency, or some other inaccurate clock source. Therefore it needs some margin. It seems that the formula they used to calculate the maximum HCLK frequencies, is:

    • Fmax = 2,5 MHz * div - 5 MHz

    Obviously applying a constant offset is a very dumb and flawed way to calculate a frequency margin. For example, at 150 MHz an offset of 5 MHz gives a margin of just a 3,3%, which is not enough for an universal approach. I recommend choosing such a divider that MDC frequency does not exceed, for example, 2,3 MHz, which gives 8,7% margin.

    Again, instead of explaining how things work, the documentation writer tried to think for the developer... and failed. Though, as the frequency numbers are the same also in TI and Espressif Systems manuals, the source of this "great" formula most likely is Synopsis. The reference manuals for H7 series has a more detailed description, but still suggests the same poorly chosen frequency limits.

    @Community member​.

    @KDJEM.1​, how about adding a decent explanation of the MDC frequency in reference manuals?

    ST Employee
    September 7, 2022

    Hello @scaprile​ ,

    Thanks for reporting this issue. It is indeed a print error and the Ethernet can work at 180MHz.

    The table in section 33.4.1 was correct (180MHz) but the register description is not.

    It'll be fixed for RM0090 next release.

    For the latest products, we will just mention the clock dividing ratio between the AHB clock and the MDC clock, to make the spec product agnostic, as proposed.

    Best regards,

    Vincent

    Technical Moderator
    December 10, 2025

    Hello @scaprile ;

     

    The issue is fixed in RM0090 Rev 21.

     

    Thank you.

    Kaouthar