In an RGMII deployment, when the peer device is powered on later than the switch, communication may remain abnormal
even though no MAC errors are reported. After manually reconfiguring RXC_DELAY and RXC_PD, communication returns to
normal. Could you recommend a reliable approach to determine whether end-to-end peer communication is truly
operational, rather than relying only on basic status indications?
System Configuration:
| Port | Connection | Mode |
|--------|------------|---------|
| Port 0 | SOC | MAC-MAC |
| Port 4 | MCU | MAC-MAC |
| Port 1 | PHY | MAC-PHY |
Initialization Sequence:
1. MCU boots and initializes Switch/PHY configurations
2. SOC completes initialization ~10 seconds later
3. Ethernet device visible via ifconfig, but communication fails
4. RXC must be manually controlled to restore communication
Problem: No error notification mechanism to determine SOC boot completion or when to trigger RXC for recovery. Port 1
and Port 4 remain operational during this issue.
Observed Symptoms:
| Scenario | MACERR | Recovery Method |
|------------------------------------ |----------------------|---------------------------------|
| SOC online at normal temperature | Reported (Runt+SOF) | Reconfigure RXC_BYPASS + RXC_PD |
| SOC powered on at high temperature | NOT detected | Reconfigure RXC_BYPASS + RXC_PD |
Additional Issue (possibly unrelated):
During normal operation, Port 0 may occasionally go offline with low probability. When this occurs, no MACERR is
reported and communication cannot be restored.
Best regards,
__shiyi
Hello @__shiyi ,
Which PHY device are you using on the RGMII interface?
When you mention the peer device, do you refer to the link partner of your PHY or another MCU MAC, switch or SoC?
Does the issue require a manual reconfiguration of RXC_DELAY / RXC_PD only after the initial power‑up or does it also occur after a normal link down / link up cycle?
The standard link status (PHY link up, MAC no error counters) only confirms signal‑level integrity. Reliable confirmation requires checks at higher OSI layers, e.g. TCP/IP.
Best regards,
Pavel
Hello @__shiyi ,
Thank you for detailed description.
It appears that this behavior is described in UM11040, Software user manual for SJA1105P, SJA1105Q, SJA1105R, SJA1105S, Rev. 3, Table 123. Registers CFG_PAD_MIIx_ID . Please check that out.
Best regards,
Pavel