EthTrcv Part 4 — WakeUp Handling & Diagnostics

This post builds on EthTrcv Part 3 — ARXML Configuration in Practice. That post covered how an EthTrcv module comes together from ARXML parameters. By now the ECU is configured, initialized, and running — but an Ethernet-capable ECU spends a considerable part of its life not in active operation, but asleep, waking up, or handling faults.

This fourth and final part of the core series closes exactly that gap: how an ECU wakes up over Ethernet, how EthSM coordinates the transceiver state with the rest of the system, and how you as a developer figure out why the link isn’t doing what it should.

WakeUp Handling

Ethernet WakeUp is fundamentally different from a CAN WakeUp. For CAN, a single dominant edge on the bus is often enough in the simplest case. Behind a single-pair Ethernet PHY sits an actual protocol — and that’s exactly what makes the software side more interesting than it first appears.

WakeUp Sources: PHY Pin and In-Band Signal

Two physically distinct mechanisms can trigger an EthTrcv WakeUp.

1. PHY pin (WU pin, local/asynchronous)

The WU pin was already covered in the Hardware Deep Dive: an external pulse on this pin causes the PHY to assert INH, starting the ECU’s voltage regulator — long before any software is even running. This matters for EthTrcv_CheckWakeup because the reason for this already-occurred hardware wakeup still has to be confirmed in software afterward.

2. In-band WakeUp signal (100BASE-T1 sleep/wake per OPEN Alliance TC10)

Automotive 100BASE-T1 PHYs typically implement the TC10 sleep/wake protocol. A PHY that wants to wake up another ECU sends a defined sequence of wake pulses directly over the data pair — no separate pin, no extra wiring.

Sender PHY (already active)              Receiver PHY (asleep)
     │                                        │
     │── Wake_Pulse ──────────────────────────►│
     │   (defined pulse sequence on T1+/T1-)   │  PHY detects pattern
     │                                          │  → asserts INH locally
     │                                          │  → voltage regulator starts
     │◄── Link training / auto-neg ────────────►│
     │                                          │  ECU boots, EcuM starts

TC10 distinguishes between a local wake request (this ECU wants to wake up its link partner, triggered by calling EthTrcv_SetTransceiverMode(ETH_MODE_ACTIVE_WITH_WAKEUP_REQUEST)) and a remote wakeup (this ECU is being woken by another one). Both cases ultimately run through the same EthTrcv_CheckWakeup evaluation, or the reason delivered via EthTrcv_GetBusWuReason, but the wakeup reason differs — relevant for the diagnostics discussed later in this post.

The key difference for the software developer: the PHY-pin wakeup has already "happened" by the time software first runs — it only needs to be confirmed. The in-band signal, on the other hand, can be actively requested by software ("wake up the rest of the ECUs on this segment") and is part of ordinary network management, not just a boot-time event.

EthTrcv_CheckWakeup — Flow Inside the EcuM WakeUp Validation Cycle

A hardware wakeup alone is not enough for EcuM. AUTOSAR requires a software-side wakeup validation: a wakeup reason must be confirmed within a configured time window (EcuMValidationTimeout), otherwise it is treated as noise (e.g. EMC coupling) and the ECU falls back to sleep.

 1. Hardware wakeup (WU pin or TC10 pulse) → INH asserted → SoC boots
 2. EcuM starts, recognizes a configured wakeup source requiring validation
 3. EcuM enters the wakeup validation cycle
        │
        ▼
 4. EcuM calls EcuM_CheckWakeup() cyclically (or ISR-driven)
        │
        ▼
 5. Dispatch through EthSM to the driver:
        EthSM_CheckWakeup() → EthTrcv_CheckWakeup(TrcvIdx)
        │
        ▼
 6. EthTrcv_CheckWakeup reads the PHY's wakeup status
    (TC10 wakeup status register or WU-pin latch)
        │
        ├── no valid reason found → returns, EcuM keeps waiting
        │
        └── valid reason detected
                │
                ▼
        7. EthTrcv_CheckWakeup calls EcuM_SetWakeupEvent(EcuMWakeupSourceType)
           with the ID linked to this transceiver via EthTrcvWakeupSourceRef
           in ARXML (see Part 3)
                │
                ▼
        8. EcuM confirms: wakeup validated → startup proceeds normally

If EthTrcv_CheckWakeup doesn’t respond within EcuMValidationTimeout, EcuM treats the wakeup as unvalidated. Depending on configuration, the ECU may shut down again immediately — a "ghost boot" with no discernible reason in the log is a classic symptom of a validation window that’s too short, or a TC10 link that comes up too slowly.

EthTrcv_CheckWakeup isn’t necessarily called just once. As long as the ECU is in the validation cycle, the function can be polled multiple times — important because TC10 link training after the wake pulse still takes a few milliseconds before the wakeup reason settles in the register.

The Wakeup Reason: Latching and When It Gets Reset

A common misconception: the standard EthTrcv API has no function that lets the application explicitly clear the wakeup reason — in particular, there is no EthTrcv_ClearTrcvWakeupReason. The wakeup reason genuinely is latched (the wakeup interrupt handler clears the interrupt, identifies the reason, and stores it), but resetting that internal state is not a step the application triggers itself. It happens implicitly, as a side effect of other calls the driver already needs to make.

Event Effect on the stored wakeup reason

Event	Effect on the stored wakeup reason
Next real hardware wakeup (interrupt, or the next polling/async-check cycle)	The interrupt handler or `EthTrcv_MainFunction` determines the new reason and overwrites the previously stored value — no application action required.
`EthTrcv_SetTransceiverMode(ETH_MODE_DOWN)` during the sleep transition	The driver re-enables the associated ICU notification so the next hardware wakeup can be detected at all. If this call is skipped, detection of the next wakeup is skipped too — not because an old reason is "stuck," but because the interrupt source was never re-armed.
`EthTrcv_Init` (cold start, "sleeping ECU + sleeping network")	Covers exactly the case where wakeup detection happens during startup itself, before `EthTrcv_CheckWakeup` ever runs for the first time.
Calling `EthTrcv_GetBusWuReason` / `EthTrcv_CheckWakeup`	Both only read the stored reason; neither clears it. Repeated calls return the same value until the next real wakeup event.

Next real hardware wakeup (interrupt, or the next polling/async-check cycle)

The interrupt handler or EthTrcv_MainFunction determines the new reason and overwrites the previously stored value — no application action required.

EthTrcv_SetTransceiverMode(ETH_MODE_DOWN) during the sleep transition

The driver re-enables the associated ICU notification so the next hardware wakeup can be detected at all. If this call is skipped, detection of the next wakeup is skipped too — not because an old reason is "stuck," but because the interrupt source was never re-armed.

EthTrcv_Init (cold start, "sleeping ECU + sleeping network")

Covers exactly the case where wakeup detection happens during startup itself, before EthTrcv_CheckWakeup ever runs for the first time.

Calling EthTrcv_GetBusWuReason / EthTrcv_CheckWakeup

Both only read the stored reason; neither clears it. Repeated calls return the same value until the next real wakeup event.

In practice, this means: if you see an ECU in the field that never reaches deep sleep, don’t go looking for a missing "clear" function — there isn’t one — but check whether the sleep transition is actually triggered via EthTrcv_SetTransceiverMode(ETH_MODE_DOWN). If that call is skipped (e.g. because a BswM rule is wired up incorrectly), wakeup detection for the next cycle stays disarmed — the symptom looks similar to a "stuck" reason, but the root cause is the missing mode transition, not a missing clear step.

If an ECU in the field never reaches deep sleep: first check whether EthTrcv_SetTransceiverMode(ETH_MODE_DOWN) is reliably called on the transition into the sleep state — only that call re-arms wakeup detection for the next cycle. If you come across a function named something like "ClearWakeupReason" in a concrete BSW stack, that’s a vendor extension, not part of the AUTOSAR standard API.

Interplay with EcuM, ComM, and EthSM

WakeUp handling is not a solo act by the EthTrcv driver — it’s orchestrated.

Module Role in the WakeUp flow

Module	Role in the WakeUp flow
EcuM	Orchestrates system start-up and sleep, manages the validation timeout, and decides — based on `EcuM_SetWakeupEvent` calls — whether startup continues or is aborted.
EthSM	Bus state manager for Ethernet; forwards `EcuM_CheckWakeup` requests to `EthTrcv_CheckWakeup` and reports network availability back up to ComM (see the next section).
ComM	Manages communication channels at the application level. Requests the network via `ComM_RequestComMode`, which causes EthSM to activate the transceiver through `EthTrcv_SetTransceiverMode(ETH_MODE_ACTIVE)`. Also uses wakeup indications for partial-networking decisions.
CanSM (for comparison)	Not part of the Ethernet stack, but a useful reference: EthSM is deliberately modeled after the same bus-state-manager pattern as CanSM. Anyone who knows CanSM will recognize the EthSM states immediately.

EcuM

Orchestrates system start-up and sleep, manages the validation timeout, and decides — based on EcuM_SetWakeupEvent calls — whether startup continues or is aborted.

EthSM

Bus state manager for Ethernet; forwards EcuM_CheckWakeup requests to EthTrcv_CheckWakeup and reports network availability back up to ComM (see the next section).

ComM

Manages communication channels at the application level. Requests the network via ComM_RequestComMode, which causes EthSM to activate the transceiver through EthTrcv_SetTransceiverMode(ETH_MODE_ACTIVE). Also uses wakeup indications for partial-networking decisions.

CanSM (for comparison)

Not part of the Ethernet stack, but a useful reference: EthSM is deliberately modeled after the same bus-state-manager pattern as CanSM. Anyone who knows CanSM will recognize the EthSM states immediately.

The ARXML link between an EthTrcv channel and its EcuM wakeup source (EthTrcvWakeupSourceRef) was already covered in Part 3. It’s exactly this parameter that determines which EcuMWakeupSource bit EcuM_SetWakeupEvent sets in step 7 of the validation cycle above.

EthSM & EthTrcv — How the State Manager Coordinates Transceiver State

EthSM (Ethernet State Manager) is the mediation layer between the mode changes that ComM requests at the application level and the actual state of the transceiver. Simplified, the state machine looks like this:

                 ComM requests the network
                              │
        ┌─────────────────────▼─────────────────────┐
        │                 OFFLINE                    │◄────────────┐
        │  EthTrcv in ETH_MODE_DOWN                   │              │
        └─────────────────────┬─────────────────────┘              │
                              │ EthTrcv_SetTransceiverMode(ACTIVE)  │
                              ▼                                     │
        ┌─────────────────────────────────────────────┐            │
        │              WAIT_TRCVLINK                   │            │
        │  Transceiver active, waiting for link-up      │            │
        │  (cyclic polling / indication of               │            │
        │   EthTrcv_GetLinkState)                        │            │
        └─────────────────────┬─────────────────────────┘            │
                              │ Link = ETHTRCV_LINK_STATE_ACTIVE      │
                              ▼                                       │
        ┌─────────────────────────────────────────────┐              │
        │                  ONLINE                       │             │
        │  Link is up, EthIf/ComM is notified            │             │
        │  (ComM_BusSM_ModeIndication)                   │             │
        └─────────────────────┬─────────────────────────┘             │
                              │ ComM releases the network /             │
                              │ link drops                              │
                              ▼                                         │
        ┌─────────────────────────────────────────────┐                │
        │               WAIT_OFFLINE                    │───────────────┘
        │  EthTrcv_SetTransceiverMode(DOWN) triggered   │
        └───────────────────────────────────────────────┘

The exact state names and transitions are implementation-dependent — different BSW stacks label them slightly differently. The principle, however, is stable: EthSM decouples "ComM wants communication" from "the link is actually there," and that decoupling is exactly what gives an ECU time to reasonably wait for frames instead of mistakenly flagging their absence as an error.

Concretely, this means EthSM calls EthTrcv_SetTransceiverMode and either polls or reacts to EthTrcv_GetLinkState — both APIs already covered in detail in Part 2 of this series. What’s new in this post is the context: these calls don’t just happen once during startup, but continuously, triggered by ComM mode requests and link-state changes at runtime.

If an ECU boots but never communicates with other ECUs, even though the physical link is confirmed on the oscilloscope: check the EthSM state first, not the EthTrcv driver. Very often EthSM is stuck in WAIT_TRCVLINK because ComM never actually requested the network at the application level.

Diagnostics & Monitoring

DEM Errors: ETHTRCV_E_ACCESS and Vendor-Specific Events

The standard error path for the transceiver runs through the DEM (Diagnostic Event Manager). The standard AUTOSAR SWS defines exactly one production DEM event for this: ETHTRCV_E_ACCESS ("Transceiver access failed"). It’s reported when access to the transceiver fails — concretely via Dem_ReportErrorStatus, once the configured debounce behavior (time- or counter-based, DemEventParameter) confirms the fault.

DEM aspect	Relevance for diagnostics
Debounce time	Prevents a brief link flicker (e.g. during auto-negotiation) from immediately setting a DTC. Too short → false alarms during normal link establishment; too long → real failures go unnoticed.
Failure operation cycle	Determines how many faulty cycles are needed before the event is considered "confirmed" and, e.g., ends up in the vehicle’s fault memory log.
Vendor-specific events	PHY vendors extend the one standard event through Complex Device Drivers (CDDs) with granular diagnostics: an event for a persistently missing link (e.g. a vendor-specific "PHY down" event), Signal Quality Index (SQI), temperature warnings, MDI CRC error counters, TC10 sleep/wake failures.

DEM aspect

Relevance for diagnostics

Debounce time

Prevents a brief link flicker (e.g. during auto-negotiation) from immediately setting a DTC. Too short → false alarms during normal link establishment; too long → real failures go unnoticed.

Failure operation cycle

Determines how many faulty cycles are needed before the event is considered "confirmed" and, e.g., ends up in the vehicle’s fault memory log.

Vendor-specific events

PHY vendors extend the one standard event through Complex Device Drivers (CDDs) with granular diagnostics: an event for a persistently missing link (e.g. a vendor-specific "PHY down" event), Signal Quality Index (SQI), temperature warnings, MDI CRC error counters, TC10 sleep/wake failures.

The standard AUTOSAR EthTrcv SWS deliberately defines only a single production DEM event (ETHTRCV_E_ACCESS). The real fine-grained diagnostics — a dedicated "link is persistently down" event, a numeric signal-quality value instead of just "link is down" — almost always come from vendor extensions. An event name like ETHTRCV_E_PHYDOWN does show up in real-world projects, but as a vendor-specific extension, not part of the AUTOSAR standard. Anyone working only with the one standard event in the field is seeing just the tip of the iceberg.

Debugging Link State Through DET

DET (Development Error Tracer) is the second diagnostic channel — for integration bugs rather than operational faults. Typical checks in the EthTrcv driver:

ETHTRCV_E_INV_TRCV_IDX     Invalid transceiver index (e.g. an off-by-one
                            against the ARXML channel mapping from Part 3)
ETHTRCV_E_PARAM_POINTER    NULL pointer passed, e.g. to
                            EthTrcv_GetLinkState(idx, NULL_PTR)
ETHTRCV_E_INVALID_PARAM    Invalid enum value passed to
                            EthTrcv_SetTransceiverMode()
ETHTRCV_E_UNINIT           API called before EthTrcv_Init has completed

Keep DET checks active on the ECU during the integration phase, even if they get disabled in the production build. An EthTrcv_GetLinkState call with a wrong index often runs through silently without DET — returning a plausible- looking but wrong result. Bugs like that cost the most time during integration.

When the reported link state doesn’t match physical reality (cable is plugged in, but ETHTRCV_LINK_STATE_DOWN is reported, or vice versa), the following order tends to pay off:

1. Enable DET and check the log for ETHTRCV_E_*
   → integration bug (wrong index, NULL pointer, API called before init)?
2. Log the return value of EthTrcv_GetLinkState right at the call site
   → does the driver's internal state match what's being reported?
3. Read the PHY's MDIO registers directly (next section)
   → does the driver state match the actual PHY state?

These three steps cleanly separate integration bugs (step 1), driver/state bugs (step 2), and actual hardware/cabling problems (step 3) — and working through them in that order pays off, because each step is cheaper than the next.

Reading MDIO Registers Directly

When software-side diagnostics hit their limit, the last resort is looking at the PHY registers themselves — independent of whatever the EthTrcv driver makes of them.

Important for the architecture: EthTrcv doesn’t own the MDIO bus itself. It synchronously calls EthIf_ReadMii/EthIf_WriteMii (from EthIf.h); per the spec, EthIf forwards that call internally to Eth_ReadMii/Eth_WriteMii of the responsible Eth driver, which performs the actual bus transaction. Both EthIf_*Mii functions are synchronous and return the result directly — a separate callback pair (EthTrcv_ReadMiiIndication/EthTrcv_WriteMiiIndication) only existed up through release R23-11; it was removed from the standard as of R24-11.

Via a vendor extension API:

Many PHY drivers offer, in addition to the standard EthTrcv interface, non-standardized access functions that read raw MDIO registers — e.g. EthTrcv_<Vendor>_ReadMdiRegister(). This exposes registers AUTOSAR itself doesn’t know about:

Register (Clause 22, address 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-specific status register (example)
  SQI     Signal Quality Index     0-15, decreasing values = cable/EMC issue
  TEMP    Temperature warning      set under thermal overload
  WU_ST   TC10 wakeup status       last wakeup reason (local/remote/reset)

The link-status bit in the BMSR is latched low: it stays at 0 until read once, even if the link has since recovered. A single read can therefore show a historical link drop that’s long over. Getting the current state requires a second read immediately afterward.

Via an external diagnostic tool:

When the suspicion is that the problem lies not in the driver but in the PHY itself or the cabling, it helps to access the hardware outside the software stack: an MDIO adapter on the debug interface, or a bench setup that drives the PHY in isolation from the rest of the ECU. That reliably separates "software reports the wrong state" from "hardware genuinely delivers this state."

Common Runtime Problems and Their Causes

PHY Doesn’t Come Up After Reset

Cause Tell-tale sign

Cause	Tell-tale sign
Power-sequencing violation (see the Hardware Deep Dive)	MDIO reads consistently return `0xFFFF` or `0x0000` right after `EthTrcv_Init`
Strap pins wired incorrectly (PHY address, operating mode)	PHY doesn’t respond on the expected MDIO address. This hardware address isn’t a standalone EthTrcv ARXML parameter — it’s internal to the Eth driver’s implementation. What’s configured in ARXML instead is which Eth controller performs the MII access for this transceiver (`EthTrcvMgmtInterface` → `EthTrcvMiiInterface` → `EthTrcvCtrlIdx`) and which transceiver index it index EthIf passes to `Eth_ReadMii`/`Eth_WriteMii` on its behalf (`EthTrcvMiiIdx`) — looks like "PHY is dead" but is actually an addressing problem at the Eth layer
Reset held too short (`RST_N` deasserted too early)	PHY doesn’t respond to the first few MDIO accesses, then behaves normally — intermittently reproducible, strongly temperature-dependent
MDC clock absent or applied too early	Complete failure of all register accesses, not just some

Power-sequencing violation (see the Hardware Deep Dive)

MDIO reads consistently return 0xFFFF or 0x0000 right after EthTrcv_Init

Strap pins wired incorrectly (PHY address, operating mode)

PHY doesn’t respond on the expected MDIO address. This hardware address isn’t a standalone EthTrcv ARXML parameter — it’s internal to the Eth driver’s implementation. What’s configured in ARXML instead is which Eth controller performs the MII access for this transceiver (EthTrcvMgmtInterface → EthTrcvMiiInterface → EthTrcvCtrlIdx) and which transceiver index it index EthIf passes to Eth_ReadMii/Eth_WriteMii on its behalf (EthTrcvMiiIdx) — looks like "PHY is dead" but is actually an addressing problem at the Eth layer

Reset held too short (RST_N deasserted too early)

PHY doesn’t respond to the first few MDIO accesses, then behaves normally — intermittently reproducible, strongly temperature-dependent

MDC clock absent or applied too early

Complete failure of all register accesses, not just some

Before suspecting the software stack: check reset timing and MDIO traffic directly at the PHY with an oscilloscope. An EthTrcv_Init that returns successfully says nothing about whether the PHY actually received the commands — many MDIO writes aren’t acknowledged.

Link Stays Permanently DOWN Even Though the Cable Is Connected

The most common runtime problem during integration, with several possible causes that are easy to confuse:

Cause Tell-tale sign

Cause	Tell-tale sign
Master/slave role conflict (both sides master or both slave)	No link training occurs; the BMSR auto-negotiation-complete bit stays 0 permanently (covered in more depth in a dedicated post, see the outlook below)
Wrong `EthTrcvSpeed`/duplex configuration in ARXML	Link comes up briefly, then drops immediately — a mismatch between the configured capabilities of both link partners
Cable attenuation/length beyond spec	SQI value (if available) stays low, link establishment takes unusually long or narrowly fails
Missing or defective common-mode filter/connector	Link works on the bench with a short cable but fails in the vehicle harness (see the EMC section in the Hardware Deep Dive)
EthSM stuck in `WAIT_TRCVLINK` because ComM never requested the network	Physical link is up per the register, but `EthTrcv_SetTransceiverMode(ACTIVE)` was never called — not a hardware problem but a configuration/application issue (see the EthSM section above)

Master/slave role conflict (both sides master or both slave)

No link training occurs; the BMSR auto-negotiation-complete bit stays 0 permanently (covered in more depth in a dedicated post, see the outlook below)

Wrong EthTrcvSpeed/duplex configuration in ARXML

Link comes up briefly, then drops immediately — a mismatch between the configured capabilities of both link partners

Cable attenuation/length beyond spec

SQI value (if available) stays low, link establishment takes unusually long or narrowly fails

Missing or defective common-mode filter/connector

Link works on the bench with a short cable but fails in the vehicle harness (see the EMC section in the Hardware Deep Dive)

EthSM stuck in WAIT_TRCVLINK because ComM never requested the network

Physical link is up per the register, but EthTrcv_SetTransceiverMode(ACTIVE) was never called — not a hardware problem but a configuration/application issue (see the EthSM section above)

Sporadic Link Drops

The most unpleasant category, because it’s often not reproducible on the bench:

EMC coupling in the vehicle harness — often occurs only with the engine running or specific loads active (ignition system, DC/DC converters), not on the workbench.
Marginal cable length/quality — works at room temperature, fails in cold or heat because the attenuation margin shifts.
Thermal drift of the PHY — SQI degrades over the operating time until error correction can no longer keep up; visible only through long-term monitoring, not a single snapshot.
DEM debounce configuration too aggressive — the physical link recovers faster than the application reacts, but ETHTRCV_E_ACCESS (or a vendor-specific counterpart) still gets set and propagated briefly because the debounce window is too tight.
Ground potential fluctuations in the harness — hard to distinguish from an actual PHY defect, usually only shows up in the vehicle, never on the test bench.

Diagnosing sporadic link drops from software logs alone rarely gets you to the root cause. Without continuous monitoring of SQI/error counters over time — not just the last link state — any root-cause analysis stays speculation.

Conclusion & Outlook

That completes the EthTrcv core series: from the basics, through the API and init sequence, ARXML configuration, and now WakeUp handling and diagnostics.

Part	Title	Focus
1	EthTrcv Part 1 — Basics & Classification	Positioning EthTrcv in the AUTOSAR stack, distinction from EthIf/Eth/EthSM
2	EthTrcv Part 2 — API & Initialization Sequence	Core APIs, init order, state transitions
3	EthTrcv Part 3 — ARXML Configuration in Practice	Containers, parameters, common configuration mistakes
4	EthTrcv Part 4 — WakeUp Handling & Diagnostics (this post)	WakeUp cycle, EthSM coordination, diagnostics & common runtime problems

Part

Title

Focus

EthTrcv Part 1 — Basics & Classification

Positioning EthTrcv in the AUTOSAR stack, distinction from EthIf/Eth/EthSM

EthTrcv Part 2 — API & Initialization Sequence

Core APIs, init order, state transitions

EthTrcv Part 3 — ARXML Configuration in Practice

Containers, parameters, common configuration mistakes

EthTrcv Part 4 — WakeUp Handling & Diagnostics (this post)

WakeUp cycle, EthSM coordination, diagnostics & common runtime problems

For readers who want to go deeper, further deep-dive posts are planned on topics this core series only touched in passing: master/slave role negotiation, loopback testing, MDIO in detail, gPTP time synchronization, safety aspects (ASIL decomposition at the transceiver), MACsec, and migration paths between PHY generations. The Hardware Deep Dive into PHY hardware architecture is already live and a good next stop for anyone moving from this series' software perspective down to the PCB level.

For readers running a full switch topology rather than a single transceiver, the natural continuation is EthSwt — The AUTOSAR Ethernet Switch Driver — much of what’s covered in this series (link state, DEM/DET diagnostics, WakeUp coordination) reappears there in a more complex form, multiplied across multiple ports.

Summary

Topic Key takeaway for software developers

Topic	Key takeaway for software developers
WakeUp sources	PHY-pin wakeup has already happened by the time software starts and only needs confirming; in-band TC10 wakeup is an active part of network management
EthTrcv_CheckWakeup	Runs inside the EcuM validation cycle and must confirm a reason via `EcuM_SetWakeupEvent` within the timeout — otherwise startup is aborted
Resetting the wakeup reason	There’s no dedicated "clear" function in the standard API — the stored reason is implicitly overwritten on the next real wakeup; what matters is that `EthTrcv_SetTransceiverMode(ETH_MODE_DOWN)` is reliably called on the sleep transition so the driver can detect the next wakeup
EthSM	Decouples ComM mode requests from the actual link state; stuck states are often an application issue, not a hardware issue
DEM/DET	`ETHTRCV_E_ACCESS` is the only standard DEM event for operational faults (further events like a PHY-down indicator are vendor extensions), DET checks cover integration bugs — both channels deliver different, complementary information
Runtime problems	PHY start-up issues, a permanently dead link, and sporadic drops have overlapping but distinguishable causes — reading MDIO registers directly separates a software problem from a hardware problem

WakeUp sources

PHY-pin wakeup has already happened by the time software starts and only needs confirming; in-band TC10 wakeup is an active part of network management

EthTrcv_CheckWakeup

Runs inside the EcuM validation cycle and must confirm a reason via EcuM_SetWakeupEvent within the timeout — otherwise startup is aborted

Resetting the wakeup reason

There’s no dedicated "clear" function in the standard API — the stored reason is implicitly overwritten on the next real wakeup; what matters is that EthTrcv_SetTransceiverMode(ETH_MODE_DOWN) is reliably called on the sleep transition so the driver can detect the next wakeup

EthSM

Decouples ComM mode requests from the actual link state; stuck states are often an application issue, not a hardware issue

DEM/DET

ETHTRCV_E_ACCESS is the only standard DEM event for operational faults (further events like a PHY-down indicator are vendor extensions), DET checks cover integration bugs — both channels deliver different, complementary information

Runtime problems

PHY start-up issues, a permanently dead link, and sporadic drops have overlapping but distinguishable causes — reading MDIO registers directly separates a software problem from a hardware problem

This concludes the EthTrcv core series. More deep-dive posts on Master/Slave, loopback, MDIO, gPTP, safety, MACsec, and more are in the series overview

WakeUp Handling#

WakeUp Sources: PHY Pin and In-Band Signal#

EthTrcv_CheckWakeup — Flow Inside the EcuM WakeUp Validation Cycle#

The Wakeup Reason: Latching and When It Gets Reset#

Interplay with EcuM, ComM, and EthSM#

EthSM & EthTrcv — How the State Manager Coordinates Transceiver State#

Diagnostics & Monitoring#

DEM Errors: ETHTRCV_E_ACCESS and Vendor-Specific Events#

Debugging Link State Through DET#

Reading MDIO Registers Directly#

Common Runtime Problems and Their Causes#

PHY Doesn’t Come Up After Reset#

Link Stays Permanently DOWN Even Though the Cable Is Connected#

Sporadic Link Drops#

Conclusion & Outlook#

Summary#

WakeUp Handling

WakeUp Sources: PHY Pin and In-Band Signal

EthTrcv_CheckWakeup — Flow Inside the EcuM WakeUp Validation Cycle

The Wakeup Reason: Latching and When It Gets Reset

Interplay with EcuM, ComM, and EthSM

EthSM & EthTrcv — How the State Manager Coordinates Transceiver State

Diagnostics & Monitoring

DEM Errors: ETHTRCV_E_ACCESS and Vendor-Specific Events

Debugging Link State Through DET

Reading MDIO Registers Directly

Common Runtime Problems and Their Causes

PHY Doesn’t Come Up After Reset

Link Stays Permanently DOWN Even Though the Cable Is Connected

Sporadic Link Drops

Conclusion & Outlook

Summary