Dieser Post baut auf EthTrcv Teil 3 — ARXML-Konfiguration in der Praxis auf. Dort ging es darum, wie ein EthTrcv-Modul aus ARXML-Parametern entsteht. Jetzt ist das Steuergerät konfiguriert, initialisiert und läuft — aber ein Ethernet-fähiges Steuergerät verbringt einen erheblichen Teil seines Lebens nicht im aktiven Betrieb, sondern im Schlaf, im Aufwachen oder in der Fehlerbehandlung.

Dieser vierte und letzte Teil der Kernserie schließt genau diese Lücke: Wie ein Steuergerät über Ethernet aufwacht, wie EthSM den Transceiver-Zustand mit dem Rest des Systems koordiniert, und wie man als Entwickler herausfindet warum der Link nicht das tut was er soll.

WakeUp-Handling

Ethernet-WakeUp unterscheidet sich fundamental von einem CAN-WakeUp. Bei CAN reicht im einfachsten Fall eine dominante Flanke auf dem Bus. Bei einem Single-Pair-Ethernet-PHY steckt dahinter ein eigenes Protokoll — und genau das macht die Software-Seite interessanter als man zunächst denkt.

WakeUp-Quellen: PHY-Pin und In-Band-Signal

Zwei physikalisch unterschiedliche Mechanismen können einen EthTrcv-WakeUp auslösen.

1. PHY-Pin (WU-Pin, lokal/asynchron)

Der WU-Pin wurde bereits im Hardware Deep Dive beschrieben: ein externer Impuls auf diesem Pin bringt den PHY dazu, INH zu aktivieren und damit den Spannungsregler des Steuergeräts zu starten — lange bevor Software überhaupt läuft. Für EthTrcv_CheckWakeup ist das relevant, weil der Grund für diesen bereits erfolgten Hardware-WakeUp im Nachhinein softwareseitig bestätigt werden muss.

2. In-Band-WakeUp-Signal (100BASE-T1 Sleep/WakeUp gemäß OPEN Alliance TC10)

Automotive-100BASE-T1-PHYs implementieren üblicherweise das TC10-Sleep/WakeUp-Protokoll. Dabei sendet ein PHY, der ein anderes Steuergerät aufwecken will, eine definierte Folge von WakeUp-Pulsen direkt über das Datenpaar — kein separater Pin, kein zusätzliches Kabel.

Sender-PHY (bereits aktiv)              Empfänger-PHY (im Sleep)
     │                                        │
     │── Wake_Pulse ──────────────────────────►│
     │   (definierte Pulsfolge auf T1+/T1-)    │  PHY erkennt Muster
     │                                          │  → aktiviert lokal INH
     │                                          │  → Spannungsregler startet
     │◄── Link-Training / Auto-Neg ────────────►│
     │                                          │  ECU bootet, EcuM startet

TC10 unterscheidet zwischen einem lokalen WakeUp-Request (dieses Steuergerät möchte den Link-Partner aufwecken, ausgelöst über einen Aufruf von EthTrcv_SetTransceiverMode(ETH_MODE_ACTIVE_WITH_WAKEUP_REQUEST)) und einem Remote-WakeUp (dieses Steuergerät wird von einem anderen geweckt). Beide Fälle laufen softwareseitig letztlich über dieselbe EthTrcv_CheckWakeup-Auswertung bzw. den über EthTrcv_GetBusWuReason gelieferten Grund, aber die Wakeup-Reason unterscheidet sich — wichtig für die Diagnose später in diesem Post.

Der entscheidende Unterschied für den Software-Entwickler: Der PHY-Pin-WakeUp ist bereits "passiert" wenn Software zum ersten Mal läuft — er ist nur noch zu bestätigen. Das In-Band-Signal dagegen kann softwareseitig aktiv angefordert werden („Wecke die restlichen Steuergeräte am Segment auf") und ist Teil des normalen Netzwerk-Managements, nicht nur ein Boot-Ereignis.

EthTrcv_CheckWakeup — Ablauf im EcuM-WakeUp-Validation-Zyklus

Ein Hardware-WakeUp allein reicht dem EcuM nicht. AUTOSAR verlangt eine softwareseitige WakeUp-Validierung: Ein Wakeup-Grund muss innerhalb eines konfigurierten Zeitfensters (EcuMValidationTimeout) bestätigt werden, sonst gilt er als Störung (z. B. EMV-Einkopplung) und das Steuergerät fällt zurück in den Schlaf.

 1. Hardware-WakeUp (WU-Pin oder TC10-Puls) → INH aktiv → SoC bootet
 2. EcuM startet, erkennt konfigurierte WakeUp-Quelle mit Validierungsbedarf
 3. EcuM tritt in den WakeUp-Validation-Zyklus ein
        │
        ▼
 4. EcuM ruft zyklisch (oder ISR-getrieben) EcuM_CheckWakeup() auf
        │
        ▼
 5. Dispatch über EthSM an den Treiber:
        EthSM_CheckWakeup() → EthTrcv_CheckWakeup(TrcvIdx)
        │
        ▼
 6. EthTrcv_CheckWakeup liest den WakeUp-Status des PHYs
    (TC10 WakeUp-Status-Register bzw. WU-Pin-Latch)
        │
        ├── kein gültiger Grund gefunden → Rückkehr, EcuM wartet weiter
        │
        └── gültiger Grund erkannt
                │
                ▼
        7. EthTrcv_CheckWakeup ruft EcuM_SetWakeupEvent(EcuMWakeupSourceType)
           mit der ID auf, die in ARXML über EthTrcvWakeupSourceRef
           mit diesem Transceiver verknüpft ist (siehe Teil 3)
                │
                ▼
        8. EcuM bestätigt: WakeUp validiert → Systemstart läuft normal weiter

Reagiert EthTrcv_CheckWakeup nicht innerhalb von EcuMValidationTimeout, behandelt EcuM den WakeUp als nicht validiert. Je nach Konfiguration fährt das Steuergerät dann sofort wieder herunter — ein "Geisterstart" ohne erkennbaren Grund im Log ist ein klassisches Symptom für ein zu kurzes Validierungsfenster oder einen zu langsamen TC10-Link-Aufbau.

EthTrcv_CheckWakeup wird nicht zwingend nur einmal aufgerufen. Solange sich das Steuergerät im Validierungszyklus befindet, kann die Funktion mehrfach gepollt werden — das ist wichtig, weil TC10-Link-Training nach dem WakeUp-Puls noch einige Millisekunden dauert, bis der WakeUp-Grund im Register stabil steht.

Der WakeUp-Grund: Latching und wann er zurückgesetzt wird

Ein verbreitetes Missverständnis: Es gibt in der Standard-EthTrcv-API keine Funktion, mit der die Applikation den WakeUp-Grund explizit löscht — insbesondere existiert kein EthTrcv_ClearTrcvWakeupReason. Der WakeUp-Grund wird zwar tatsächlich gelatcht (der WakeUp-Interrupt-Handler löscht den Interrupt, ermittelt den Grund und speichert ihn ab), aber das Zurücksetzen dieses internen Zustands ist kein Schritt, den die Applikation selbst auslöst. Er passiert implizit, als Nebenwirkung anderer, ohnehin nötiger Aufrufe.

EreignisAuswirkung auf den gespeicherten WakeUp-Grund

Nächster echter Hardware-WakeUp (Interrupt bzw. nächster Polling-/Async-Check-Zyklus)

Der Interrupt-Handler bzw. EthTrcv_MainFunction ermittelt den neuen Grund und überschreibt den bisher gespeicherten Wert — ohne dass die Applikation etwas löschen muss.

EthTrcv_SetTransceiverMode(ETH_MODE_DOWN) beim Sleep-Übergang

Der Treiber aktiviert die zugehörige ICU-Notification erneut, damit der nächste Hardware-WakeUp überhaupt wieder erkannt werden kann. Bleibt dieser Aufruf aus, bleibt die Erkennung des nächsten WakeUps aus — nicht weil ein alter Grund "hängt", sondern weil die Interrupt-Quelle nie wieder scharf geschaltet wurde.

EthTrcv_Init (Kaltstart, „schlafendes Steuergerät + schlafendes Netzwerk")

Deckt genau den Fall ab, in dem WakeUp-Erkennung schon beim Hochlauf selbst stattfindet, bevor EthTrcv_CheckWakeup überhaupt zum ersten Mal läuft.

EthTrcv_GetBusWuReason / EthTrcv_CheckWakeup aufrufen

Beide lesen den gespeicherten Grund nur; keiner der beiden löscht ihn. Mehrfaches Aufrufen liefert bis zum nächsten echten WakeUp-Ereignis denselben Wert zurück.

Für die Praxis heißt das: Wer im Feld einen Fall beobachtet, in dem ein Steuergerät nie in den Tiefschlaf geht, sucht nicht nach einer fehlenden "Clear"-Funktion — die gibt es nicht —, sondern prüft, ob der Sleep-Übergang tatsächlich per EthTrcv_SetTransceiverMode(ETH_MODE_DOWN) ausgelöst wird. Bleibt dieser Aufruf aus (z. B. weil eine BswM-Regel falsch verdrahtet ist), bleibt die WakeUp-Erkennung für den nächsten Zyklus unscharf — das äußert sich am Symptom ähnlich wie ein "hängender" Grund, die Ursache liegt aber im ausbleibenden Moduswechsel, nicht in einem fehlenden Löschvorgang.

Wenn ein Steuergerät im Feld nie in den Tiefschlaf geht: zuerst prüfen, ob EthTrcv_SetTransceiverMode(ETH_MODE_DOWN) beim Übergang in den Schlafzustand zuverlässig aufgerufen wird — nur dieser Aufruf reaktiviert die WakeUp-Erkennung für den nächsten Zyklus. Stößt man in einem konkreten BSW-Stack auf eine Funktion namens „ClearWakeupReason" o. ä., handelt es sich um eine Vendor-Erweiterung, keinen Bestandteil der AUTOSAR-Standard-API.

Zusammenspiel mit EcuM, ComM und EthSM

WakeUp-Handling ist kein Alleingang des EthTrcv-Treibers — es ist orchestriert.

ModulRolle im WakeUp-Flow

EcuM

Orchestriert System-Start und -Schlaf, verwaltet den Validierungs-Timeout, entscheidet anhand von EcuM_SetWakeupEvent-Aufrufen ob der Systemstart fortgesetzt oder abgebrochen wird.

EthSM

Bus State Manager für Ethernet; leitet EcuM_CheckWakeup-Anfragen an EthTrcv_CheckWakeup weiter und meldet Netzwerkverfügbarkeit nach oben an ComM zurück (siehe nächster Abschnitt).

ComM

Verwaltet Kommunikationskanäle auf Applikationsebene. Fordert über ComM_RequestComMode das Netzwerk an, was EthSM veranlasst den Transceiver über EthTrcv_SetTransceiverMode(ETH_MODE_ACTIVE) zu aktivieren. Nutzt WakeUp-Indikationen zusätzlich für Partial-Networking-Entscheidungen.

CanSM (zum Vergleich)

Kein Bestandteil des Ethernet-Stacks, aber hilfreich als Referenz: EthSM folgt bewusst demselben Bus-State-Manager-Muster wie CanSM. Wer CanSM kennt, erkennt die EthSM-Zustände sofort wieder.

Die ARXML-Verknüpfung zwischen einem EthTrcv-Kanal und seiner EcuM-WakeUp-Quelle (EthTrcvWakeupSourceRef) wurde bereits in Teil 3 behandelt. Genau dieser Parameter bestimmt, welches EcuMWakeupSource-Bit EcuM_SetWakeupEvent in Schritt 7 des Validierungszyklus oben setzt.

EthSM & EthTrcv — wie der State Manager den Transceiver-Zustand koordiniert

EthSM (Ethernet State Manager) ist die Vermittlungsschicht zwischen den Moduswechseln, die ComM auf Applikationsebene anfordert, und dem tatsächlichen Zustand des Transceivers. Vereinfacht dargestellt sieht der Zustandsautomat so aus:

                    ComM fordert Netzwerk an
                              │
        ┌─────────────────────▼─────────────────────┐
        │                 OFFLINE                    │◄────────────┐
        │  EthTrcv im Modus ETH_MODE_DOWN             │              │
        └─────────────────────┬─────────────────────┘              │
                              │ EthTrcv_SetTransceiverMode(ACTIVE)  │
                              ▼                                     │
        ┌─────────────────────────────────────────────┐            │
        │              WAIT_TRCVLINK                   │            │
        │  Transceiver aktiv, wartet auf Link-Up        │            │
        │  (zyklisches Polling/Indication von            │            │
        │   EthTrcv_GetLinkState)                        │            │
        └─────────────────────┬─────────────────────────┘            │
                              │ Link = ETHTRCV_LINK_STATE_ACTIVE      │
                              ▼                                       │
        ┌─────────────────────────────────────────────┐              │
        │                  ONLINE                       │             │
        │  Link steht, EthIf/ComM wird informiert        │             │
        │  (ComM_BusSM_ModeIndication)                   │             │
        └─────────────────────┬─────────────────────────┘             │
                              │ ComM gibt Netzwerk frei /               │
                              │ Link fällt weg                          │
                              ▼                                         │
        ┌─────────────────────────────────────────────┐                │
        │               WAIT_OFFLINE                    │───────────────┘
        │  EthTrcv_SetTransceiverMode(DOWN) angestoßen  │
        └───────────────────────────────────────────────┘

Die exakten Zustandsnamen und Übergänge sind implementierungsabhängig — verschiedene BSW-Stacks benennen sie leicht unterschiedlich. Das Prinzip ist aber stabil: EthSM entkoppelt "ComM will Kommunikation" von "der Link ist tatsächlich da", und genau in dieser Entkopplung steckt die Zeit, in der ein Steuergerät sinnvoll auf Frames warten kann statt sie fälschlich als Fehler zu werten.

Für den Software-Entwickler heißt das konkret: EthSM ruft EthTrcv_SetTransceiverMode und pollt bzw. reagiert auf EthTrcv_GetLinkState — beide APIs, die im Teil 2 dieser Serie bereits im Detail besprochen wurden. Neu in diesem Post ist der Kontext: diese Aufrufe passieren nicht nur einmalig beim Hochlauf, sondern fortlaufend, ausgelöst durch ComM-Modusanforderungen und Link-Zustandsänderungen zur Laufzeit.

Wenn ein Steuergerät zwar bootet, aber nie mit anderen ECUs kommuniziert, obwohl der physische Link laut Oszilloskop steht: als Erstes den EthSM-Zustand prüfen, nicht den EthTrcv-Treiber. Sehr häufig hängt EthSM in WAIT_TRCVLINK fest, weil ComM das Netzwerk aus Applikationssicht nie tatsächlich angefordert hat.

Diagnose & Monitoring

DEM-Fehler: ETHTRCV_E_ACCESS und vendorspezifische Events

Der Standard-Fehlerpfad für den Transceiver läuft über den DEM (Diagnostic Event Manager). Die AUTOSAR-Standard-SWS definiert dafür genau ein produktives DEM-Event: ETHTRCV_E_ACCESS ("Transceiver access failed"). Es wird gemeldet, wenn der Zugriff auf den Transceiver fehlschlägt — konkret über Dem_ReportErrorStatus, sobald das konfigurierte Debounce-Verhalten (zeit- oder zählerbasiert, DemEventParameter) den Fehler bestätigt.

DEM-AspektBedeutung für die Diagnose

Debounce-Zeit

Verhindert, dass ein kurzer Link-Flicker (z. B. während Auto-Negotiation) sofort einen DTC setzt. Zu kurz eingestellt → Fehlalarme beim normalen Verbindungsaufbau; zu lang eingestellt → echte Ausfälle bleiben unbemerkt.

Failure Operation Cycle

Bestimmt, wie viele fehlerhafte Zyklen nötig sind bis der Event als "confirmed" gilt und z. B. ins Fahrzeug-Fehlerspeicherprotokoll geht.

Vendorspezifische Events

PHY-Hersteller erweitern das eine Standard-Event über Complex Device Drivers (CDDs) um granulare Diagnosen: ein Event für einen dauerhaft ausbleibenden Link (z. B. ein herstellerspezifisches „PHY-Down"-Event), Signal Quality Index (SQI), Temperaturwarnungen, MDI-CRC-Fehlerzähler, TC10-Sleep/WakeUp- Fehlschläge.

Die AUTOSAR-Standard-EthTrcv-SWS definiert bewusst nur ein einziges produktives DEM-Event (ETHTRCV_E_ACCESS). Die eigentliche Feindiagnostik — ein dediziertes "Link ist dauerhaft down"-Event, ein numerischer Signal-Quality-Wert statt nur "Link ist down" — kommt fast immer aus Vendor-Erweiterungen. Ein Event-Name wie ETHTRCV_E_PHYDOWN taucht in der Praxis durchaus in realen Projekten auf, ist dann aber eine herstellerspezifische Erweiterung, kein Bestandteil des AUTOSAR-Standards. Wer im Feld nur mit dem einen Standard-Event arbeitet, sieht nur die Spitze des Eisbergs.

Link-State über DET debuggen

Der DET (Development Error Tracer) ist der zweite Diagnosekanal — für Integrationsfehler statt Betriebsfehler. Typische Prüfungen im EthTrcv-Treiber:

ETHTRCV_E_INV_TRCV_IDX     Ungültiger Transceiver-Index (z. B. Off-by-one
                            gegenüber der ARXML-Kanalzuordnung aus Teil 3)
ETHTRCV_E_PARAM_POINTER    NULL-Pointer übergeben, z. B. an
                            EthTrcv_GetLinkState(idx, NULL_PTR)
ETHTRCV_E_INVALID_PARAM    Ungültiger Enum-Wert bei
                            EthTrcv_SetTransceiverMode()
ETHTRCV_E_UNINIT           API-Aufruf vor abgeschlossenem EthTrcv_Init

DET-Checks im Steuergerät für die Integrationsphase aktiv lassen, auch wenn sie im Serien-Build deaktiviert werden. Ein EthTrcv_GetLinkState-Aufruf mit falschem Index läuft ohne DET oft klaglos durch — mit einem stillen, plausibel aussehenden aber falschen Ergebnis. Genau solche Fehler kosten in der Integration am meisten Zeit.

Wenn der gemeldete Link-Zustand nicht zur physischen Realität passt (Kabel steckt, aber ETHTRCV_LINK_STATE_DOWN wird gemeldet, oder umgekehrt), lohnt sich folgende Reihenfolge:

1. DET aktivieren und Log auf ETHTRCV_E_* prüfen
   → Integrationsfehler (falscher Index, NULL-Pointer, API vor Init)?
2. Rückgabewert von EthTrcv_GetLinkState direkt an der Aufrufstelle loggen
   → stimmt der Treiber-interne Zustand mit dem gemeldeten überein?
3. MDIO-Register des PHYs direkt auslesen (nächster Abschnitt)
   → stimmt der Treiber-Zustand mit dem tatsächlichen PHY-Zustand überein?

Diese drei Schritte trennen sauber zwischen Integrationsfehler (Schritt 1), Treiber-/Zustandsfehler (Schritt 2) und tatsächlichem Hardware-/Leitungsproblem (Schritt 3) — und genau in dieser Reihenfolge lohnt es sich sie abzuarbeiten, weil jeder Schritt günstiger ist als der nächste.

MDIO-Register direkt auslesen

Wenn Software-seitige Diagnose an ihre Grenzen stößt, bleibt der Blick auf die PHY-Register selbst — unabhängig davon, was der EthTrcv-Treiber daraus macht.

Wichtig für das Verständnis der Architektur: EthTrcv besitzt den MDIO-Bus nicht selbst. Es ruft synchron EthIf_ReadMii/EthIf_WriteMii auf (aus EthIf.h); EthIf reicht diesen Aufruf laut Spezifikation intern an Eth_ReadMii/Eth_WriteMii des zuständigen Eth-Treibers weiter, der die eigentliche Bus-Transaktion ausführt. Beide EthIf_*Mii-Funktionen sind synchron und liefern das Ergebnis direkt zurück — ein separates Callback-Paar (EthTrcv_ReadMiiIndication/ EthTrcv_WriteMiiIndication) gab es nur bis Release R23-11; es wurde mit R24-11 aus dem Standard gestrichen.

Über eine Vendor-Extension-API:

Viele PHY-Treiber bieten zusätzlich zur Standard-EthTrcv-Schnittstelle nicht-standardisierte Zugriffsfunktionen, die rohe MDIO-Register lesen — etwa EthTrcv_<Vendor>_ReadMdiRegister(). Damit lassen sich Register auslesen, die AUTOSAR selbst nicht kennt:

Register (Clause 22, Adresse 1)   Basic Status Register (BMSR)
  Bit 2   Link Status              1 = Link up (latched low!)
  Bit 5   Auto-Negotiation Complete
  Bit 3   Auto-Negotiation Ability

Vendor-spezifisches Statusregister (Beispiel)
  SQI     Signal Quality Index    0–15, sinkende Werte = Kabel-/EMV-Problem
  TEMP    Temperaturwarnung       gesetzt bei thermischer Überlast
  WU_ST   TC10 WakeUp-Status      letzter WakeUp-Grund (Local/Remote/Reset)

Das Link-Status-Bit im BMSR ist latched low: Es bleibt auf 0, bis es einmal gelesen wurde, selbst wenn der Link zwischenzeitlich wieder steht. Ein einzelner Lesevorgang kann daher einen historischen Link-Drop zeigen, der längst vorbei ist. Für den aktuellen Zustand ist ein zweiter, unmittelbar folgender Lesevorgang nötig.

Über ein externes Diagnose-Tool:

Wenn der Verdacht besteht, dass nicht der Treiber, sondern der PHY selbst oder die Leitung das Problem ist, hilft der Zugriff außerhalb des Software-Stacks: ein MDIO-Adapter am Debug-Interface, oder ein Bench-Setup, das den PHY isoliert vom restlichen Steuergerät ansteuert. Das trennt zuverlässig "Software meldet falschen Zustand" von "Hardware liefert tatsächlich diesen Zustand".

Häufige Laufzeitprobleme und deren Ursachen

PHY kommt nach Reset nicht hoch

UrsacheErkennungsmerkmal

Power-Sequencing-Verletzung (siehe Hardware Deep Dive)

MDIO-Reads liefern durchgehend 0xFFFF oder 0x0000 direkt nach EthTrcv_Init

Strap-Pins falsch beschaltet (PHY-Adresse, Betriebsmodus)

PHY antwortet nicht auf der erwarteten MDIO-Adresse. Diese Hardware-Adresse ist kein eigenständiger EthTrcv-ARXML-Parameter — sie steckt intern in der Eth-Treiber-Implementierung. In ARXML konfiguriert wird stattdessen, welcher Eth-Controller den MII-Zugriff für diesen Transceiver übernimmt (EthTrcvMgmtInterface → EthTrcvMiiInterface → EthTrcvCtrlIdx) und mit welchem Transceiver-Index EthIf für ihn EthIf_ReadMii/EthIf_WriteMii aufruft (EthTrcvMiiIdx) — Symptom sieht aus wie „PHY tot", ist aber ein Adressierungsproblem auf Eth-Ebene

Reset-Zeit zu kurz (RST_N zu früh deasserted)

PHY reagiert auf die ersten paar MDIO-Zugriffe nicht, danach normal — sporadisch reproduzierbar, stark temperaturabhängig

MDC-Takt liegt nicht an oder zu früh an

Kompletter Ausfall aller Register-Zugriffe, nicht nur einzelner

Bevor der Software-Stack verdächtigt wird: Reset-Timing und MDIO-Traffic mit dem Oszilloskop direkt am PHY prüfen. Ein EthTrcv_Init, das laut Rückgabewert erfolgreich durchläuft, sagt nichts darüber aus, ob der PHY die Kommandos tatsächlich empfangen hat — viele MDIO-Schreibzugriffe werden nicht quittiert.

Link bleibt dauerhaft DOWN obwohl Kabel steckt

Das häufigste Laufzeitproblem in der Integrationsphase, mit mehreren möglichen Ursachen die sich leicht verwechseln lassen:

UrsacheErkennungsmerkmal

Master/Slave-Rollenkonflikt (beide Seiten Master oder beide Slave)

Kein Link-Training, BMSR Auto-Negotiation-Complete-Bit bleibt dauerhaft 0 (Details dazu in einem eigenen Vertiefungs-Post, siehe Ausblick)

Falsche EthTrcvSpeed/Duplex-Konfiguration im ARXML

Link kommt kurzzeitig, fällt dann sofort wieder ab — Fehlanpassung zwischen den konfigurierten Fähigkeiten beider Link-Partner

Kabeldämpfung/-länge über Spezifikation

SQI-Wert (falls verfügbar) dauerhaft niedrig, Link-Aufbau braucht ungewöhnlich lange oder scheitert knapp

Fehlender oder defekter Common-Mode-Filter/Steckverbinder

Link funktioniert im Labor mit kurzem Kabel, fällt im Fahrzeugkabelbaum aus (siehe EMV-Abschnitt im Hardware Deep Dive)

EthSM hängt in WAIT_TRCVLINK, weil ComM nie angefordert hat

Physischer Link steht laut Register, aber EthTrcv_SetTransceiverMode(ACTIVE) wurde nie aufgerufen — kein Hardwareproblem, sondern ein Konfigurations- /Applikationsproblem (siehe Abschnitt zu EthSM oben)

Sporadische Link-Drops

Die unangenehmste Kategorie, weil sie im Labor oft nicht reproduzierbar ist:

  • EMV-Einkopplung im Fahrzeugkabelbaum — tritt oft nur bei laufendem Motor oder aktiven Verbrauchern (Zündanlage, DC/DC-Wandler) auf, nicht auf der Werkbank.

  • Marginale Kabellänge/-qualität — funktioniert bei Raumtemperatur, fällt bei Kälte oder Hitze aus, weil sich die Dämpfungsreserve ändert.

  • Thermische Drift des PHYs — SQI sinkt über die Betriebsdauer, bis die Fehlerkorrektur nicht mehr ausreicht; sichtbar nur über Langzeit-Monitoring, nicht über einen einzelnen Snapshot.

  • Debounce-Konfiguration im DEM zu aggressiv — der physische Link erholt sich schneller als die Applikation reagiert, aber ETHTRCV_E_ACCESS (oder ein vendorspezifisches Pendant) wird trotzdem kurz gesetzt und propagiert, weil das Debounce-Fenster zu knapp bemessen ist.

  • Massepotentialschwankungen im Kabelbaum — schwer von einem echten PHY-Defekt zu unterscheiden, zeigt sich meist nur im Fahrzeugverbund, nie am Prüfstand.

Sporadische Link-Drops rein aus Software-Logs zu diagnostizieren führt selten zum Ziel. Ohne kontinuierliches Monitoring von SQI/Fehlerzählern über die Zeit — nicht nur den letzten Link-State — bleibt jede Ursachenanalyse Spekulation.

Fazit & Ausblick

Damit ist die EthTrcv-Kernserie komplett: von den Grundlagen über die API- und Init-Sequenz, die ARXML-Konfiguration bis hin zu WakeUp-Handling und Diagnose.

TeilTitelFokus

1

EthTrcv Teil 1 — Grundlagen & Einordnung

Einordnung von EthTrcv im AUTOSAR-Stack, Abgrenzung zu EthIf/Eth/EthSM

2

EthTrcv Teil 2 — API & Initialisierungssequenz

Kern-APIs, Init-Reihenfolge, Zustandsübergänge

3

EthTrcv Teil 3 — ARXML-Konfiguration in der Praxis

Container, Parameter, typische Konfigurationsfehler

4

EthTrcv Teil 4 — WakeUp-Handling & Diagnose (dieser Post)

WakeUp-Zyklus, EthSM-Koordination, Diagnose & häufige Laufzeitprobleme

Wer tiefer einsteigen will, findet in loser Folge weitere Vertiefungs-Posts zu Themen, die in dieser Kernserie bewusst nur gestreift wurden: Master/Slave-Rollen- aushandlung, Loopback-Tests, MDIO im Detail, gPTP-Zeitsynchronisation, Safety-Aspekte (ASIL-Dekomposition am Transceiver), MACsec und Migrationspfade zwischen PHY-Generationen. Der Hardware Deep Dive zur PHY-Hardwarearchitektur ist bereits online und ein guter nächster Halt für alle, die von der Software-Perspektive dieser Serie zur PCB-Ebene wechseln wollen.

Wer statt eines einzelnen Transceivers eine ganze Switch-Topologie im Fahrzeug betreibt, findet die Fortsetzung im EthSwt — Der AUTOSAR Ethernet Switch Driver — vieles aus dieser Serie (Link-State, DEM/DET-Diagnose, WakeUp-Koordination) taucht dort in komplexerer Form wieder auf, multipliziert über mehrere Ports.

Zusammenfassung

ThemaKernaussage für Software-Entwickler

WakeUp-Quellen

PHY-Pin-WakeUp ist beim Software-Start bereits passiert und muss nur bestätigt werden; In-Band-TC10-WakeUp ist aktiver Bestandteil des Netzwerk-Managements

EthTrcv_CheckWakeup

Läuft im EcuM-Validierungszyklus, muss innerhalb des Timeouts einen Grund via EcuM_SetWakeupEvent bestätigen — sonst wird der Systemstart abgebrochen

WakeUp-Grund zurücksetzen

Es gibt keine dedizierte "Clear"-Funktion in der Standard-API — der gespeicherte Grund wird implizit beim nächsten echten WakeUp überschrieben; entscheidend ist, dass EthTrcv_SetTransceiverMode(ETH_MODE_DOWN) beim Sleep-Übergang zuverlässig aufgerufen wird, damit der Treiber den nächsten WakeUp erkennen kann

EthSM

Entkoppelt ComM-Modusanforderungen vom tatsächlichen Link-Zustand; hängende Zustände sind oft ein Applikations-, kein Hardwareproblem

DEM/DET

ETHTRCV_E_ACCESS ist das einzige DEM-Standard-Event für Betriebsfehler (weitergehende Events wie ein PHY-Down-Indikator sind Vendor-Erweiterungen), DET-Checks decken Integrationsfehler ab — beide Kanäle liefern unterschiedliche, sich ergänzende Information

Laufzeitprobleme

PHY-Startprobleme, dauerhaft toter Link und sporadische Drops haben überlappende, aber unterscheidbare Ursachen — MDIO-Register direkt lesen trennt Software- von Hardwareproblem

Das war die EthTrcv-Kernserie. Weitere Vertiefungs-Posts zu Master/Slave, Loopback, MDIO, gPTP, Safety, MACsec und mehr findest du in der Serienübersicht