In short
100BASE-T1 has no auto-negotiation, so a link comes up only when exactly one side is configured as master and the other as slave, at a matching speed, over a correctly wired single twisted pair. Work the fault in that order: prove the physical layer, prove the PHY answers on MDIO, prove the two roles, then chase stability.
Every answer to this question is written per part number: a thread about one PHY on one vendor’s forum, a thread about another somewhere else, a developer forum thread where the engineer works it out themselves at the seventeenth post. Change one component and none of it transfers.
This is the checklist that does transfer, ordered the way a bench engineer works. Every figure and every behavioural claim about the standard or the tooling traces to an IEEE 802.3 task force record, the Linux ethtool manual or kernel documentation, published test material or a public thread, named in the References. Where a step rests on bench practice rather than a document, it says so.
- Both ends powered, out of reset, not asleep.
- Continuity, no shorts, every connector seated.
- Length and connector count inside the specified link segment.
- The PHY answers on MDIO with the right identifier.
- MDIO address and bus match the schematic.
- Role set by strap or register, and what survives a reset.
- Exactly one master and one slave, confirmed at both ends.
- Role read back, both ends on the same speed and mode.
- Channel and environment: EMC setup, routing, strain, temperature.
- Quality metrics trended, then formal test material.
Start with the rule that breaks CAN and 100BASE-TX habits
100BASE-T1 has no auto-negotiation, so master and slave are configured, not negotiated
On 100BASE-T1 the master and slave relationship is set by configuration on each device. Nothing on the wire resolves it.
The record is explicit. During IEEE P802.3bw D1.2 working group ballot a commenter asked for negotiable MASTER and SLAVE functionality, noting that two PHYs both provisioned as MASTER, or both as SLAVE, will not operate correctly. The task force rejected it: this type of network does not have plug and play functionality, it is a pre-configured embedded network. The draft clause text carried into ballot states the relationship is set by FORCE mode, and a request to reword it to “set by management” was rejected.
Which variant you are on matters, because auto-negotiation is optional rather than absent further up the family: the T1 family explained sets out where Clause 98 applies. If you came from CAN, there was no role to get wrong; our Automotive Ethernet versus CAN comparison covers the rest.
One pair, full duplex, echo cancellation: what that means for fault finding
Both transmitters drive the same two conductors at once, and each receiver subtracts its own transmission to recover the far end’s. There is no idle direction to watch go quiet, and a near-end receiver problem looks like a far-end transmitter problem, so symmetry tests beat any single measurement.
Polarity is the exception. The 802.3bw ballot text describes link-up starting with the MASTER PHY sending symbols to the SLAVE, during which the SLAVE detects a polarity flip and corrects it by changing the sign of both its received and its transmitted signals, so the MASTER always observes correct polarity. A swapped pair is therefore not, by itself, a reason for no link. Continuity, shorts and breaks are.
The three states you can be in
No link. No carrier, no link LED, the interface never reports carrier up. Steps 1 to 8.
Link up, no useful traffic. A switching, VLAN, port mapping or dissector question; the SOME/IP decoding fix list works through it.
Link that drops. Steps 9 and 10, and a different instrument set.
What to write down before you change anything
Bench tickets get long because nobody recorded the starting state. Before the first change: the configured role at each end and where it comes from, the speed and mode at each end, cable length and inline connector count, every device sitting inline, the driver, PHY address and MDIO bus the host reports, and whether either end has been reset since. That list is also, almost exactly, the evidence a silicon vendor will ask for.
Steps 1 to 3, prove the physical layer
Both ends powered, out of reset, and not in a low-power state
Powered is not running. A T1 PHY can be held in reset by a GPIO a driver has not released, sit in standby after power-on, or be commanded to sleep by the network itself: the OPEN Alliance publishes a 100BASE-T1 Sleep/Wake-up Specification, so a link can be put to sleep and woken by design. A link down because the far end took the sleep path is not a fault, and probing shows nothing but a quiet pair.
Confirm at both ends: rails present, reset released, normal operating mode, no sleep request outstanding.
Pair continuity, polarity, shield and connector seating
Continuity on both conductors, no short between them, no short to shield or ground, connectors seated at every joint. Harness drawings name connector families that are supplier trademarks rather than IEEE terms; the practical point is not which family you have but how many mated pairs sit between the two PHYs and whether each is latched.
The host can do part of this. The ethtool manual documents --cable-test, which reports results depending on the interface’s capability, typically open pairs, shorted pairs and pairs that are OK, with an approximate distance to a fault. --cable-test-tdr returns raw time domain reflectometer data, by default between 0 and 150 m at 1 m steps, though the interface rounds to whatever granularity the hardware implements, often 0.8 m.
Cable length and construction against the link segment the standard assumes
IEEE 802.3bw defines its link segment as up to 15 m of a single balanced twisted-pair cable, up to four inline connectors and two end connectors. That is the channel the transmitter and receiver specifications were written against, not a promise about your harness.
So the question is not only whether the run is under 15 m, but how many inline joints are in the path. A 3 m run through six breakout connectors is outside the specified channel even though the length looks comfortable. The OPEN Alliance publishes a 100BASE-T1 Channel and Component Requirements document for the rest.
Anything inline is a device with its own role
A media converter, breakout box or bench harness with a T1 PHY inside it is not passive. It holds a role of its own, and that role has to pair with the device under test. The developer forum thread mentioned above turns on exactly this: the engineer ran experiments with converters whose role was set by a DIP switch, and found their sensor and their compute platform had ended up on the same side. Take inline devices out once the direct link is proved, or record what each is set to.
Steps 4 to 6, prove the PHY is alive and configured
Reading the PHY identifier over MDIO before you trust any other register value
The Linux kernel documentation describes the mechanism plainly. An MDIO bus driver provides read and write functions where mii_id is the address on the bus for the PHY and regnum is the register number. During bus initialisation the PHY abstraction layer identifies a device by reading its UID from registers 2 and 3 and comparing it against each driver’s phy_id field ANDed with that driver’s phy_id_mask. A PHY device name looks like 0:00: bus id first, address second.
Be careful what you claim about all-ones and all-zeros reads: the kernel documentation does not define either as an error code. It does say identification depends on those two registers returning the UID, and that phy_attach binds a generic driver when none was found at bus initialisation. A uniform read across every address is evidence the transaction is not reaching something that answers, which puts address, bus, power, reset and management clock ahead of any register-level theory.
PHY address conflicts and the wrong MDIO bus, the two failures that look like a dead device
An address conflict comes first. Two PHYs on one bus strapped to the same address make reads ambiguous and writes land on both, and on a board carrying a switch and discrete PHYs this is a real risk, because strap options often share functional pins.
The second is the wrong bus. A device tree or driver configuration pointing at the wrong one of several MDIO buses produces a PHY present on the board and absent from the operating system. The 0:00 naming is what to check, both halves against the schematic. ethtool takes a phyad N parameter for the PHY address, and ethtool -d prints a register dump, decoded for some devices and in hex for the rest.
Strap resistors versus register configuration, and which one wins after a reset
In a public thread on one silicon vendor’s forum the vendor’s own support answer states it directly: the mode is set on each device by a strap resistor or by writing to registers, and the registers can be read back to determine which mode the device is in. Two questions follow, both for your part’s datasheet.
Which one wins? A strap is sampled at reset; a register write happens afterwards. On some parts the write overrides the strap, but the ordering is the part’s business and not something to assume.
What survives a reset? Configuration written before a reset is configuration you no longer have. If a driver probe resets the PHY after your init script set the role, the strap value is what the link comes up with. Read the role back once the interface is fully up, and get the strap right so the default is correct.
Steps 7 and 8, prove the master and slave pairing
Exactly one master per link, and how to check the other end rather than assume it
The reason is the clock. In the IEEE 802.3bp Clause 97 description of the same role pair, a MASTER PHY uses a local clock to determine the timing of transmitter operations, and a SLAVE PHY recovers the clock from the received signal. Where auto-negotiation is not used, the draft states the relationship is established by management or hardware configuration of the PHY, with the ends brought into step by a PHY Link Synchronization function operating half duplex before training. Two masters gives two free-running clocks and nothing to recover; two slaves gives nobody sourcing one.
Which side should be master? There is no rule in the standard, and the vendor answer in the forum thread above was the same: either device can hold either role, as long as there is exactly one of each. That makes it an architecture decision, and it belongs in the interface control document rather than in one engineer’s head, informed by where the link sits in the vehicle architecture.
Checking the other end is the step people skip. When that same questioner asked what the default was on the downstream ports of a switch from another vendor, the answer was that they would have to check that vendor’s documentation.
Setting it from Linux with ethtool master-slave and reading it back
Where the kernel manages the PHY, ethtool is the vendor-neutral surface. The manual documents four values on the -s option: preferred-master and preferred-slave, expressing a preference during auto-negotiation, and forced-master and forced-slave, which it notes can be used without auto-negotiation. On 100BASE-T1 the forced pair applies. The manual carries the meaning too: as MASTER the PMA transmit function sources TX_TCLK from a local clock source, as SLAVE from the clock recovered from the MASTER’s data stream. Not all devices support it.
Read it back. The ethtool netlink interface carries ETHTOOL_A_LINKMODES_MASTER_SLAVE_CFG for the master/slave port mode and ETHTOOL_A_LINKMODES_MASTER_SLAVE_STATE for the master/slave port state: what you asked for, and what the port actually is. A write that did not take, or that a reset discarded, shows up as a disagreement between them.
Switch ports and SoC MAC ports: where the setting actually lives
The setting does not always live where ethtool can reach it. Behind a managed switch it is a switch port configuration reached through the switch’s management interface or driver, and the host’s ethtool view may show the CPU-facing port rather than the T1 port. Where the PHY hangs off an SoC MAC the kernel owns, ethtool on that interface is the right surface. On some integrated platforms the role is fixed by board firmware running before the operating system, which is where the developer forum thread landed. The vendor answered that the platform’s 1000BASE-T1 ports default to slave, that its ports do not negotiate the role, and that changing it has to be done through the board’s Aurix firmware rather than from Linux. Note the scope: that is a statement about one platform’s ports, not about the link type. Clause 98 auto-negotiation does exist for 1000BASE-T1, and it is optional, so a platform can simply not implement it.
Speed and mode mismatches: 100BASE-T1 against 1000BASE-T1 against 10BASE-T1S
A matching role is not sufficient. 100BASE-T1, 1000BASE-T1 and 10BASE-T1S are different clauses with different symbol rates and different line codes, and nothing on the pair adapts one to another. A port forced to 100BASE-T1 facing one forced to 1000BASE-T1 will not link however the roles are set. The T1 family article has the comparison.
Worked examples from public threads, generalised into the step
Both threads quoted above are this step in miniature. The first, on a silicon vendor’s forum, gets a clean set of answers and still cannot tell the engineer what the switch at the other end defaults to.
The second is the reason this article exists. An engineer who cannot talk to a T1 sensor asks three yes/no questions: do the ports default to slave, does the role auto-negotiate, can it be changed. The thread runs to eighteen posts over twelve days, they wait eleven days, solve it themselves through the board’s firmware console two days before the answer arrives, and the answer when it comes is about the platform’s 1000BASE-T1 ports rather than the 100BASE-T1 ports he asked about. Those three questions are exactly what a vendor-neutral checklist should answer on day one.
Steps 9 and 10, the link comes up and then drops
EMC and cable resonance in component-level tests, with the published case study
A component-level EMC test bench has a resonance of its own, and on a T1 harness that resonance shows up as an emissions failure rather than as a link failure.
In component-level automotive EMC tests a cable bundle of pre-defined length connects the device under test to the test system, typically 1.7 m to 2.0 m, with 1.8 m standard practice. With one side grounded and the other floating, that cable is analogous to a folded monopole antenna whose primary resonant frequency is where a quarter wavelength matches its length. For 1.8 m that estimates to roughly 41 MHz, and measured peaks fall between 30 MHz and 40 MHz because of parasitic capacitance. The result is wideband emission peaks in radiated and conducted current emission measurements; the published example shows a peak at 33.5 MHz that disappears when the 100BASE-T1 connection is unlinked, which is to say the T1 channel was the source of the coupled noise rather than its victim.
The mitigations are structural: change termination and grounding at the cable ends to alter the resonant structure, and reduce the power coupled into it by checking shield effectiveness, connector design, channel symmetry and supply noise near the connectors.
Temperature, connector strain and harness routing on a real vehicle loom
The other family of intermittents is mechanical and thermal, and it is why bench-stable links fail in vehicle. Work the differences deliberately: connector seating and latch retention under vibration, routing alongside a switching supply, temperature cycling that moves both the cable’s characteristics and the PHY’s margin, strain where a harness bends. Then the channel, because a loom adding inline joints beyond the four the link segment assumes has left the specified channel even if the link still comes up cold.
Link quality indicators the PHY already gives you
The ethtool netlink interface exposes a Signal Quality Index as a current value plus the maximum that PHY supports, so it is meaningful only relative to that maximum. It is a receiver-side quality number rather than a link-up flag, which is what makes it worth trending on a link that is up but marginal.
Recent ethtool also carries --show-mse, PHY Mean Square Error diagnostics following the OPEN Alliance PHY diagnostics model used by automotive and industrial PHYs. Lower values generally indicate better signal quality and 0 is ideal, but scaling and sampling windows are vendor specific and reported by the PHY’s capability block, so values are read against the reported maximum scales rather than compared across parts. The manual warns that short windows can yield high variance and that userspace should poll and average. Which is the instruction for both: log them across a thermal cycle and a shake, do not read one sample.
Reading the pair with an oscilloscope when the registers say the link is fine
When registers report a healthy link and the system still misbehaves, look at the pair: a differential probe and an instrument with the bandwidth to make sense of what comes back, alongside the other in-vehicle buses you are correlating against. We covered that side of the bench in measuring automotive Ethernet alongside CAN FD, LIN and FlexRay.
Two cautions. Probing a live pair changes it, because both transmitters drive the same conductors and your probe becomes part of the channel. And a scope tells you about the signal, not about conformance.
When to escalate to conformance testing rather than keep probing
The OPEN Alliance publishes a public set for 100BASE-T1: interoperability, PHY control, physical coding sublayer and physical media attachment test suites, EMC test specifications for transceivers, common mode chokes and ESD suppression devices, channel and component requirements, and ECU test specifications for layer 1 and layer 2. If the symptom is intermittent, environment-dependent and reproducible only in a system, that is an interoperability and conformance question. Published test suites give you a result a supplier will act on; probing gives you an anecdote.
Symptom to cause lookup table
| Symptom | First check | Likely cause | Confirming measurement |
|---|---|---|---|
| No link, both ends powered | Role at each end | Both master, or both slave | Master/slave state, not the config |
| No link, role looks correct | Reset and power state | In reset, standby, or asleep | Rails, reset line, mode register |
| No link, PHY absent from the OS | MDIO address and bus | Address conflict, or wrong bus | UID from registers 2 and 3 |
| No link through a bench setup | Inline devices | A converter holding its own role | Remove them, test direct |
| No link at a specific speed | Physical layer at each end | 100BASE-T1 against 1000BASE-T1 | Forced mode at both ends |
| Link up, no frames | Switching, VLAN, port mapping | Not a physical layer fault | Frame counters at both ends |
| Drops under vibration | Seating at every mated pair | Partially latched or strained connector | SQI or MSE while agitating joints |
| Emission peak at 30-40 MHz in the EMC lab | Bundle length and end grounding | Cable resonance in the test setup | Repeat with the T1 link unlinked |
| Drops in vehicle, not on bench | Channel against the link segment | More connectors, longer or different cable | Joints counted against 15 m and four inline |
| Role reverts after reboot | Config order against reset | Write discarded by a later reset | Role read back once the interface is up |
The four causes to rule out first
The first four rows cost nothing to check and cover the cases where the copper is fine and the configuration is not: both ends in the same role, a device not actually running, a PHY invisible on the management bus, and a converter quietly holding a third role in the middle.
Evidence to attach when you raise it with the silicon vendor
Send state, not story: the list you wrote down before the first change, plus the read-back role state at both ends, a register dump or at minimum the UID from registers 2 and 3, driver and kernel version, whether the role survives a reboot, and for a marginal link an SQI or MSE trend rather than a single sample.
That turns an escalation into a shared measurement rather than an exchange of opinions. It is close to what a production station needs when a link fails there instead: programming and flashing over automotive Ethernet at end of line is a different discipline, but it starts from a link that comes up.
Where GSAS fits
GSAS Micro Systems is an engineering partner, and on a link that will not come up the useful first conversation is not about equipment. It is about which of the ten steps your programme can already answer, because that separates a configuration problem from a channel problem.
The questions are narrow. Is the master and slave assignment for each link recorded where a second integrator can find it? Does your bring-up sequence read the role back after reset, or only write it? Does your harness sit inside the link segment the PHY was specified against, connector count included? And on a marginal link, are you trending the PHY’s own quality metrics or hunting a single moment of failure?
Our applications engineers work in IST, so a bench session lands inside your working day, and quotations are issued in INR through the procurement channels Indian OEMs and tier-one suppliers already use. The teams we work with sit in Bengaluru, Pune, Chennai and Hyderabad. Start with the automotive Ethernet capabilities page, then request a scoped conversation about a specific link, harness or validation plan. Where our answer is that you do not need to buy anything yet, that is the answer you get.
References
- IEEE 802.3 Ethernet Working Group: https://www.ieee802.org/3/
- IEEE P802.3bw D1.2 approved working group ballot comments (100BASE-T1 MASTER and SLAVE relationship set by FORCE mode; rejected request for negotiable MASTER and SLAVE functionality, recorded as a pre-configured embedded network without plug and play functionality; struck justification about auto-negotiation latency; link-up starting with the MASTER PHY sending symbols to the SLAVE and the SLAVE correcting polarity; link segment of up to 15 m of single balanced twisted-pair cable with up to four inline connectors and two end connectors): https://www.ieee802.org/3/bw/comments/8023bw_D1_2_approved.pdf
- IEEE P802.3bp D1.4 Clause 97 draft text (MASTER PHY uses a local clock, SLAVE PHY recovers the clock from the received signal; when auto-negotiation is not used the relationship is established by management or hardware configuration of the PHY; PHY Link Synchronization operates half duplex before training starts): https://www.ieee802.org/3/bp/public/may15/tu_3bp_02a_0515.pdf
- Linux ethtool manual page (master-slave values preferred-master, preferred-slave, forced-master and forced-slave; TX_TCLK sourcing in MASTER and SLAVE roles; phyad; register dump; cable-test and cable-test-tdr behaviour; show-mse PHY Mean Square Error diagnostics following the OPEN Alliance PHY diagnostics model): https://man7.org/linux/man-pages/man8/ethtool.8.html
- Linux kernel PHY abstraction layer documentation (MDIO bus read and write prototypes with mii_id as the PHY address; PHY UID stored in registers 2 and 3 matched against phy_id and phy_id_mask; PHY device naming as bus id and address; phy_attach binding a generic driver where none was found at bus initialisation): https://docs.kernel.org/networking/phy.html
- Linux kernel ethtool netlink documentation (ETHTOOL_A_LINKMODES_MASTER_SLAVE_CFG master/slave port mode, ETHTOOL_A_LINKMODES_MASTER_SLAVE_STATE master/slave port state, ETHTOOL_A_LINKSTATE_SQI and ETHTOOL_A_LINKSTATE_SQI_MAX, link extended state and substate values): https://docs.kernel.org/networking/ethtool-netlink.html
- OPEN Alliance automotive Ethernet specification index (100BASE-T1 Interoperability Test Suite, PHY Control Test Suite, Physical Coding Sublayer and Physical Media Attachment Test Suites, EMC Test Specifications for Transceivers, Common Mode Chokes and ESD Suppression Devices, Channel and Component Requirements, Sleep/Wake-up Specification and test suite, Automotive Ethernet ECU Test Specification Layer 1 and Layer 2): https://opensig.org/automotive-ethernet-specifications/
- OPEN Alliance Technical Committees: https://opensig.org/tech-committees/
- “Cable Resonance in Automotive Component EMC Tests”, Signal Integrity Journal (1.7 m to 2.0 m bundle lengths with 1.8 m standard practice, folded monopole analogy and quarter-wave estimate of about 41 MHz for 1.8 m, measured peaks from 30 MHz to 40 MHz, the 33.5 MHz driver monitor system example, and the termination, shielding, symmetry and supply-noise mitigations): https://www.signalintegrityjournal.com/articles/4073-cable-resonance-in-automotive-component-emc-tests
- Public silicon vendor forum thread on 100BASE-T1 master and slave configuration (one master and one slave required, no auto-negotiation on that device, role set by strap resistor or register write and readable back from registers, no rule on which side takes which role, third-party switch defaults to be checked in that vendor’s documentation): https://e2e.ti.com/support/interface-group/interface/f/interface-forum/949811/dp83tc811s-q1-master-and-slave-configuration-in-100base-t1
- Public SoC platform developer forum thread on changing T1 port master and slave configuration (eighteen posts; three yes/no questions about default role, auto-negotiation and changing the role, answered eleven days later and scoped to 1000BASE-T1 rather than the 100BASE-T1 ports asked about; converter role experiments; resolution through the board firmware console rather than the operating system): https://forums.developer.nvidia.com/t/how-to-change-base-t1-ports-master-slave-configuration/199674
Also appears in:
Building for Automotive & Mobility?
Talk to our application engineers for personalized tool recommendations.
