Clock issue of S32K3 EMAC

[wuxianlong]

Hi， NXP

Regarding the clock configuration of the EMAC of S32K3, why is there a timing issue between the input clock and the register configuration?

After TXC and RXC receive stable clocks, configure the relevant registers MUX_7.MUx_8, MUX_9, and the EMAC can work normally.

Before TXC and RXC receive stable clocks, configure the relevant registers MUX_7.MUx_8, MUX_9, and the output rate of the EMAC will be abnormal.

I compared the relevant registers, and all are the same configurations.

Best Regards,
xianlong

[sw_ma]

I encountered an initialization timing issue while using the Emac function of s32k314. If initialization is performed according to the timing in the demo (initializing GPIO first and then initializing clock), EMAC can work normally. However, if initialization is performed according to the timing of initializing GPIO first and then initializing clock, EMAC will run abnormally. Why is this?

[wuxianlong]

This problem you mentioned is the same as mine. Before the pin initialization, both EMAC_TXC/RXC are in GPIO mode. If the clock is initialized directly, the condition cannot be met (the clock initialization of the EMAC must be performed after the clock input is stable). As for why this condition needs to be met, there is currently no explanation or description.

[sw_ma]

Thank you for your answer. I now have a better understanding of this question.

[PetrS]

Hi,

there should be no issue if the clock MUXes (MUX_7, MUX_8, MUX_9) are configured before the external TXC/RXC clocks become stable. However, it is essential to ensure that the EMAC initialization is performed only after the external clocks are stable. This is typically achieved by adding a delay after clock and pin initialization.

BR, Petr

[wuxianlong]

Hi,@PetrS

Thank you for your reply.
After I tested adding a delay, the EMAC was able to send out MAC frames, but the data was incorrect.
The difference I tested: whether to configure the clock multiplexers (MUX_7, MUX_8, MUX_9) before the external TXC/RXC clock is stable.

Best Regards.
xianlong

[PetrS]

Hi,

if the issue is related to the placement of PHY RST deassertion—working when done before clock initialization but failing when done after—it could still be due to insufficient delay for PHY activation.

Please note that the PHY typically requires a delay of around 6 ms or more after RST deassertion before it becomes fully active. Try extending the delay you're currently using to ensure proper PHY readiness.

Also, if you deassert RST before clock initialization, you inherently introduce some delay due to waiting for the crystal oscillator, PLL lock, and mode transitions. This might explain why it works in that case.

If the issue persists, please share:

• The full project you're using
• Details about the hardware setup

This will help in diagnosing the problem more accurately.

BR, Petr

[wuxianlong]

Hi，

I tested it using the S32K3x4. This issue is not related to the RTD version or the type of PHY chip.
You can test and reproduce it.

Best Regards,

xianlong