Why does ENET_TX_CLK (GPIO_B1_10) have SION enabled in the SDK?

[nickwallis]

Hi,

Why does ENET_TX_CLK (GPIO_B1_10) have SION enabled in the SDK?

This pin is an output, it's the 25MHz reference clock for the Ethernet PHY.

thanks

-Nick

  IOMUXC_SetPinMux(
      IOMUXC_GPIO_B1_10_ENET_REF_CLK,         /* GPIO_B1_10 is configured as ENET_REF_CLK */
      1U);                                    /* Software Input On Field: Force input path of pad GPIO_B1_10 */

[jeremyzhou]

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1) Why does ENET_TX_CLK (GPIO_B1_10) have SION enabled in the SDK?
-- I think Mark already explained it in detail and hope it helps.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[mjbcswitzerland]

Hi Nick

In the case of RMII interface, as used on the EVKs, a 50MHz clock, derived from PLL6, is output on ENET_REF_CLK (GPIO_B1_10 - or GPIO2-26) [referenced as ENET_TX_CLK on diagrams, although not necessarily the pin's name]. Note that it is not 25MHz, which is used only in MII mode (50MHz is required for RMII mode).

This output clock is supplied to the PHY as oscillator input so that it can work and is also required by the Ethernet controller as common synchronised clock. It is however only a common synchronised clock when it is actually applied to the Ethernet controller itself.

Without SION cleared the clock is indeed output to the PHY but not internally looped back from the pad to the Ethernet controller and so it will be missing its clock. With SION set the loop-back takes place and so both PHY and Ethernet controller have their required clock.

As comparison, the SION is also needed by LPI2C pins so that the LPI2C Tx generated outputs are also connected (looped back) to the LPI2C receiver - without this the receiver part will not work as it won't 'see' the I2C bus.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/iMX/RT1060.html

[nickwallis]

Thanks @mjbcswitzerland , that makes sense.

But how do you know, other than by trail-and-error, which peripherals need SION set in order to function correctly?

-Nick

[mjbcswitzerland]

Nick

Since there are no actual details about how the internal workings are connected I don't think one can generally know exactly when SION is needed or not, so sometimes trial and error is the only way to be sure.

In the case of I2C traditionally both Rx and Tx part of the peripheral is connected to the bus signals but in the i.MX RT pin pad design they default to being isolated so the Tx part can send something out without the Rx part from 'seeing' it if the internal connection is not made. This is probably the easiest situation to imagine since it is obvious that both Rx and TX parts need to share the same lines and the Rx can't work if it is separated from the bus. In the case of some clocks it is not necessarily quite so obvious.

Also I don't know when SION control has benefits over fixed internal connections but maybe one day there will be a situation where it could be useful(?)

Regards

Mark

[nickwallis]

OK thanks Mark.

I did some time ago have difficulty getting the LPUART peripheral to work correctly in ONEWIRE mode (i.e. Tx and Rx both share the same external bus, in a similar way to I2C. This also means the Tx output must be open drain, not push-pull). At the time I quickly implemented what I needed using GPIO and moved on, but now I wonder if part of the problem might have been SION not being set for those pins........ think I'll revisit this when I get chance.

-Nick