This post was revised after fact-checking it against the real SWS EthSwt (see correction issue #145): the SWS actually uses the term SMI itself — not as vendor jargon, but as the name for the register space that EthSwt_ReadMmd/WriteMmd address.

SMI vs. MDIO — same electrical layer, extended access

The Serial Management Interface (SMI) uses the same electrical foundation as the MDIO (IEEE 802.3 Clause 22/45) known from this blog’s EthTrcv MDIO post. The difference lies in what’s being accessed: in a plain EthTrcv setup, MDIO addresses pure PHY registers. With EthSwt, the same electrical interface allows access to switch-internal transceiver registers over an extended register space — for which the SWS provides a dedicated API, EthSwt_ReadMmd/WriteMmd.

The real API

Std_ReturnType EthSwt_ReadMmd(
    uint8   SwitchIdx,
    uint8   SwitchPortIdx,
    uint8   Mmd,        // MDIO Manageable Device
    uint16  RegIdx,     // index of the transceiver register on the SMI
    uint16* RegValPtr
);

Std_ReturnType EthSwt_WriteMmd(
    uint8   SwitchIdx,
    uint8   SwitchPortIdx,
    uint8   Mmd,
    uint16  RegIdx,
    uint16  RegVal
);

Per the SWS, both functions are reentrant for different SwitchIdx but not reentrant for the same SwitchIdx — parallel access to different switch chips is fine, but access to the same chip has to be serialized.

Clause 45 — native or emulated

Perhaps the most important sentence in the spec about these two functions: "Reads/writes a transceiver register using Clause 45 access if supported by hardware, or implements a Clause 45 access using Clause 22 operations." Concretely, that means:

  • If the switch chip natively supports Clause 45 (extended register space with device address + 16-bit register index), the driver uses it directly

  • If the hardware only supports Clause 22 (classic 5-bit register address), the driver emulates the Clause 45 access internally via several Clause 22 operations

This emulation is fully transparent to the caller — EthSwt_ReadMmd/ WriteMmd look identical from the application side, regardless of whether native Clause 45 cycles or a sequence of Clause 22 accesses run underneath. Still, when debugging with a logic analyzer it’s worth knowing which case applies — the number of bus cycles per ReadMmd call differs significantly.

Configurability

Like most optional EthSwt APIs, EthSwt_ReadMmd and EthSwt_WriteMmd can be toggled at pre-compile time — via EthSwtReadMmdApi and EthSwtWriteMmdApi respectively. If the function isn’t needed (e.g. because the chip vendor’s driver exposes diagnostic registers some other way), it can be removed from the generated code.

SMI directly in diagnostic code

For cases where no AUTOSAR API access is possible (e.g. during very early bring-up, before EthSwt_Init has even completed successfully), direct SMI access via an external MDIO adapter or a debug board remains common practice — content-wise identical to what this blog’s EthTrcv MDIO post describes for the transceiver case.

Case study: VLAN table doesn’t match the configuration

  1. EthSwt_GetArlTable or the corresponding VLAN diagnostic API returns unexpected values

  2. Direct register access via EthSwt_ReadMmd on the vendor-specific VLAN table register to see the actual hardware state

  3. Cross-check against the expected ARXML configuration (Part 3 of this series)

  4. If there’s a mismatch: check whether an EthSwt_EnableVlan call has changed the state at runtime in the meantime

Summary

AspectKey takeaway

SMI vs. MDIO

Same electrical layer (Clause 22/45), but an extended register space for switch-internal transceiver registers

API

EthSwt_ReadMmd/WriteMmd(SwitchIdx, SwitchPortIdx, Mmd, RegIdx, …​)

Clause 45

Used natively if the hardware supports it — otherwise transparently emulated via Clause 22 operations

Reentrancy

Parallel across different switches, serialized for the same switch