EthTrcv — MDIO-Zugriff und PHY-Register direkt lesen

MDIO (Management Data Input/Output) ist der serielle Steuerbus zwischen MAC/SoC und PHY-Chip, über den EthTrcv_Init und alle Register-Zugriffe laufen — nicht über MII/RGMII. IEEE 802.3 kennt zwei Frame-Formate: Clause 22 (klassisch, 32 Register pro PHY) und Clause 45 (erweitert, mit DEVAD-Adressraum, Pflicht bei 1000BASE-T1 und Safety-PHYs).

Kurz zur Auffrischung das Frame-Format, weil die Feldnamen im weiteren Verlauf ständig auftauchen:

PHYAD/PRTAD adressiert den Chip auf dem Bus, REGAD/DEVAD+Adresse adressiert das Register innerhalb des Chips. Genau diese Registeradressen sind das Thema dieses Posts.

Jeder IEEE-konforme PHY implementiert einen Satz Standard-Register, die bei jedem Hersteller an der gleichen Adresse liegen und die gleiche Bedeutung haben. Darüber hinaus definiert jeder Hersteller Vendor-spezifische Register für Diagnosefunktionen, die über den IEEE-Standard hinausgehen (Kabeldiagnose, erweiterte Fehlerzähler, LED-Konfiguration).

Im Normalfall greift Applikationscode nicht direkt auf MDIO zu — und die Funktion, die EthTrcv dafür aufruft, gehört auch nicht zu EthTrcv selbst, sondern zu EthIf: EthIf_ReadMii/EthIf_WriteMii (deklariert in EthIf.h). EthIf ist dabei nur Vermittler, nicht Ausführender: Laut Spezifikation (SWS_EthIf_00706/SWS_EthIf_00707) leitet EthIf den Aufruf intern an die Funktion <EthDrv>_ReadMii/<EthDrv>_WriteMii des zuständigen Ethernet-Controller-Treibers weiter — in der Praxis also an Eth_ReadMii/Eth_WriteMii des Eth-Moduls, das den physischen MDIO-Bus tatsächlich schaltet.

CtrlIdx wählt den Ethernet-Controller (MAC) aus, dem der betreffende MDIO-Bus gehört, TrcvIdx den Transceiver auf diesem Bus, RegIdx die Registeradresse gemäß PHY-Register-Map. Beide Funktionen sind laut Spezifikation ausdrücklich synchron (Sync/Async: Synchronous) — sie blockieren, bis die MDIO-Transaktion abgeschlossen ist, und liefern das Ergebnis direkt als Std_ReturnType zurück; EthIf_ReadMii zusätzlich den gelesenen Registerwert über RegValPtr.

Für EthTrcv bedeutet das: Es reicht ein einziger, blockierender Aufruf pro Registerzugriff. Das ist einfacher als das frühere Request/Indication-Muster, hat aber eine Kehrseite — EthTrcv_MainFunction darf nicht so lange synchron auf eine MDIO-Transaktion warten, dass andere Aufgaben des Treibers ins Hintertreffen geraten. Wie lange ein Aufruf real blockiert, hängt vom Timing des zugrunde liegenden Eth-Treibers und der MDC-Frequenz ab.

Ob EthTrcv überhaupt per MII mit Eth spricht, ist eine Konfigurationsentscheidung, kein Automatismus. AUTOSAR modelliert das als Choice-Container in der ECU-Konfiguration:

Einen Parameter EthTrcvReadMiiApi gibt es nicht — welcher Zugriffsweg aktiv ist, wird darüber entschieden, welcher der beiden Container im ARXML konfiguriert ist, nicht über ein Bool-Flag.

Nicht jede Debug-Situation hat Zugriff auf den vollständigen AUTOSAR-Stack — beim Hardware-Bring-up läuft oft noch kein RTE, oder man debuggt auf einem Evaluation-Board ganz ohne AUTOSAR. In diesem Fall bleiben zwei Wege:

Weg 1 — Bare-Metal-Treiber: Ein minimaler MDIO-Treiber, der direkt die MAC-Register des SoCs für MDIO-Transaktionen anspricht (die meisten SoC-MACs haben dafür ein eigenes MDIO-Controller-Register-Set, unabhängig vom eigentlichen Ethernet-Datenpfad).

Weg 2 — externer MDIO-Adapter (siehe Abschnitt "Tooling" unten): Wenn selbst der SoC nicht vertrauenswürdig ist (z. B. weil man einen MAC-Fehler vom PHY-Fehler unterscheiden will), kann ein externer USB-MDIO-Adapter komplett am Ziel-SoC vorbei direkt auf den MDIO-Bus zugreifen.

Für die tägliche Fehlersuche reicht ein kleiner, immer wiederkehrender Satz an Registern. Die folgende Tabelle zeigt die Standard-Bits im Basic Status Register (Adresse 1), die für Link-Diagnose relevant sind:

Für Speed und Duplex existieren keine eigenen Bits im Basic Status Register — die liegen entweder im Auto-Negotiation Link Partner Ability Register (5) in Kombination mit dem Advertisement-Register (4), oder direkt in einem Vendor-Statusregister, das viele PHYs als bequeme Abkürzung anbieten (z. B. "Auto-Negotiated Speed/Duplex" in einem einzigen Register statt der Ableitung aus zwei Capability-Registern).

Der TJA1100 ist einer der verbreitetsten 100BASE-T1-PHYs in Automotive-Designs und eignet sich gut als konkretes Beispiel, weil sein Registersatz gut dokumentiert und repräsentativ für die Klasse der 100BASE-T1-Automotive-PHYs ist.

Für MDIO-Diagnose abseits des Ziel-SoCs gibt es etablierte Werkzeugklassen:

Ausgangslage: Ein Steuergerät mit TJA1100-PHY meldet über EthTrcv_GetLinkState dauerhaft ETHTRCV_LINK_STATE_DOWN. Das Kabel ist augenscheinlich korrekt gesteckt, die Gegenseite (Switch-Port) zeigt ebenfalls keinen Link. Schritt-für-Schritt-Diagnose über MDIO-Register:

Schritt 1 — Ist der PHY überhaupt ansprechbar?

Beide Werte entsprechen der bekannten TJA1100-OUI. Der PHY antwortet — MDIO-Bus, Pull-up und PHY-Adresse sind also in Ordnung. Wäre hier 0xFFFF zurückgekommen, läge der Fehler auf Busebene (siehe Hardware Deep Dive), nicht im Link selbst.

Schritt 2 — Basic Control Register prüfen: ist der PHY im Power-Down oder Reset?

Gefunden: Bit 11 ist gesetzt, der PHY befindet sich im Power-Down-Modus. Das erklärt den fehlenden Link vollständig — ein PHY im Power-Down treibt keine Signale auf die Leitung.

Schritt 3 — Ursache für Power-Down eingrenzen

Ein Blick ins TJA1100-Datenblatt zeigt: Bit 11 im Basic Control Register wird beim Power-On je nach Zustand des CONFIG-Pins automatisch gesetzt. In diesem Fall war ein Pull-Widerstand auf dem CONFIG-Pin des Evaluation-Boards falsch bestückt — eine Board-Bestückungsvariante, die für ein anderes Power-On-Verhalten vorgesehen war.

Schritt 4 — Workaround zur Bestätigung: Power-Down per Software aufheben

Nach dem Löschen von Power-Down und einem Autonegotiation-Neustart kommt der Link tatsächlich hoch. Root Cause bestätigt: Hardware-Bestückungsfehler auf dem CONFIG-Pin, kein Software- oder Kabelfehler.

Schritt 5 — Ausgehandelten Modus verifizieren

Der interne Zustandsautomat des TJA1100 bestätigt ACTIVE — die Diagnose ist abgeschlossen. Die endgültige Behebung erfolgt auf Hardware-Ebene (Bestückungskorrektur in der nächsten Board-Revision); bis dahin dient das MDIO-Write aus Schritt 4 als Werkstatt-Workaround, nicht als Serienlösung.

Weiter in der EthTrcv-Serie: EthTrcv & IEEE 802.1AS — gPTP und Hardware-Timestamping im PHY