Analogous to this blog’s EthTrcv bring-up post, this article collects the most common failure patterns during EthSwt chip bring-up — referencing the concrete APIs and error codes from the previous parts of this series.
First diagnostic step: where is the system stuck?
A port won’t come up
Possible causes:
EthSwtPortMacLayerTypeorEthSwtPortTrcvRefmisconfigured in the ARXML (see Part 3)The port was never activated via
EthSwt_SetSwitchPortMode(…, ETH_MODE_ACTIVE)The underlying
EthTrcvport has no link (see the EthTrcv bring-up post)The call happened before state
ETHSWT_STATE_PORTINIT_COMPLETEDwas reached (see Part 2) — the API reliably returnsE_NOT_OKin that case
Possible debugging paths:
Poll
EthSwt_GetSwitchPortModeandEthSwt_GetLinkStateper port and compare against the expected topologyCheck the extended production error
ETHSWT_E_SYNCPORT2PHY— indicates a mismatch between switch port mode and PHY modeCheck the port configuration in the AUTOSAR tooling against the physical wiring
Verify the transceiver reference for each port individually
No forwarding possible between two ports
Possible causes:
VLAN configuration separates the ports (
EthSwtPortIngressDefaultVlan, different VLAN IDs,EthSwt_EnableVlanaccidentally set toFALSEfor a required VLAN — see Parts 3/4)The MAC address table (ARL/FDB) has overflowed, or entries aged out too early (see this series' ARL table post)
Wrong MAC learning mode (
EthSwt_GetMacLearningMode) for the given topology (SVL instead of IVL or vice versa)
Possible debugging paths:
Cross-check the VLAN assignment of both ports (default VLAN, ingress VLAN translation)
Read out
EthSwt_GetArlTableand check for missing/incorrect entriesMirror traffic selectively to a diagnostic port (see Part 4,
EthSwt_WritePortMirrorConfiguration) and observe the actual frame flow
Host interface not responding (SPI / MDIO / MMD)
Possible causes:
SPI: clock polarity/phase (CPOL/CPHA) mismatch between host and switch chip
MDIO/MMD: wrong device or register address in
EthSwt_ReadTrcvRegister/ReadMmdThe switch chip’s reset pin wasn’t deasserted, or not long enough
Power-sequencing error on multi-port chips (see this series' hardware deep dive)
Possible debugging paths:
Capture the SPI bus with a logic analyzer and check timing/mode against the datasheet
Test
EthSwt_GetSwitchRegagainst a known standard register (chip ID)Check power sequencing and reset timing with an oscilloscope
MAC address table overflows / behaves unexpectedly
Possible causes:
Aging time configured too long for the actual network dynamics
A broadcast storm or a loop in the network fills the table with constantly changing entries (see the case study in Part 4)
Static entries collide with learned dynamic entries
Possible debugging paths:
Watch the MIB counters (
EthSwt_GetRxStats/GetTxStats) per port, identify unusually high broadcast/multicast ratesPeriodically read out
EthSwt_GetArlTablecontent and check for unusual growth
Mirroring delivers no or wrong packets
Possible causes:
CapturePortIdxor the ingress/egress bitmasks in the port-mirror configuration are set incorrectly (see Part 4)MirroringPacketDividerset too high, so practically no frames arriveThe mirror target port itself is not
ETH_MODE_ACTIVE
Possible debugging paths:
Read out
EthSwt_ReadPortMirrorConfigurationand compare it against the intended configurationCheck
EthSwt_GetPortMirrorState— is mirroring even active?Set the divider to
1as a test to rule it out as the cause
Summary
| Symptom | First thing to check |
|---|---|
Port won’t come up | State ( |
No forwarding | VLAN configuration, ARL table, MAC learning mode |
Host interface dead |
|
ARL table overflowing | Check MIB counters for broadcast/multicast rates |
Mirroring delivers nothing | Cross-check mirror configuration and mirror port state |