• State Resolved
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 53 views
  • Users 0 members are here
Support feedback
Options
Options
Related

Original question:

TMS320F28388D: MDIO clock: CSR clock source?

TMS320F28386D: MDIO clock: CSR clock source?

Ernst van der Pols
Prodigy 51 points

Part Number: TMS320F28386D

I have exactly the same question as Markus A: TMS320F28388D: MDIO clock: CSR clock source?, although I am using the F28386.

Unfortunately, that question has not been answered. Strangely enough MS CoPilot suggests that the CM clock is the source of the CSR clock, referring to the question of Markus A.

I did some measurements to verify this suggestion, selecting different settings for the CR field in the MAC_MDIO_Address Register, with the same clock configuration as Markus:

  • CPU 1 clock = 200 MHz
  • AUX clock = 125 MHz
  • CM uses AUX clock
  • Ethernet clock = System clock with divider 2 = 100 MHz
MDIO Clock Measurements
CR divider MDIO clock frequency
0001 62 2.0 MHz
0011 26 4.8 MHz
1000 4 31.25 MHz

As you can see, a value of 125 MHz for the CSR clock fits the measured MDIO clock values best.

So, until TI declares otherwise, I assume CoPilot's suggestion is correct and the "CSR clock" is equal to the CMCLK, or to be more precise the CM.PERx.SYSCLK for the Ethernet peripheral.

  • +1
    TI__Mastermind 36023 points

    Hello Ernst,

    Your conclusion is correct. The "CSR clock" referenced in the MAC_MDIO_Address Register is the CM peripheral subsystem clock (CM.PERx.SYSCLK), which is identical to CMCLK 1.

    Confirmation from Documentation

    The TRM states that CM.PERx.SYSCLK is the same as CMCLK, with each peripheral having its own independent clock gating controlled by the CMPCLKCRx registers 1. The MDIO module, as part of the Ethernet subsystem on the CM, uses this clock for its CSR operations.

    Validation Against Your Measurements

    With CMCLK = 125 MHz (derived from AUXPLL), your measurements align precisely:

    CR Field Divider Expected (125 MHz / divider) Measured
    0001 62 2.016 MHz 2.0 MHz
    0011 26 4.808 MHz 4.8 MHz
    1000 4 31.25 MHz 31.25 MHz

    This is a near-perfect match, confirming CSR clock = CMCLK = 125 MHz in your configuration.

    CR Field Programming Guidance

    When selecting the CR value, the TRM specifies that for standard operation (Bit 11 = 0), you should select the range that encompasses your CSR clock frequency to keep MDC between 1.0–2.5 MHz per IEEE 802.3. With a 125 MHz CSR clock, CR = 0001 (valid for CSR clock 100–150 MHz, divider = 62) is the correct choice for compliant operation 1.

    The TRM does not explicitly define "CSR clock" in the context of the MDIO register, which is a documentation gap. However, the architectural description of the CM clocking system and your empirical measurements both confirm that it is the CM peripheral clock. Note that ETHERNETCLK (configured separately via SysCtl_setEnetClk) is a different clock used for the Ethernet MAC/PTP timing and is not the CSR clock source for MDIO.

    Have you verified whether changing the CMCLK source or divider (e.g., switching from AUXPLL to SYSPLL or adjusting the CMCLK divider) shifts the measured MDC frequency proportionally, which would provide additional confirmation of this clock relationship?

    1. TMS320F2838x Technical Reference Manual (SPRUII0F)

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    Prodigy 51 points

    Dear Zackary,

    Thank you for your elaborate answer! This will also help CoPilot and its friends :-).

    No, unfortunately I did not alter the CMCLK frequency as additional check with these measurements. I was already convinced with a match on the 125 MHz value of the CMCLK, having only 200 MHz as other main clock in the system.

    At that moment we were just at the beginning of an in-depth search of "why the ethernet interface did not work" on our prototype board. Turned out to be an overlooked component error, but we took the long road of using all loopback and other diagnostics of the MAC and the PHY, trying an internal and external RMII clock, etc.. before finding the culprit by just looking at the component type number from a distance. Anyway, we tracked some issues in apparently not often used parts of the driverlib in this process (solved elsewhere in this forum), so our work was not in vain.

    Kind regards,

    Ernst