Dieser Post baut auf dem vorherigen Post zu Master/Slave auf und wendet sich einem Werkzeug zu, das in kaum einem Produktionswerk fehlt, aber in der Applikationssoftware selten mehr als eine Randnotiz ist: Loopback.

Wer schon einmal ein Steuergerät am Bandende (End-of-Line) getestet hat, kennt das Problem: Es gibt keinen Prüfstand mit echtem Fahrzeugnetzwerk, kein zweites Steuergerät, das antwortet, und keine Zeit für einen vollständigen Integrationstest pro Fahrzeug. Loopback löst genau dieses Problem — und dieser Post zeigt, wie er auf PHY-Ebene funktioniert und wie EthTrcv ihn ansteuert.

Was ist Loopback?

Die Grundidee ist denkbar einfach: Statt einen Frame über das Netzwerk zu senden und auf eine Antwort einer Gegenstelle zu warten, wird das gesendete Signal an irgendeiner Stelle im Übertragungsweg direkt auf den Empfangspfad zurückgespiegelt — ohne dass ein externes Netzwerk oder eine reale Gegenstelle beteiligt ist.

Normalbetrieb:
  ECU A ──sendet Frame──► Kabel ──► ECU B ──sendet Antwort──► Kabel ──► ECU A

Loopback:
  ECU A ──sendet Frame──► [wird intern zurückgespiegelt] ──► ECU A empfängt eigenen Frame

Das klingt trivial, ist aber ausgesprochen nützlich: Wenn ein Frame, der gesendet wurde, unverändert wieder empfangen wird, ist der komplette Pfad zwischen den beiden Loopback-Punkten funktionsfähig — MAC-Interface, PCS, PMA, je nach Loopback-Ebene sogar das Kabel und der Steckverbinder eingeschlossen.

Loopback ist kein AUTOSAR-Feature im engeren Sinn — es ist eine PHY-Fähigkeit, die IEEE 802.3 in mehreren Loopback-Ebenen vorsieht. AUTOSAR bietet lediglich eine (optionale) API, um sie anzusteuern. Viele der interessanten Details liegen deshalb im PHY-Datenblatt, nicht in der ARXML-Spezifikation.

Der entscheidende Unterschied zwischen den Loopback-Ebenen ist, wo im Signalpfad gespiegelt wird. Je näher am Kabel, desto mehr Hardware wird tatsächlich getestet — aber desto mehr kann auch schiefgehen, wenn eine Gegenstelle beteiligt ist.

Drei Loopback-Ebenen im PHY

IEEE 802.3 und die meisten Automotive-PHY-Datenblätter unterscheiden drei Loopback-Ebenen, die sich in Position und Testabdeckung deutlich unterscheiden.

Internal Loopback (Digital Loopback)

Die Spiegelung findet auf der MAC-seitigen Digitallogik des PHY statt — noch bevor das Signal die analogen Sende-Stufen (PMA/PMD) überhaupt erreicht.

        MAC/SoC                         PHY-Chip                      Leitung
   ┌──────────────┐   RGMII/RMII   ┌─────────────────────┐
   │              │───TX──────────►│  PCS  ┄┄┐            │
   │  Ethernet    │                │         ┆ Loopback   │           (kein Signal
   │  MAC         │◄──RX───────────│  PCS  ◄┄┘            │            auf der
   │              │                │                       │            Leitung)
   └──────────────┘                │        PMA/PMD ───────┼──✕───────►
                                    └─────────────────────┘

Der Sendepfad wird nach dem PCS (oder sogar davor) direkt auf den Empfangspfad zurückgeführt. Die analoge Ausgangsstufe, der Line-Driver und die Echo-Cancellation-Logik werden dabei komplett umgangen.

EigenschaftBeschreibung

Getestet wird

MAC-Interface (RGMII/RMII/MII), Framing, PCS-Logik, Teile der digitalen Kette

Nicht getestet

PMA/PMD, Line-Driver, Kabel, Steckverbinder, Echo-Cancellation

Signal auf dem Kabel

Keins — die Leitung bleibt komplett ruhig

Typischer Einsatz

Software-/Treiber-Bring-up, Nachweis dass MAC-PHY-Verbindung korrekt konfiguriert ist

Internal Loopback ist der günstigste, aber auch der am wenigsten aussagekräftige Test. Ein grüner Internal-Loopback-Test beweist nur, dass die digitale Kette zwischen MAC und PHY funktioniert — nicht, dass der PHY überhaupt senden kann.

External Loopback (Analog Loopback / MDI Loopback)

Hier verlässt das Signal tatsächlich den PHY-Chip in Richtung Leitung — und wird direkt am MDI-Anschluss (oder kurz dahinter) elektrisch auf den Empfangspfad zurückgeführt.

        MAC/SoC                         PHY-Chip                      Leitung
   ┌──────────────┐   RGMII/RMII   ┌─────────────────────┐
   │              │───TX──────────►│  PCS ──► PMA/PMD ───┼──► T1+/T1- ──┐
   │  Ethernet    │                │                       │            │
   │  MAC         │◄──RX───────────│  PCS ◄── PMA/PMD ◄───┼── T1+/T1- ◄─┘
   │              │                │                       │      ▲
   └──────────────┘                └─────────────────────┘      Loopback
                                                                (Stecker/MDI)

Die Spiegelung erfolgt entweder durch einen Loopback-Stecker (der T1+/T1- direkt kurzschließt oder mit definierter Impedanz terminiert) oder durch einen analogen Loopback-Modus im PHY selbst, der die MDI-Pins intern verbindet.

EigenschaftBeschreibung

Getestet wird

Vollständiger Sende-/Empfangspfad im PHY inkl. PMA/PMD, teilweise Line-Driver

Nicht getestet

Das eigentliche Kabel zur Gegenstelle, Verhalten der Gegenstelle

Signal auf dem Kabel

Ja — echtes elektrisches Signal am MDI-Anschluss messbar

Typischer Einsatz

Hardware-Bring-up, EOL-Funktionsprüfung des PHY selbst, Oszilloskop-Messungen

External Loopback ist der Modus, den man am Oszilloskop sieht: Weil ein echtes Signal am MDI-Pin anliegt, lässt sich hier auch die Signalqualität (Augen-Diagramm, Amplitude, Jitter) direkt am Steckverbinder messen — ohne dass eine zweite ECU als Signalquelle oder -senke gebraucht wird.

Remote Loopback (PHY-zu-PHY Loopback)

Die dritte Ebene braucht — anders als die ersten beiden — eine echte Gegenstelle. Der PHY am anderen Ende des Kabels spiegelt das empfangene Signal zurück auf die Leitung, ohne es an seine eigene MAC weiterzureichen.

   ECU A (Tester)                              ECU B (Gegenstelle, Remote Loopback aktiv)
   ┌──────────────┐                            ┌──────────────┐
   │  MAC         │                            │  MAC         │
   │   │          │                            │   │          │
   │   ▼          │                            │   ▼          │
   │  PHY A       │                            │  PHY B       │
   │   │ TX ──────┼──── Kabel (T1+/T1-) ───────┼──► RX        │
   │   │          │                            │    │         │
   │   ▼ RX ◄─────┼──── Kabel (T1+/T1-) ◄───────┼──── TX ◄────┘
   │              │                            │  (Signal wird im PHY B
   └──────────────┘                            │   zurückgespiegelt,
                                                │   MAC B bleibt außen vor)
                                                └──────────────┘

ECU A sendet einen Frame, ECU B’s PHY spiegelt das Signal auf PHY-Ebene zurück, ECU A empfängt den eigenen Frame — nun aber über das komplette Kabel inklusive beider Steckverbinder.

EigenschaftBeschreibung

Getestet wird

Gesamter physikalischer Pfad: Kabel, beide Steckverbinder, beide PHYs (analoger Teil)

Nicht getestet

MAC und Software-Stack der Gegenstelle (bewusst umgangen)

Signal auf dem Kabel

Ja — vollständige Übertragungsstrecke wird durchlaufen

Typischer Einsatz

EOL-Kabeltest im Fahrzeug, Verkabelungsprüfung zwischen zwei realen Steuergeräten

Remote Loopback setzt voraus, dass die Gegenstelle den Modus aktiv unterstützt und aktiviert — entweder per MDIO-Kommando von außen (z. B. über einen Diagnose-Tester, der ECU B in Remote Loopback versetzt) oder weil ECU B ihn selbst über ihre eigene EthTrcv-Konfiguration aktiviert hat. Ein PHY, der Remote Loopback nicht unterstützt, lässt sich damit nicht testen.

Die drei Ebenen im Vergleich

KriteriumInternalExternalRemote

Signal verlässt den Chip

Nein

Ja

Ja

Kabel wird getestet

Nein

Nein (nur Stecker/Terminierung)

Ja, vollständig

Gegenstelle nötig

Nein

Nein

Ja

Testet MAC-Interface

Ja

Ja (indirekt)

Ja (indirekt)

Testet PMA/PMD

Nein

Ja

Ja (beide Seiten)

Typischer Anwendungsfall

Software-Bring-up

Hardware-/EOL-Test PHY

EOL-Kabeltest, Feldfehlerdiagnose

AUTOSAR-API

AUTOSAR sieht für Loopback-Funktionalität die Schnittstelle EthTrcv_SetPhyLoopbackMode vor — allerdings mit einer wichtigen Einschränkung:

EthTrcv_SetPhyLoopbackMode ist im AUTOSAR-Standard als vendor-spezifische bzw. optionale API markiert, nicht als verpflichtender Teil der EthTrcv-Schnittstelle. Ob und wie sie implementiert ist, hängt vom jeweiligen EthTrcv-Modul-Hersteller ab. In der Praxis begegnet man drei unterschiedlichen Realisierungen.

Variante 1: Standardisierte Vendor-API

Manche EthTrcv-Implementierungen bilden EthTrcv_SetPhyLoopbackMode direkt ab und kapseln die MDIO-Zugriffe intern:

/* Vendor-Erweiterung, signatur-ähnlich zu EthTrcv_SetPhyTestMode */
Std_ReturnType EthTrcv_SetPhyLoopbackMode(
    uint8 TrcvIdx,
    EthTrcv_PhyLoopbackModeType LoopbackMode
);

/* Reales Enum aus Eth_GeneralTypes.h, SWS_EthTrcv_91004 */
typedef enum {
    ETHTRCV_PHYLOOPBACK_NONE = 0x00,
    ETHTRCV_PHYLOOPBACK_INTERNAL = 0x01,
    ETHTRCV_PHYLOOPBACK_EXTERNAL = 0x02,
    ETHTRCV_PHYLOOPBACK_REMOTE = 0x03
} EthTrcv_PhyLoopbackModeType;

Variante 2: Generische Testmodus-API

Andere Stacks bilden Loopback als Spezialfall eines generischen PHY-Testmodus ab, etwa über EthTrcv_SetPhyTestMode mit einem herstellerspezifischen Modus-Enum. Der Vorteil: eine Schnittstelle für alle PHY-Testfunktionen (Loopback, Testpattern-Generierung, Force-Link). Der Nachteil: weniger Typsicherheit, mehr Dokumentation nötig, um die richtigen Enum-Werte pro PHY zu kennen.

Variante 3: Direkter MDIO-Zugriff über EthIf

Fehlt eine dedizierte Loopback-API, bleibt der direkte Weg über die MDIO-Register des PHY — aber weder EthTrcv noch der Ethernet-Controller-Treiber Eth stellen dafür den Aufrufpunkt, sondern EthIf: EthIf_ReadMii(CtrlIdx, TrcvIdx, RegIdx, RegValPtr) und EthIf_WriteMii(CtrlIdx, TrcvIdx, RegIdx, RegVal) (aus EthIf.h) sind laut Spezifikation die Funktionen, die EthTrcv aufruft. EthIf ist dabei nur Vermittler: Es leitet den Aufruf intern an Eth_ReadMii/Eth_WriteMii des zuständigen Eth-Treibers weiter — dort passiert die eigentliche MDIO-Transaktion. Beide EthIf_*Mii-Funktionen sind ausdrücklich synchron spezifiziert und liefern das Ergebnis direkt als Std_ReturnType zurück; ein separater Rückruf ist nicht nötig.

Ältere AUTOSAR-Releases (bis R23-11) kannten für dieselbe Aufgabe ein asynchrones Callback-Paar EthTrcv_ReadMiiIndication/EthTrcv_WriteMiiIndication. Beide wurden mit Release R24-11 aus dem Standard gestrichen — in der aktuellen Spezifikation (R25-11) existieren sie nicht mehr.

/* Beispiel: Loopback-Bit im Standard-Register 0.0 (Basic Control Register),
   Bit 14, gemäß IEEE 802.3 Clause 22.
   Der Bus-Zugriff läuft synchron über EthIf_ReadMii/EthIf_WriteMii; EthIf
   reicht das intern an den zuständigen Eth-Treiber weiter. */
#define PHY_BCR_REG_ADDR      0x00u
#define PHY_BCR_LOOPBACK_BIT  (1u << 14)

Std_ReturnType Phy_EnableInternalLoopback(uint8 CtrlIdx, uint8 TrcvIdx)
{
    uint16 bcrValue;
    Std_ReturnType result;

    /* 1. Aktuellen Registerwert lesen (blockiert bis zum Abschluss) */
    result = EthIf_ReadMii(CtrlIdx, TrcvIdx, PHY_BCR_REG_ADDR, &bcrValue);
    if (result != E_OK)
    {
        return result;
    }

    /* 2. Loopback-Bit setzen und zurückschreiben */
    bcrValue |= PHY_BCR_LOOPBACK_BIT;
    return EthIf_WriteMii(CtrlIdx, TrcvIdx, PHY_BCR_REG_ADDR, bcrValue);
}

Das Loopback-Bit in Register 0.0 ist IEEE-802.3-Standard und aktiviert bei den meisten PHYs den Internal Loopback. Für External und Remote Loopback gibt es kein standardisiertes Register — hier muss ins Vendor-spezifische Registerblatt geschaut werden (siehe der Post zu MDIO und PHY-Registern).

Anwendungsfälle

EOL-Test in der Fahrzeugproduktion

Am Bandende hat ein Werk Sekunden, nicht Minuten, um ein Steuergerät zu prüfen. Ein vollständiger Netzwerk-Integrationstest mit allen Kommunikationspartnern ist am Band schlicht nicht praktikabel. Loopback-Tests lösen das:

1. EOL-Tester sendet Diagnose-Kommando: "Aktiviere Remote Loopback auf ECU B"
2. ECU B (Prüfling) versetzt seinen EthTrcv in ETHTRCV_PHYLOOPBACK_REMOTE
3. EOL-Tester (oder ECU A) sendet Testframes über das reale Fahrzeugkabel
4. Testframes kommen unverändert zurück → Kabel + Stecker + beide PHYs OK
5. ECU B verlässt Remote Loopback, EOL-Test wird als "PASS" protokolliert

Das prüft in einem einzigen Schritt genau die Hardware, die im Feld am häufigsten Probleme macht: Kabel, Crimp-Kontakte und Steckverbinder.

Kabel- und Steckerprüfung

Unabhängig vom EOL-Kontext: External und Remote Loopback sind die Standardwerkzeuge, um bei einem Verdacht auf Kabel- oder Steckerproblem schnell einzugrenzen, ohne das Fahrzeug zu zerlegen.

Ein einfacher, aber wirksamer Diagnose-Trick: External Loopback direkt am Steckverbinder der ECU (mit Loopback-Stecker) gibt Auskunft über den PHY. Kommt das Signal dort sauber zurück, aber Remote Loopback über das volle Kabel schlägt fehl, liegt der Fehler mit hoher Wahrscheinlichkeit im Kabel oder in einem der beiden Steckverbinder — nicht im PHY selbst.

Fehlereingrenzung — Stack-Problem oder Hardware-Problem?

Die vielleicht unterschätzte Stärke von Loopback-Tests: Sie trennen Software-/Stack-Fehler von Hardware-Fehlern. Wenn ein Kommunikationsproblem auftritt, ist die erste Frage immer: Liegt es am Protokollstack (Com, PduR, Socket-Adapter, …​) oder an der Hardware darunter?

Beobachtung: Frames kommen bei ECU B nicht an

Schritt 1 — Internal Loopback auf ECU A:
   Frame kommt zurück?  → MAC/PHY-Anbindung auf ECU A ist grundsätzlich OK
   Frame kommt nicht zurück? → Fehler liegt zwischen MAC und PHY (Treiber,
                                Interface-Konfiguration, RGMII-Timing)

Schritt 2 — External Loopback auf ECU A:
   Frame kommt zurück?  → PHY sendet und empfängt korrekt, Line-Driver OK
   Frame kommt nicht zurück? → PHY-Defekt oder falsche PHY-Konfiguration

Schritt 3 — Remote Loopback über das reale Kabel:
   Frame kommt zurück?  → Kabel, Stecker und PHY B (analog) sind OK
                           → das ursprüngliche Problem liegt im Software-Stack
                             von ECU B, nicht in der Hardware
   Frame kommt nicht zurück? → Kabel-, Stecker- oder PHY-B-Problem bestätigt

Diese Kette von innen nach außen — Internal, External, Remote — ist der Standardablauf, um in wenigen Minuten zu wissen, in welcher Schicht ein Fehler zu suchen ist, bevor man mit dem Debugger tiefer in den Stack einsteigt.

Codebeispiel — Loopback aktivieren, Paket senden, Ergebnis prüfen

Das folgende Beispiel zeigt einen vollständigen Internal-Loopback-Selbsttest, wie er etwa in einer Power-On-Self-Test-Routine oder einem Diagnose-Job verwendet werden könnte.

#include "EthTrcv.h"
#include "EthIf.h"

#define LOOPBACK_TEST_PATTERN   0xA5u
#define LOOPBACK_TEST_LEN       64u
#define LOOPBACK_TIMEOUT_MS     50u

typedef enum {
    LOOPBACK_TEST_OK,
    LOOPBACK_TEST_TIMEOUT,
    LOOPBACK_TEST_DATA_MISMATCH,
    LOOPBACK_TEST_MODE_NOT_SET
} LoopbackTestResultType;

static boolean s_loopbackFrameReceived = FALSE;
static uint8   s_loopbackRxBuffer[LOOPBACK_TEST_LEN];

/* Wird vom EthIf/Stack aufgerufen, sobald ein Frame empfangen wurde */
void LoopbackTest_RxIndication(uint8 CtrlIdx, Eth_FrameType FrameType,
                                boolean IsBroadcast, const uint8* PhysAddrPtr,
                                const uint8* DataPtr, uint16 LenByte)
{
    if (LenByte == LOOPBACK_TEST_LEN)
    {
        memcpy(s_loopbackRxBuffer, DataPtr, LOOPBACK_TEST_LEN);
        s_loopbackFrameReceived = TRUE;
    }
}

LoopbackTestResultType LoopbackTest_RunInternal(uint8 TrcvIdx, uint8 CtrlIdx)
{
    Std_ReturnType   ret;
    uint8            txBuffer[LOOPBACK_TEST_LEN];
    Eth_BufIdxType   bufIdx;
    uint8*           txDataPtr;
    uint16           bufLen = LOOPBACK_TEST_LEN;
    uint32           waited = 0u;

    /* 1. Internal Loopback aktivieren */
    ret = EthTrcv_SetPhyLoopbackMode(TrcvIdx, ETHTRCV_PHYLOOPBACK_INTERNAL);
    if (ret != E_OK)
    {
        return LOOPBACK_TEST_MODE_NOT_SET;
    }

    /* 2. Testframe vorbereiten und senden */
    memset(txBuffer, LOOPBACK_TEST_PATTERN, LOOPBACK_TEST_LEN);
    s_loopbackFrameReceived = FALSE;

    ret = EthIf_ProvideTxBuffer(CtrlIdx, ETH_PRIO_TC0, ETHIF_TX_BUFFER_ANY,
                                 &bufIdx, &txDataPtr, &bufLen);
    if (ret == BUFREQ_OK)
    {
        memcpy(txDataPtr, txBuffer, LOOPBACK_TEST_LEN);
        (void)EthIf_Transmit(CtrlIdx, bufIdx, ETH_FRAME_TYPE_LOOPBACK_TEST,
                              TRUE, LOOPBACK_TEST_LEN, s_loopbackOwnAddr);
    }

    /* 3. Auf Empfang des eigenen Frames warten (gepollt oder Task-Kontext) */
    while ((s_loopbackFrameReceived == FALSE) && (waited < LOOPBACK_TIMEOUT_MS))
    {
        EthIf_MainFunctionRx(CtrlIdx);
        Delay_1ms();
        waited++;
    }

    if (s_loopbackFrameReceived == FALSE)
    {
        (void)EthTrcv_SetPhyLoopbackMode(TrcvIdx, ETHTRCV_PHYLOOPBACK_NONE);
        return LOOPBACK_TEST_TIMEOUT;
    }

    /* 4. Empfangene Daten mit gesendeten Daten vergleichen */
    if (memcmp(txBuffer, s_loopbackRxBuffer, LOOPBACK_TEST_LEN) != 0)
    {
        (void)EthTrcv_SetPhyLoopbackMode(TrcvIdx, ETHTRCV_PHYLOOPBACK_NONE);
        return LOOPBACK_TEST_DATA_MISMATCH;
    }

    /* 5. Loopback wieder deaktivieren — nicht vergessen! */
    (void)EthTrcv_SetPhyLoopbackMode(TrcvIdx, ETHTRCV_PHYLOOPBACK_NONE);

    return LOOPBACK_TEST_OK;
}

Schritt 5 im Beispiel ist kein Detail, sondern der häufigste Bug in Loopback-Testroutinen: Wird der Loopback-Modus nach dem Test nicht wieder deaktiviert, bleibt die ECU danach vom Netzwerk isoliert — sie "spricht" nur noch mit sich selbst. Ein vergessenes ETHTRCV_PHYLOOPBACK_NONE nach einem Diagnose-Job ist ein klassischer Grund für "ECU antwortet plötzlich nicht mehr", der sich erst nach einem Power-Cycle von selbst löst.

Grenzen — was Loopback nicht kann

So nützlich Loopback-Tests sind, sie haben klare Grenzen, die man kennen sollte, bevor man sich zu sehr auf ein "PASS" verlässt.

GrenzeErklärung

Verdeckt echte PHY-Defekte

Loopback testet Sende- und Empfangspfad gemeinsam. Ein PHY, dessen Sender zu schwach und dessen Empfänger zu unempfindlich ist, kann sich im Loopback trotzdem "gesund" rechnen, wenn sich beide Fehler im Test kompensieren. Ein separater Test mit einer echten, unabhängigen Gegenstelle deckt das auf.

Keine Aussage über EMV-Verhalten

Ein Kabel kann im Loopback perfekt funktionieren und trotzdem im EMV-Test durchfallen, weil Störabstrahlung und Störfestigkeit andere Fehlermechanismen sind als reine Signalübertragung.

Keine Aussage über Timing unter Last

Loopback-Tests laufen typischerweise mit wenig Verkehr und ohne Netzwerklast durch andere Teilnehmer. Sie sagen nichts über Verhalten bei voller Bus-Auslastung, Kollisionen im Switch oder Priorisierungsfehlern.

Remote Loopback verdeckt Softwarefehler der Gegenstelle

Per Definition wird die MAC/Software-Schicht der Gegenstelle umgangen. Ein "PASS" im Remote Loopback sagt nichts darüber, ob der Protokollstack der Gegenstelle überhaupt funktionsfähig ist.

Kein Ersatz für Konformitätstests

IEEE-802.3-Konformität (Augen-Diagramm, Return Loss, Jitter-Toleranz) erfordert kalibrierte Messtechnik. Ein bestandener Loopback-Test ist ein guter Indikator, aber kein Zertifikat.

Loopback-Tests sind ein Schnelltest, keine vollständige Verifikation. Sie gehören in die Produktionslinie und in die Fehlereingrenzung — nicht als Ersatz für Hardware-Validierung, EMV-Prüfung oder Feldtests mit echten Kommunikationspartnern.

Zusammenfassung

ThemaKernaussage für Software-Entwickler

Internal Loopback

Testet nur die digitale Kette MAC↔PHY, kein Signal auf dem Kabel — günstig, aber wenig aussagekräftig

External Loopback

Testet den analogen PHY-Pfad bis zum Steckverbinder — Standard für PHY-Hardwaretests

Remote Loopback

Testet die komplette physikalische Strecke inkl. Kabel und beider Steckverbinder — braucht eine kooperierende Gegenstelle

AUTOSAR-API

EthTrcv_SetPhyLoopbackMode ist vendor-spezifisch/optional; ohne sie führt der Weg synchron über EthIf_ReadMii/EthIf_WriteMii, die EthIf intern an Eth_ReadMii/Eth_WriteMii weiterreicht

Anwendungsfälle

EOL-Test am Band, Kabel-/Steckerdiagnose, systematische Fehlereingrenzung Software vs. Hardware

Grenzen

Kann sich kompensierende PHY-Defekte verdecken, sagt nichts über EMV, Last oder Software der Gegenstelle

Weiter in der EthTrcv-Serie: EthTrcv — MDIO-Zugriff und PHY-Register direkt lesen