Analog zum EthTrcv-Inbetriebnahme-Post dieses Blogs sammelt dieser Artikel die häufigsten Fehlerbilder beim Bring-up eines EthSwt-Chips — mit Bezug auf die konkreten APIs und Fehlercodes aus den vorherigen Teilen dieser Serie.
Erster Diagnoseschritt: wo hängt das System fest?
Ein Port kommt nicht hoch
Mögliche Gründe:
EthSwtPortMacLayerTypebzw.EthSwtPortTrcvRefim ARXML falsch konfiguriert (siehe Teil 3)Port wurde nie via
EthSwt_SetSwitchPortMode(…, ETH_MODE_ACTIVE)aktiviertZugrundeliegender
EthTrcv-Port hat keinen Link (siehe EthTrcv-Inbetriebnahme)Aufruf erfolgte, bevor der Zustand
ETHSWT_STATE_PORTINIT_COMPLETEDerreicht war (siehe Teil 2) — die API liefert dann zuverlässigE_NOT_OK
Mögliche Debugging-Wege:
EthSwt_GetSwitchPortModeundEthSwt_GetLinkStateje Port pollen und mit der erwarteten Topologie abgleichenExtended Production Error
ETHSWT_E_SYNCPORT2PHYprüfen — deutet auf einen Widerspruch zwischen Switch-Port-Modus und PHY-Modus hinPort-Konfiguration im AUTOSAR-Tooling gegen die physische Verkabelung prüfen
Trcv-Referenz je Port einzeln verifizieren
Kein Forwarding zwischen zwei Ports möglich
Mögliche Gründe:
VLAN-Konfiguration trennt die Ports (
EthSwtPortIngressDefaultVlan, unterschiedliche VLAN-IDs,EthSwt_EnableVlanversehentlich aufFALSEfür ein benötigtes VLAN — siehe Teil 3/4)MAC-Adresstabelle (ARL/FDB) ist übergelaufen bzw. Einträge wurden zu früh gealtert (siehe ARL-Tabelle-Post dieser Serie)
Falscher MAC-Learning-Modus (
EthSwt_GetMacLearningMode) für die vorliegende Topologie (SVL statt IVL oder umgekehrt)
Mögliche Debugging-Wege:
VLAN-Zuordnung beider Ports gegenprüfen (Default-VLAN, Ingress-VLAN-Translation)
EthSwt_GetArlTableauslesen und auf fehlende/falsche Einträge prüfenTraffic gezielt auf einen Diagnose-Port spiegeln (siehe Teil 4,
EthSwt_WritePortMirrorConfiguration) und den tatsächlichen Frame-Fluss beobachten
Host-Interface antwortet nicht (SPI / MDIO / MMD)
Mögliche Gründe:
SPI: Taktpolarität/-phase (CPOL/CPHA) zwischen Host und Switch-Chip stimmt nicht überein
MDIO/MMD: falsche Geräte- oder Registeradresse bei
EthSwt_ReadTrcvRegister/ReadMmdReset-Pin des Switch-Chips wurde nicht bzw. nicht lange genug deassertiert
Power-Sequencing-Fehler bei Mehrport-Chips (siehe Hardware-Deep-Dive dieser Serie)
Mögliche Debugging-Wege:
SPI-Bus mit Logic-Analyzer mitschneiden und Timing/Modus gegen Datenblatt prüfen
EthSwt_GetSwitchReggegen ein bekanntes Standardregister (Chip-ID) testenPower-Sequencing und Reset-Timing oszilloskopisch prüfen
MAC-Adresstabelle läuft über / verhält sich unerwartet
Mögliche Gründe:
Aging-Zeit zu lang für die tatsächliche Netzwerkdynamik konfiguriert
Broadcast-Sturm oder Loop im Netzwerk füllt die Tabelle mit ständig wechselnden Einträgen (siehe Fallstudie in Teil 4)
Statische Einträge kollidieren mit gelernten dynamischen Einträgen
Mögliche Debugging-Wege:
MIB-Zähler (
EthSwt_GetRxStats/GetTxStats) je Port beobachten, auffällig hohe Broadcast-/Multicast-Raten identifizierenEthSwt_GetArlTable-Inhalt periodisch auslesen und auf ungewöhnliches Wachstum prüfen
Mirroring liefert keine oder falsche Pakete
Mögliche Gründe:
CapturePortIdxbzw. die Ingress-/Egress-Bitmasken in der Port-Mirror-Konfiguration falsch gesetzt (siehe Teil 4)MirroringPacketDividerzu hoch gewählt, sodass praktisch keine Frames mehr ankommenMirror-Target-Port ist selbst nicht
ETH_MODE_ACTIVE
Mögliche Debugging-Wege:
EthSwt_ReadPortMirrorConfigurationauslesen und mit der beabsichtigten Konfiguration vergleichenEthSwt_GetPortMirrorStateprüfen — ist Mirroring überhaupt aktiv?Divider testweise auf
1setzen, um auszuschließen, dass er die Ursache ist
Zusammenfassung
| Symptom | Erster Blick |
|---|---|
Port kommt nicht hoch | Zustand ( |
Kein Forwarding | VLAN-Konfiguration, ARL-Tabelle, MAC-Learning-Modus |
Host-Interface tot |
|
ARL-Tabelle läuft über | MIB-Zähler auf Broadcast-/Multicast-Raten prüfen |
Mirroring liefert nichts | Mirror-Konfiguration und Mirror-Port-State gegenprüfen |