EthTrcv — Was kann bei der Inbetriebnahme schiefgehen?

Diagnose-APIs nutzen — Kabeldiagnose (TDR-basiert, vendor-spezifisches Register) starten und das Ergebnis auslesen. Ein sauberes Kabel meldet keine Reflexionen; ein defektes zeigt Short/Open und häufig sogar eine ungefähre Fehlerposition in Metern. Ergänzend lassen sich Loopback-/Testmodes aktivieren, um den PHY selbst vom Kabel zu isolieren und so PHY-Fehler von Kabel-Fehlern zu trennen.

AUTOSAR-Tooling-Konfiguration gegen reale Hardware prüfen — ARXML-Parameter wie EthTrcvSpeed und EthTrcvDuplexMode müssen mit dem tatsächlich verbauten PHY und dessen Fähigkeiten übereinstimmen. Ein häufiger Fehler: ein Parameter wurde von einer älteren Boardrevision kopiert, die einen anderen PHY-Chip mit anderen Default-Fähigkeiten hatte.

EthTrcv_GetDuplexMode/EthTrcv_GetBaudRate auslesen und vergleichen — auf beiden Seiten der Verbindung, wenn beide Seiten unter eigener Kontrolle stehen. Eine Diskrepanz zwischen dem, was konfiguriert wurde, und dem, was der Treiber tatsächlich zurückliefert, zeigt sofort, ob das Problem in der Konfiguration oder im PHY-Zustand liegt.

Pin-Straps auslesen — die Hardware-Default-Konfiguration direkt am PHY verifizieren (siehe Exkurs zu Strap-Pins weiter unten), unabhängig von dem, was die Software später per MDIO überschreibt. Wenn Strap und Software-Konfiguration widersprüchlich sind, gewinnt je nach PHY entweder der letzte MDIO-Write oder der Strap-Wert bleibt bis zum nächsten Reset bestehen — das steht im Datenblatt und ist PHY-spezifisch.

Prüfen, ob der Transceiver via EthTrcv_SetTransceiverMode tatsächlich in ETH_MODE_ACTIVE gesetzt wurde — ein Transceiver, der im Modus ETH_MODE_DOWN verharrt, zeigt exakt dasselbe äußere Symptom wie ein defekter PHY: kein Link, keine Aktivität auf der Leitung. Der Unterschied liegt rein in der Software-Ansteuerung, nicht in der Hardware.

Prüfen, ob ControllerInit des Eth-Treibers erfolgreich durchgelaufen ist — ein fehlgeschlagener MAC-seitiger Init verhindert den Link genauso zuverlässig wie ein PHY-Problem, zeigt sich aber typischerweise an einer ganz anderen Stelle im Log (Eth-Modul statt EthTrcv-Modul) und wird deshalb in der ersten Fehlersuche gerne übersehen.

MII-Interface-Typ beidseitig verifizieren — den tatsächlich verwendeten Interface-Typ sowohl aus der SoC-MAC-Treiberkonfiguration als auch aus dem PHY-Datenblatt bzw. den gelesenen Strap-Pins gegenüberstellen. Diese beiden Konfigurationen werden oft von unterschiedlichen Teams (SoC-BSP vs. PHY-Bring-up) gepflegt und laufen leicht auseinander.

Taktsignale am Interface oszilloskopisch prüfen — bei RGMII die Frequenz von TXC/RXC messen und mit der erwarteten Geschwindigkeit abgleichen (125 MHz bei 1 Gbit/s, 25 MHz bei 100 Mbit/s, 2,5 MHz bei 10 Mbit/s). Eine falsche Taktfrequenz ist der eindeutigste Beweis für einen Speed-Mismatch zwischen MAC und PHY.

Mode-/Standby-Pins auf ihren tatsächlichen Pegel prüfen — mit Multimeter oder Oszilloskop direkt am Pin, nicht nur in der Schaltplan-Dokumentation. Ein Pin, der laut Schaltplan auf "aktiv" liegen soll, aber durch einen Bestückungsfehler auf dem falschen Potential hängt, ist ein klassischer Board-Bring-up-Fehler.

Rohen Frame-Traffic direkt am MII-Interface mitschneiden — mit einem Logic-Analyzer, der einen MII/RGMII-Decoder unterstützt. Das zeigt unmittelbar, ob überhaupt Bits über das Interface laufen, und falls ja, ob sie als gültige Frames dekodierbar sind — unabhängig davon, was der EthTrcv-Treiber softwareseitig meldet.

Treiber-/Hardware-Konfiguration gegen die tatsächliche PCB-Bestückung prüfen — welches Interface (MII/RMII/RGMII) der Treiber erwartet, ergibt sich implizit aus der konkreten Hardware- und Treiberintegration (es gibt kein eigenes ARXML-Enum dafür); diese Erwartung muss exakt zur Hardware passen, nicht nur zur ursprünglichen Design-Absicht.

EthTrcv_GetLinkState wiederholt pollen und Drop-Zeitpunkte protokollieren — ein einfaches Loggingskript, das den Link-Zustand samt Zeitstempel mitschreibt, liefert die Grundlage für jede weitere Korrelation. Ohne Zeitstempel lässt sich ein EMV-bedingter Drop nicht von einem mechanischen Wackelkontakt unterscheiden.

Drop-Zeitpunkte mit anderen Ereignissen korrelieren — Motorstart, Schalten von Relais, Betätigen von Aktoren im selben Kabelbaum. Fällt der Link exakt beim Einschalten eines bestimmten Verbrauchers, ist EMV-Einkopplung der naheliegendste Verdächtige.

RMS-Amplitude bzw. SQI-Werte (Signal Quality Index) auslesen — sofern der PHY diese vendor-spezifischen Diagnoseregister anbietet, liefern sie ein quantitatives Maß für die Signalreserve, statt nur ein binäres "Link up/down". Ein SQI-Wert, der nahe an der Schwelle liegt, bestätigt eine Marginal-Link-Situation, auch wenn der Link im Moment der Messung gerade steht.

Kabeldiagnose (TDR) unter Betriebsbedingungen wiederholen — nicht nur einmalig im Ruhezustand, sondern während der Link aktiv belastet wird und idealerweise unter denselben mechanischen/thermischen Bedingungen, unter denen die Drops auftreten.

Temperaturtests gezielt wiederholen — im Klimaschrank definierte Temperaturrampen fahren und dabei kontinuierlich den Link-Zustand protokollieren, um eine Temperaturschwelle einzugrenzen, ab der die Drops beginnen.

Mechanische Prüfung der Steckverbindung — Steckverbinder gezielt leicht bewegen (innerhalb der spezifizierten Toleranz) während der Link-Zustand beobachtet wird, sowie Sichtprüfung auf Korrosion oder unzureichende Kontaktkraft.

Register-Reads gegen Standardregister wie die PHY-ID prüfen — ein durchgehendes 0xFFFF oder 0x0000 über mehrere unterschiedliche Register hinweg (nicht nur eines) deutet zuverlässig auf ein Busproblem hin, nicht auf ein Konfigurationsproblem innerhalb des PHYs. Antwortet der PHY dagegen mit einem plausiblen, aber falschen Wert, liegt das Problem eher bei der Adressierung als auf der elektrischen Ebene.

Spannungspegel und Power-Sequencing messen — alle relevanten Versorgungsdomänen (siehe Hardware Deep Dive) mit dem Oszilloskop beim Power-On aufzeichnen und die gemessene Reihenfolge sowie die zeitlichen Abstände gegen das Datenblatt prüfen.

Reset-Timing oszilloskopisch prüfen — Dauer des Low-Pegels an RST_N sowie den zeitlichen Abstand zwischen Deassertieren des Resets und dem ersten MDIO-Zugriff messen und mit der im Datenblatt geforderten minimalen Boot-Zeit vergleichen.

MDIO-Adresse per Pin-Strap-Readback verifizieren — falls der PHY dies unterstützt, die tatsächlich gestrapte Adresse unabhängig von der Software auslesen (z. B. über ein Statusregister, das den Strap-Wert nach dem Boot weiterhin sichtbar hält), statt sich allein auf die Schaltplan-Dokumentation zu verlassen.

Inkonsistente oder korrumpierte Register-Reads als Symptom erkennen — ein Adresskonflikt zeigt sich selten als sauberer, eindeutiger Fehler, sondern als unzuverlässiges Verhalten: mal antwortet PHY 1, mal PHY 2, mal überlagern sich beide Antworten zu einem Wert, der zu keinem der beiden passt. Dieses Muster — Werte, die von Read zu Read ohne ersichtlichen Grund wechseln — ist der stärkste Hinweis auf einen Adresskonflikt, im Unterschied zum konsistenten 0xFFFF bei einem reinen Busproblem.

Adress-Strap-Pins jedes PHYs einzeln prüfen — für jeden PHY auf dem Board getrennt die gestrapte Adresse anhand des Schaltplans und, falls möglich, per Pin-Messung verifizieren, statt sich auf die ARXML-Konfiguration allein zu verlassen.

PHYs einzeln isolieren und Adresse verifizieren — falls das Board es zulässt, einen der beiden PHYs elektrisch vom MDIO-Bus trennen (z. B. durch Auslöten oder eine bestückbare Trennstelle) und die verbleibende PHY-Adresse gezielt auslesen. Damit lässt sich zweifelsfrei feststellen, welcher PHY auf welcher Adresse tatsächlich antwortet.

EthTrcv_CheckWakeup im EcuM-Validierungszyklus debuggen — mit Breakpoint oder Tracing direkt in der Funktion prüfen, ob sie überhaupt aufgerufen wird, ob sie einen gültigen WakeUp-Grund erkennt, und ob EcuM_SetWakeupEvent mit der erwarteten ID tatsächlich ausgeführt wird, bevor EcuMValidationTimeout abläuft.

WakeUp-Puls hardwareseitig mit dem Oszilloskop prüfen — direkt am WU-Pin bzw. am MDI-Leitungspaar mitschneiden, ob überhaupt ein Impuls bzw. eine TC10-Pulsfolge ankommt, und ob deren Form/Timing der Spezifikation entspricht. Das trennt zuverlässig "Hardware-Signal kommt nicht an" von "Software erkennt ein ankommendes Signal nicht".

EcuM-Mapping prüfen — die Verknüpfung zwischen EthTrcvWakeupSourceRef im ARXML und der tatsächlich im EcuM konfigurierten EcuMWakeupSource Zeile für Zeile nachvollziehen, gerade nach Copy-Paste-Konfigurationsänderungen zwischen mehreren Steuergeräte-Varianten.

Fehlerzähler beobachten und mit Lastzuständen korrelieren — CRC-, Alignment- und Symbol-Fehlerzähler regelmäßig auslesen (meist Read-Clear-on-Read, also mit fester Abtastperiode protokollieren) und mit Umgebungsbedingungen wie Motorlast, Temperatur oder Datendurchsatz in Beziehung setzen. Eine Fehlerrate, die mit dem Datendurchsatz skaliert statt konstant zu sein, deutet eher auf ein Timing-Problem am MAC-Interface; eine Fehlerrate, die mit externen Lastwechseln korreliert, eher auf EMV.

Signalqualität über PHY-Diagnoseregister auslesen — SQI und vergleichbare vendor-spezifische Metriken liefern ein quantitatives Bild der Leitungsseite, unabhängig von den reinen Fehlerzählern, und helfen einzugrenzen, ob das Problem auf der Leitungsseite (MDI) oder dem digitalen MAC-Interface liegt.

Loopback-Tests zur Eingrenzung nutzen — durch gezieltes Kurzschließen des Datenpfads an unterschiedlichen Stellen (intern im PHY, extern am MDI) lässt sich feststellen, ob Fehler bereits ohne reale Leitung auftreten (→ Hinweis auf ein MAC-Interface- oder PHY-internes Problem) oder erst mit angeschlossenem Kabel (→ Hinweis auf die Leitungsseite). Details zu den verfügbaren Loopback-Modi und wie man sie über AUTOSAR aktiviert, stehen im eigenen Loopback-Post.