EthTrcv — Reading MDIO and PHY Registers Directly

MDIO (Management Data Input/Output) is the serial control bus between the MAC/SoC and the PHY chip, over which EthTrcv_Init and every register access run — not over MII/RGMII. IEEE 802.3 defines two frame formats: Clause 22 (classic, 32 registers per PHY) and Clause 45 (extended, with a DEVAD address space, mandatory for 1000BASE-T1 and safety PHYs).

A quick refresher on the frame format, since the field names keep coming up below:

PHYAD/PRTAD addresses the chip on the bus, REGAD/DEVAD+address addresses the register inside the chip. Those register addresses are exactly what this post is about.

Every IEEE-compliant PHY implements a set of standard registers that sit at the same address and carry the same meaning across vendors. On top of that, every vendor defines vendor-specific registers for diagnostic features that go beyond the IEEE standard (cable diagnostics, extended error counters, LED configuration).

Normally, application code does not access MDIO directly — and the function EthTrcv calls for it doesn’t belong to EthTrcv either, it belongs to EthIf: EthIf_ReadMii/ EthIf_WriteMii (declared in EthIf.h). EthIf is only a broker here, not the executor: per the spec (SWS_EthIf_00706/SWS_EthIf_00707), EthIf forwards the call internally to <EthDrv>_ReadMii/<EthDrv>_WriteMii of the responsible Ethernet Controller Driver — in practice Eth_ReadMii/Eth_WriteMii of the Eth module, which is what actually toggles MDC/MDIO on the wire.

CtrlIdx selects the Ethernet controller (MAC) that owns the MDIO bus in question, TrcvIdx the transceiver on that bus, and RegIdx the register address per the PHY register map. Both functions are explicitly synchronous per the spec (Sync/Async: Synchronous) — they block until the MDIO transaction has completed and return the result directly as Std_ReturnType; EthIf_ReadMii additionally returns the register value read via RegValPtr.

For EthTrcv, that means a single blocking call per register access is enough. That’s simpler than the earlier request/indication pattern, but it has a flip side — EthTrcv_MainFunction must not block on an MDIO transaction long enough to starve the driver’s other duties. How long a call actually blocks depends on the timing of the underlying Eth driver and the MDC frequency.

Whether EthTrcv talks to Eth via MII at all is a configuration choice, not a given. AUTOSAR models this as a choice container in the ECU configuration:

There is no EthTrcvReadMiiApi parameter — which access path is active is decided by which of the two containers is present in the ARXML, not by a boolean flag.

Not every debugging situation has access to the full AUTOSAR stack — during hardware bring-up there is often no RTE running yet, or you’re debugging on an evaluation board without AUTOSAR at all. In that case, two paths remain:

Path 1 — bare-metal driver: a minimal MDIO driver that talks directly to the SoC’s MAC registers for MDIO transactions (most SoC MACs have their own MDIO controller register set, independent of the actual Ethernet data path).

Path 2 — external MDIO adapter (see the "Tooling" section below): if even the SoC cannot be trusted (e.g. because you want to distinguish a MAC fault from a PHY fault), an external USB MDIO adapter can bypass the target SoC entirely and access the MDIO bus directly.

For day-to-day troubleshooting, a small, recurring set of registers is enough. The table below shows the standard bits in the Basic Status Register (address 1) that are relevant to link diagnostics:

There are no dedicated bits for speed and duplex in the Basic Status Register — those live either in the Auto-Negotiation Link Partner Ability register (5) combined with the Advertisement register (4), or directly in a vendor status register that many PHYs provide as a convenient shortcut (e.g. "auto-negotiated speed/duplex" in a single register instead of deriving it from two capability registers).

The TJA1100 is one of the most widely used 100BASE-T1 PHYs in automotive designs and makes a good concrete example, since its register set is well documented and representative of the class of 100BASE-T1 automotive PHYs.

For MDIO diagnostics outside the target SoC, a few established tool classes exist:

Starting point: an ECU with a TJA1100 PHY consistently reports ETHTRCV_LINK_STATE_DOWN via EthTrcv_GetLinkState. The cable is visibly plugged in correctly, and the far side (switch port) shows no link either. Step-by-step diagnosis via MDIO registers:

Step 1 — Does the PHY respond at all?

Both values match the known TJA1100 OUI. The PHY responds — so the MDIO bus, pull-up, and PHY address are fine. Had this returned 0xFFFF, the fault would be at the bus level (see the hardware deep dive), not in the link itself.

Step 2 — Check the Basic Control Register: is the PHY in power-down or reset?

Found it: bit 11 is set, the PHY is in power-down mode. That fully explains the missing link — a PHY in power-down drives no signal onto the line.

Step 3 — Narrow down the cause of the power-down

A look at the TJA1100 datasheet reveals: bit 11 in the Basic Control Register gets set automatically at power-on depending on the state of the CONFIG pin. In this case, a pull resistor on the evaluation board’s CONFIG pin was populated incorrectly — a board assembly variant intended for a different power-on behavior.

Step 4 — Confirm with a software workaround: clear power-down

After clearing power-down and restarting autonegotiation, the link actually comes up. Root cause confirmed: a hardware assembly fault on the CONFIG pin, not a software or cable fault.

Step 5 — Verify the negotiated mode

The TJA1100’s internal state machine confirms ACTIVE — diagnosis complete. The actual fix happens at the hardware level (assembly correction in the next board revision); until then, the MDIO write from step 4 serves as a bench workaround, not a production fix.

Next in the EthTrcv series: EthTrcv & IEEE 802.1AS — gPTP and Hardware Timestamping in the PHY