Clock issue of S32K3 EMAC

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Clock issue of S32K3 EMAC

178 Views
wuxianlong
Contributor V

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. wuxianlong_0-1761725478471.png

Best Regards,
xianlong

0 Kudos
Reply
4 Replies

152 Views
PetrS
NXP TechSupport
NXP TechSupport

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

0 Kudos
Reply

133 Views
wuxianlong
Contributor V

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.
wuxianlong_0-1761788185412.png

wuxianlong_1-1761788275424.png

wuxianlong_2-1761788351696.png

Best Regards.
xianlong

 

0 Kudos
Reply

105 Views
PetrS
NXP TechSupport
NXP TechSupport

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

0 Kudos
Reply

95 Views
wuxianlong
Contributor V

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

0 Kudos
Reply