This post builds on the previous post on Master/Slave and turns to a tool that is missing from almost no production plant, yet rarely gets more than a footnote in application software: loopback.

Anyone who has tested an ECU at end-of-line knows the problem: there is no test bench with a real vehicle network, no second ECU that responds, and no time for a full integration test per vehicle. Loopback solves exactly this problem — and this post shows how it works at the PHY level and how EthTrcv drives it.

What Is Loopback?

The basic idea is disarmingly simple: instead of sending a frame over the network and waiting for a response from a peer, the transmitted signal is mirrored directly back onto the receive path at some point in the transmission chain — without any external network or real peer involved.

Normal operation:
  ECU A ──sends frame──► cable ──► ECU B ──sends reply──► cable ──► ECU A

Loopback:
  ECU A ──sends frame──► [mirrored back internally] ──► ECU A receives its own frame

That sounds trivial, but it is remarkably useful: if a frame that was sent comes back unchanged, the entire path between the two loopback points is functional — the MAC interface, PCS, PMA, and, depending on the loopback level, even the cable and the connector.

Loopback is not an AUTOSAR feature in the strict sense — it is a PHY capability that IEEE 802.3 provides in several loopback levels. AUTOSAR merely offers an (optional) API to control it. Many of the interesting details therefore live in the PHY datasheet, not in the ARXML specification.

The decisive difference between the loopback levels is where in the signal path the mirroring happens. The closer to the cable, the more hardware actually gets exercised — but the more can also go wrong once a peer is involved.

Three Loopback Levels in the PHY

IEEE 802.3 and most automotive PHY datasheets distinguish three loopback levels, which differ significantly in position and test coverage.

Internal Loopback (Digital Loopback)

The mirroring happens in the MAC-side digital logic of the PHY — before the signal ever reaches the analog transmit stages (PMA/PMD).

        MAC/SoC                          PHY chip                      Cable
   ┌──────────────┐   RGMII/RMII   ┌─────────────────────┐
   │              │───TX──────────►│  PCS  ┄┄┐            │
   │  Ethernet    │                │         ┆ Loopback   │           (no signal
   │  MAC         │◄──RX───────────│  PCS  ◄┄┘            │            on the
   │              │                │                       │            cable)
   └──────────────┘                │        PMA/PMD ───────┼──✕───────►
                                    └─────────────────────┘

The transmit path is fed straight back into the receive path after the PCS (or even before it). The analog output stage, the line driver, and the echo-cancellation logic are all bypassed entirely.

PropertyDescription

Tested

MAC interface (RGMII/RMII/MII), framing, PCS logic, parts of the digital chain

Not tested

PMA/PMD, line driver, cable, connector, echo cancellation

Signal on the cable

None — the line stays completely quiet

Typical use

Software/driver bring-up, proof that the MAC-PHY connection is configured correctly

Internal loopback is the cheapest test but also the least conclusive one. A passing internal loopback test only proves that the digital chain between MAC and PHY works — not that the PHY can transmit at all.

External Loopback (Analog Loopback / MDI Loopback)

Here the signal actually leaves the PHY chip toward the cable — and is mirrored electrically back onto the receive path directly at the MDI connector (or just behind it).

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

The mirroring happens either through a loopback connector (which shorts T1+/T1- directly or terminates them with a defined impedance) or through an analog loopback mode inside the PHY that internally ties the MDI pins together.

PropertyDescription

Tested

Full transmit/receive path inside the PHY, including PMA/PMD, partly the line driver

Not tested

The actual cable to the peer, behavior of the peer

Signal on the cable

Yes — a real electrical signal is measurable at the MDI connector

Typical use

Hardware bring-up, end-of-line functional test of the PHY itself, oscilloscope measurements

External loopback is the mode you see on an oscilloscope: because a real signal is present at the MDI pin, signal quality (eye diagram, amplitude, jitter) can be measured directly at the connector — no second ECU needed as a signal source or sink.

Remote Loopback (PHY-to-PHY Loopback)

The third level, unlike the first two, requires an actual peer. The PHY at the other end of the cable mirrors the received signal back onto the line without ever handing it up to its own MAC.

   ECU A (tester)                               ECU B (peer, remote loopback active)
   ┌──────────────┐                            ┌──────────────┐
   │  MAC         │                            │  MAC         │
   │   │          │                            │   │          │
   │   ▼          │                            │   ▼          │
   │  PHY A       │                            │  PHY B       │
   │   │ TX ──────┼──── cable (T1+/T1-) ───────┼──► RX        │
   │   │          │                            │    │         │
   │   ▼ RX ◄─────┼──── cable (T1+/T1-) ◄───────┼──── TX ◄────┘
   │              │                            │  (signal mirrored
   └──────────────┘                            │   inside PHY B,
                                                │   MAC B never sees it)
                                                └──────────────┘

ECU A sends a frame, ECU B’s PHY mirrors the signal back at the PHY level, and ECU A receives its own frame — but now over the complete cable including both connectors.

PropertyDescription

Tested

Entire physical path: cable, both connectors, both PHYs (analog part)

Not tested

MAC and software stack of the peer (deliberately bypassed)

Signal on the cable

Yes — the full transmission link is exercised

Typical use

End-of-line cable test in the vehicle, wiring verification between two real ECUs

Remote loopback requires the peer to actively support and enable the mode — either via an external MDIO command (e.g. a diagnostic tester that puts ECU B into remote loopback) or because ECU B enabled it itself through its own EthTrcv configuration. A PHY that does not support remote loopback simply cannot be tested this way.

The Three Levels Compared

CriterionInternalExternalRemote

Signal leaves the chip

No

Yes

Yes

Cable is tested

No

No (connector/termination only)

Yes, fully

Peer required

No

No

Yes

Tests MAC interface

Yes

Yes (indirectly)

Yes (indirectly)

Tests PMA/PMD

No

Yes

Yes (both sides)

Typical use case

Software bring-up

Hardware/EOL test of the PHY

EOL cable test, field fault diagnosis

The AUTOSAR API

AUTOSAR provides EthTrcv_SetPhyLoopbackMode for loopback functionality — but with an important caveat:

EthTrcv_SetPhyLoopbackMode is marked in the AUTOSAR standard as a vendor-specific / optional API, not as a mandatory part of the EthTrcv interface. Whether and how it is implemented depends on the specific EthTrcv module vendor. In practice you encounter three different realizations.

Variant 1: Standardized Vendor API

Some EthTrcv implementations map EthTrcv_SetPhyLoopbackMode directly and encapsulate the MDIO access internally:

/* Vendor extension, signature similar to EthTrcv_SetPhyTestMode */
Std_ReturnType EthTrcv_SetPhyLoopbackMode(
    uint8 TrcvIdx,
    EthTrcv_PhyLoopbackModeType LoopbackMode
);

/* Real enum from 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;

Variant 2: Generic Test-Mode API

Other stacks model loopback as a special case of a generic PHY test mode, for instance via EthTrcv_SetPhyTestMode with a vendor-specific mode enum. The advantage: one interface for all PHY test functions (loopback, test pattern generation, force link). The downside: less type safety, and more documentation needed to know the correct enum values per PHY.

Variant 3: Direct MDIO Access via EthIf

If there is no dedicated loopback API, the direct route is through the PHY’s MDIO registers — but neither EthTrcv nor the Ethernet Controller Driver Eth is the entry point for that; it’s EthIf. EthIf_ReadMii(CtrlIdx, TrcvIdx, RegIdx, RegValPtr) and EthIf_WriteMii(CtrlIdx, TrcvIdx, RegIdx, RegVal) (from EthIf.h) are, per the spec, the functions EthTrcv actually calls. EthIf is only a broker here: it forwards the call internally to Eth_ReadMii/Eth_WriteMii of the responsible Eth driver, where the actual MDIO transaction happens. Both EthIf_*Mii functions are explicitly specified as synchronous and return the result directly as Std_ReturnType — no separate callback is needed.

Earlier AUTOSAR releases (up through R23-11) used an asynchronous callback pair, EthTrcv_ReadMiiIndication/EthTrcv_WriteMiiIndication, for the same job. Both were removed from the standard as of R24-11 — they no longer exist in the current spec (R25-11).

/* Example: loopback bit in the standard register 0.0 (Basic Control Register),
   bit 14, per IEEE 802.3 Clause 22.
   The bus access goes through EthIf_ReadMii/EthIf_WriteMii, synchronously;
   EthIf forwards it internally to the responsible Eth driver. */
#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. Read the current register value (blocks until complete) */
    result = EthIf_ReadMii(CtrlIdx, TrcvIdx, PHY_BCR_REG_ADDR, &bcrValue);
    if (result != E_OK)
    {
        return result;
    }

    /* 2. Set the loopback bit and write it back */
    bcrValue |= PHY_BCR_LOOPBACK_BIT;
    return EthIf_WriteMii(CtrlIdx, TrcvIdx, PHY_BCR_REG_ADDR, bcrValue);
}

The loopback bit in register 0.0 is IEEE 802.3 standard and, on most PHYs, enables internal loopback. There is no standardized register for external or remote loopback — for those you need to consult the vendor-specific register map (see the post on MDIO and PHY registers).

Use Cases

End-of-Line Testing in Vehicle Production

At the end of the production line, a plant has seconds, not minutes, to verify an ECU. A full network integration test with every communication partner simply is not practical on the line. Loopback tests solve this:

1. EOL tester sends a diagnostic command: "Enable remote loopback on ECU B"
2. ECU B (device under test) puts its EthTrcv into ETHTRCV_PHYLOOPBACK_REMOTE
3. EOL tester (or ECU A) sends test frames over the real vehicle cable
4. Test frames come back unchanged → cable + connectors + both PHYs OK
5. ECU B exits remote loopback, EOL test is logged as "PASS"

In a single step this exercises exactly the hardware that causes the most problems in the field: cables, crimp contacts, and connectors.

Cable and Connector Verification

Independent of the EOL context: external and remote loopback are the standard tools for quickly narrowing down a suspected cable or connector problem without tearing the vehicle apart.

A simple but effective diagnostic trick: external loopback right at the ECU connector (using a loopback plug) tells you about the PHY. If the signal comes back clean there but remote loopback over the full cable fails, the fault is very likely in the cable or in one of the two connectors — not in the PHY itself.

Fault Isolation — Stack Problem or Hardware Problem?

Perhaps the most underrated strength of loopback tests: they separate software/stack faults from hardware faults. When a communication problem occurs, the first question is always: is it the protocol stack (Com, PduR, socket adapter, …​) or the hardware underneath it?

Observation: frames are not arriving at ECU B

Step 1 — internal loopback on ECU A:
   Frame comes back?     → MAC/PHY connection on ECU A is fundamentally OK
   Frame does not come back? → fault is between MAC and PHY (driver,
                                interface configuration, RGMII timing)

Step 2 — external loopback on ECU A:
   Frame comes back?     → PHY transmits and receives correctly, line driver OK
   Frame does not come back? → PHY defect or incorrect PHY configuration

Step 3 — remote loopback over the real cable:
   Frame comes back?     → cable, connectors, and PHY B (analog side) are OK
                            → the original problem is in ECU B's software
                              stack, not in the hardware
   Frame does not come back? → cable, connector, or PHY B problem confirmed

This inside-out chain — internal, external, remote — is the standard procedure to know within minutes which layer to search for a fault in, before diving deeper into the stack with a debugger.

Code Example — Enable Loopback, Send a Packet, Check the Result

The following example shows a complete internal loopback self-test, the kind you might find in a power-on self-test routine or a diagnostic job.

#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];

/* Called by the EthIf/stack as soon as a frame has been received */
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. Enable internal loopback */
    ret = EthTrcv_SetPhyLoopbackMode(TrcvIdx, ETHTRCV_PHYLOOPBACK_INTERNAL);
    if (ret != E_OK)
    {
        return LOOPBACK_TEST_MODE_NOT_SET;
    }

    /* 2. Prepare and send a test frame */
    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. Wait for the frame to come back (polled or task context) */
    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. Compare received data against sent data */
    if (memcmp(txBuffer, s_loopbackRxBuffer, LOOPBACK_TEST_LEN) != 0)
    {
        (void)EthTrcv_SetPhyLoopbackMode(TrcvIdx, ETHTRCV_PHYLOOPBACK_NONE);
        return LOOPBACK_TEST_DATA_MISMATCH;
    }

    /* 5. Disable loopback again — do not forget this! */
    (void)EthTrcv_SetPhyLoopbackMode(TrcvIdx, ETHTRCV_PHYLOOPBACK_NONE);

    return LOOPBACK_TEST_OK;
}

Step 5 in the example is not a minor detail — it is the most common bug in loopback test routines. If the loopback mode is not disabled again after the test, the ECU is left isolated from the network afterward: it only "talks" to itself. A forgotten ETHTRCV_PHYLOOPBACK_NONE after a diagnostic job is a classic root cause of "ECU suddenly stops responding" that only resolves itself after a power cycle.

Limits — What Loopback Cannot Do

As useful as loopback tests are, they have clear limits that you should know before trusting a "PASS" too much.

LimitExplanation

Can hide a real PHY defect

Loopback tests transmit and receive path together. A PHY whose transmitter is too weak and whose receiver is too insensitive can still come out "healthy" in loopback if both faults cancel each other out in the test. A separate test with a real, independent peer exposes this.

Says nothing about EMC behavior

A cable can work perfectly in loopback and still fail an EMC test, because emission and immunity are different failure mechanisms than pure signal transmission.

Says nothing about timing under load

Loopback tests typically run with little traffic and no network load from other nodes. They say nothing about behavior under full bus utilization, switch collisions, or prioritization errors.

Remote loopback hides software faults on the peer

By definition, the peer’s MAC/software layer is bypassed. A "PASS" in remote loopback says nothing about whether the peer’s protocol stack is even functional.

Not a substitute for conformance testing

IEEE 802.3 conformance (eye diagram, return loss, jitter tolerance) requires calibrated measurement equipment. A passing loopback test is a good indicator, but not a certificate.

Loopback tests are a quick check, not a full verification. They belong on the production line and in fault isolation — not as a replacement for hardware validation, EMC testing, or field tests with real communication partners.

Summary

TopicKey takeaway for software developers

Internal loopback

Tests only the digital chain MAC↔PHY, no signal on the cable — cheap but not very conclusive

External loopback

Tests the analog PHY path up to the connector — the standard for PHY hardware tests

Remote loopback

Tests the entire physical link including cable and both connectors — needs a cooperating peer

AUTOSAR API

EthTrcv_SetPhyLoopbackMode is vendor-specific/optional; without it, use EthIf_ReadMii/EthIf_WriteMii synchronously, which EthIf forwards internally to Eth_ReadMii/Eth_WriteMii

Use cases

End-of-line testing, cable/connector diagnostics, systematic fault isolation of software vs. hardware

Limits

Can hide compensating PHY defects, says nothing about EMC, load, or the peer’s software

Next in the EthTrcv series: EthTrcv — Direct MDIO Access and Reading PHY Registers