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
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
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
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:
This will help in diagnosing the problem more accurately.
BR, Petr
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