TMDS64EVM: MDIO can't read from PHY

Seth Appleman

Part Number: TMDS64EVM
Other Parts Discussed in Thread: SYSCONFIG,

I am writing custom firmware for the PRU, and have so far been unable to read from the PHY using the MDIO register interface. I can see my updates to the MDIO registers enabling the MDIO and setting other configuration settings, but everytime I try and read from a PHY register using the MDIO USER ACCESS registers, the GO bit it never being cleared after I set my commands, so I wait indefinitely for a reply. I tried running more or less similar custom driver code on the R5F with equally unsuccessful results.

Trying to isolate the issue, I am now using a empty demo project for the R5F core 0 I cloned out of the SDK examples, and using the sysconfig tool to generate the interface/driver code between the Arm core MDIO interface and the PHY device. I am getting the exact same problem - GO bit in the MDIO USER ACCESS register never clears so I never get any reply.

My sysconfig file creates a single PRU (ICSS) TI Driver instance on ICSSG1, and a single ETHPHY (ICSS-EMAC) TI board driver, also for ICSSG1. Stepping through the code I can see the PHY device drives called and the MDIO init routine called. I can see the MDIO CONTROL register set properly during the init call. I add a call to my main code:

ETHPHY_command(gEthPhyHandle[0], ETHPHY_CMD_SOFT_RESTART, &status, 1);

Tracing down the call tree, I get stuck at the same point in the PHY Read Reg routine, GO bit never clearing.

I noticed that with the settings as defined now, there are no pinmux configurations generated for interfacing with the PHY device (RMII pins or MDIO pins). Not sure if this may have something to do with the problem? Any other suggestions?

3 months ago

+1 PratheeshGangadhar 3 months ago

TI__Guru 51011 points

Root Cause: Missing Pinmux + Board-Level Mux Configuration

Your diagnosis is correct — the missing pinmux configuration is the primary cause. The MDIO GO bit only self-clears when the MDIO state machine completes a transaction [3]. If the MDIO clock (MDC) and data (MDIO) signals aren't physically routed to the PHY, the state machine sends commands into the void and never receives acknowledgment.

However, on the TMDS64EVM specifically, there are two layers to this problem:

1. SysConfig Pinmux for MDIO Pins

PRU_ICSSG pins require multiplexing at two levels: the processor-level PADCONFIGx registers and the PRU_ICSSG IP-level internal wrapper multiplexing [4]. SysConfig should generate both, but your current configuration is generating neither. You need to explicitly add MDIO pin assignments in SysConfig's PinMux utility — select the appropriate pins for PRG1_MDIO0_MDC and PRG1_MDIO0_MDIO [5][6].

2. TMDS64EVM Hardware Multiplexer

This is a critical detail specific to your EVM: the TMDS64EVM uses external GPIO-controlled multiplexers to route MDIO/MDC signals between the CPSW and ICSSG (PRG) controllers to the PHYs [7]. The mux selection is controlled via a GPIO on a 24-bit IO expander [8]. If this mux is not set to route ICSSG1's MDIO to the PHY, your MDIO signals will never reach the PHY regardless of pinmux settings.

Recommended Debug Steps

Step	Action	Why
1	In SysConfig, add PinMux entries for `PRG1_MDIO0_MDC` and `PRG1_MDIO0_MDIO`	Routes MDIO signals to physical pins [4][5]
2	Configure the IO expander GPIO to select ICSSG1 (PRG) mode for the MDIO/MDC mux	The EVM mux defaults may route MDIO to CPSW instead of ICSSG1 [7][8]
3	Verify PHY address is set to 3 in SysConfig's ETHPHY board config	Matches TMDS64EVM hardware straps [9]
4	Confirm `MDIO_CONTROL_REG` bit [30] ENABLE is set and CLKDIV [15:0] is configured	MDIO state machine won't operate without these [3]
5	Enable "custom board" in SysConfig if using non-default peripheral configurations	Required for proper initialization of peripherals outside default EVM config [12]
6	Probe MDC pin with oscilloscope	Confirms whether MDIO clock is physically toggling

The fact that both PRU and R5F exhibit identical behavior confirms this is a hardware configuration issue (pinmux + board mux), not a firmware problem — the PRU_ICSSG MDIO module is accessible to both PRU cores and external host processors via the VBUSP interface [13], so both paths fail identically when the physical signals aren't routed.

Citations

0 Seth Appleman 3 months ago in reply to PratheeshGangadhar

Prodigy 230 points

Thank you for the detailed response and citations.

Some additional questions:

From step 2, how do I configure the IO expander? It is referenced several times in the manual reference you provided, but it is not clear what I need to do in code (or otherwise) to set it properly.
From step 3, reading the citation provided, it is not clear what specifically I need to do/read in order to validare the PHY address of the device. Please elaborate or provide further documention on what procedure I must do.
From step 6, I am going to probe TP21 to check the waveform for the functioning MDIO clock, correct?

Thanks again.

Processors

Processors forum