EthTrcv — What Can Go Wrong During Bring-Up?

Use the diagnostic APIs — start cable diagnostics (TDR-based, vendor-specific register) and read the result. A healthy cable reports no reflections; a defective one shows a short/open and often even an approximate fault distance in meters. Complementarily, loopback/test modes can isolate the PHY itself from the cable, which separates PHY faults from cable faults.

Check the AUTOSAR tooling configuration against the real hardware — ARXML parameters like EthTrcvSpeed and EthTrcvDuplexMode must match the actually populated PHY and its capabilities. A common mistake: a parameter was copied from an older board revision that used a different PHY chip with different default capabilities.

Read and compare EthTrcv_GetDuplexMode/EthTrcv_GetBaudRate — on both sides of the link, when both sides are under your control. A discrepancy between what was configured and what the driver actually reports immediately shows whether the problem sits in configuration or in PHY state.

Read the pin straps — verify the hardware default configuration directly at the PHY (see the strap-pin deep dive below), independent of whatever software later overwrites via MDIO. If strap and software configuration disagree, depending on the PHY either the last MDIO write wins or the strap value persists until the next reset — this is PHY-specific and documented in the datasheet.

Check whether the transceiver was actually set to ETH_MODE_ACTIVE via EthTrcv_SetTransceiverMode — a transceiver stuck in ETH_MODE_DOWN shows exactly the same outward symptom as a defective PHY: no link, no activity on the line. The difference lies purely in software control, not in hardware.

Check whether the Eth driver’s ControllerInit completed successfully — a failed MAC-side init prevents the link just as reliably as a PHY problem, but typically shows up in a completely different place in the log (the Eth module rather than the EthTrcv module) and is therefore easy to overlook in a first pass.

Verify the MII interface type on both sides — cross-check the interface type actually used, both in the SoC MAC driver configuration and in the PHY datasheet or read-back strap pins. These two configurations are often maintained by different teams (SoC BSP vs. PHY bring-up) and drift apart easily.

Check clock signals at the interface with an oscilloscope — for RGMII, measure the frequency of TXC/RXC and compare it against the expected speed (125 MHz at 1 Gbit/s, 25 MHz at 100 Mbit/s, 2.5 MHz at 10 Mbit/s). A wrong clock frequency is the clearest possible proof of a speed mismatch between MAC and PHY.

Check mode/standby pins for their actual level — with a multimeter or oscilloscope directly at the pin, not just in the schematic documentation. A pin that the schematic says should be "active" but that hangs at the wrong potential due to an assembly error is a classic board bring-up bug.

Capture raw frame traffic directly at the MII interface — with a logic analyzer that supports an MII/RGMII decoder. This shows immediately whether any bits are moving across the interface at all, and if so, whether they decode as valid frames — independent of what the EthTrcv driver reports in software.

Check the driver/hardware configuration against the actual PCB population — which interface (MII/RMII/RGMII) the driver expects is implicit in the concrete hardware and driver integration (there’s no dedicated ARXML enum for it); this expectation must match the hardware exactly, not just the original design intent.

Poll EthTrcv_GetLinkState repeatedly and log drop timestamps — a simple logging script that records link state together with a timestamp is the foundation for any further correlation. Without timestamps, an EMC-induced drop cannot be distinguished from an intermittent mechanical contact.

Correlate drop timestamps with other events — engine start, relay switching, actuator activity on the same harness. If the link drops exactly when a particular load switches on, EMC coupling is the obvious suspect.

Read RMS amplitude or SQI (Signal Quality Index) values — where the PHY offers these vendor-specific diagnostic registers, they give a quantitative measure of signal margin instead of just a binary "link up/down". An SQI value sitting close to the threshold confirms a marginal-link situation even when the link happens to be up at the moment of measurement.

Repeat cable diagnostics (TDR) under operating conditions — not just once at rest, but while the link is actively loaded, and ideally under the same mechanical/thermal conditions under which the drops occur.

Repeat temperature tests deliberately — run defined temperature ramps in a climate chamber while continuously logging link state, to narrow down a temperature threshold at which the drops begin.

Mechanically inspect the connector — gently move the connector (within specified tolerance) while observing link state, plus a visual inspection for corrosion or insufficient contact force.

Check register reads against standard registers such as the PHY ID — a consistent 0xFFFF or 0x0000 across several different registers (not just one) reliably indicates a bus-level problem rather than a configuration problem inside the PHY. If the PHY instead responds with a plausible but wrong value, the issue is more likely addressing-related than electrical.

Measure voltage levels and power sequencing — capture all relevant supply domains (see the Hardware Deep Dive) with an oscilloscope during power-on and compare the measured order and timing gaps against the datasheet.

Check reset timing with an oscilloscope — measure the duration of the low level on RST_N as well as the time between reset deassertion and the first MDIO access, and compare against the minimum boot time required by the datasheet.

Verify the MDIO address via pin-strap readback — where the PHY supports it, read back the actually strapped address independently of software (e.g. via a status register that keeps the strap value visible after boot), instead of relying on the schematic documentation alone.

Recognize inconsistent or corrupted register reads as the symptom — an address conflict rarely shows up as a clean, unambiguous error; instead it appears as unreliable behavior: sometimes PHY 1 responds, sometimes PHY 2, sometimes both responses overlap into a value that matches neither. This pattern — values that change from read to read with no apparent reason — is the strongest indicator of an address conflict, in contrast to the consistent 0xFFFF of a pure bus problem.

Check each PHY’s address strap pins individually — for every PHY on the board, separately verify the strapped address against the schematic and, if possible, by direct pin measurement, rather than relying solely on the ARXML configuration.

Isolate the PHYs individually and verify the address — if the board allows it, electrically disconnect one of the two PHYs from the MDIO bus (e.g. by desoldering or via a populatable isolation point) and read out the remaining PHY’s address in isolation. This conclusively establishes which PHY actually responds on which address.

Debug EthTrcv_CheckWakeup within the EcuM validation cycle — with a breakpoint or tracing directly inside the function, verify whether it is called at all, whether it recognizes a valid WakeUp reason, and whether EcuM_SetWakeupEvent is actually invoked with the expected ID before EcuMValidationTimeout elapses.

Check the WakeUp pulse in hardware with an oscilloscope — capture directly at the WU pin or the MDI wire pair whether a pulse, or TC10 pulse sequence, arrives at all, and whether its shape/timing matches the specification. This reliably separates "the hardware signal never arrives" from "software fails to recognize an arriving signal".

Check the EcuM mapping — trace, line by line, the link between EthTrcvWakeupSourceRef in ARXML and the EcuMWakeupSource actually configured in EcuM — particularly after configuration changes copy-pasted between multiple ECU variants.

Watch error counters and correlate them with load states — regularly read CRC, alignment, and symbol error counters (usually read-clear-on-read, so log them at a fixed sampling period) and relate them to environmental conditions such as engine load, temperature, or data throughput. An error rate that scales with throughput rather than staying constant points more toward a MAC-interface timing problem; an error rate correlating with external load switching points more toward EMC.

Read signal quality via PHY diagnostic registers — SQI and comparable vendor-specific metrics give a quantitative picture of the line side, independent of the raw error counters, and help narrow down whether the problem sits on the line side (MDI) or the digital MAC interface.

Use loopback tests to narrow it down — by deliberately short-circuiting the data path at different points (internal within the PHY, external at the MDI), you can determine whether errors already occur without a real cable attached (→ pointing to a MAC-interface or internal PHY problem) or only appear with the cable connected (→ pointing to the line side). Details on the available loopback modes and how to activate them via AUTOSAR are in the dedicated loopback post.