STM32C5 Series Ethernet CLK

[Franzl]

Hello, I have one of the new STM32C5A3ZG chips here.
I am currently trying to configure Ethernet using CubeMX2.

However, I am unable to configure the system clock to run above 100 MHz while simultaneously enabling Ethernet, as the Ethernet peripheral requires a 100 MHz clock. This is quite a significant loss of performance, considering the core is capable of running at 144 MHz. If I were to try to enable USB at the same time, it wouldn't work at all, as that peripheral requires a 48 MHz clock. Furthermore, I do not trust the internal RC oscillator to provide a stable connection for USB.

Is there a practical solution for this?

[Andrew Neil]

Welcome to the forum

Please see How to write your question to maximize your chances to find a solution for best results.

In particular, what board are you using?

[waclawek.jan]

> the Ethernet peripheral requires a 100 MHz clock

What clock?

Unless you are going to use PTP - which is an advanced feature to be left after basic function is working - there are at least 5 different signals which are related to ETH and can be called clocks (see block diagram of the ETH module in ETH chapter in RM):

1. eth_hclk - this is the clock to interface the ETH module to AHB bus matrix, i.e. through which registers are written and data are transferred to and from the rest of mcu. I can't find no restriction for this clock's frequency in the 'C5 documentation, although there's probably some sane minimum (e.g. 25MHz in 'F4)

2. eth_rx_clk/eth_tx_clk - these are clocks used in MII mode, which have to be supplied from the PHY through the ETH_MII_TX_CLK/ETH_MII_RX_CLK (25MHz for 100Mbps ETH) - yellow path in Clock distribution for ETH figure in the RCC chapter (due to ST's characteristic inability to hold consistent signal names across RM, in this figure these signals are called clk_rx_i/clk_tx_i

3. eth_ref_clk - this is are used in RMII mode, and these too have to be supplied from the PHY through ETH_RMII_REF_CLK pin (50MHz for 100Mbps ETH) - blue in the Clock distribution for ETH figure in the RCC chapter (and this signal is called clk_rmii_i in that figure). From this clock, in fact, eth_rx_clk/eth_tx_clk are generated too, in RCC, but that's a lesser important detail here.

4. ETH_CLK/eth_clk_fb - this signal has nothing to do with ETH module per se, it's a convenience signal coming from RCC and through ETH_CLK pin, it may supply the primary clock to the PHY (most PHYs can use their own crystal oscillator to generate the reference clocks, or use some external source for their input clock - and this would then be that external source). Depending on the PHY used, this has to be 25/50/100MHz (or not, if there's some other clock source to the PHY). In RMII mode, eth_clk_fb can also be used as source of eth_ref_clk if ETHREFCLKSEL=1, but IMO that won't conform to the ETH timing requirements. Some may see that as sparing down the clock-out->PHY->reference-clock-in path i.e. sparing pins, but there are reasons (delays, jitter) for that path.

If CubeMX2 insists of system clock being 100MHz, you've probably set the same source for system clock as for ETH_CLK and/or enabled ETHREFCLKSEL. As I explained above, it's not optimal. If you do it that way, then you have the 100MHz restriction, too. If this is not the case, then it's some CubeMX2 bug.

Disclaimer: I don't use the 'C5 and I don't use CubeMX2.

JW

[Saket_Om]

Hello @Franzl 

Please refer to the attached .ioc2 file, which configures the Ethernet clock to 96 MHz while keeping the system clock at 144 MHz.

[Franzl]

I have this warning in CubeMX2 v1.0.1 if ETH1 MUX not 25MHz or 50MHz or 100MHz:

Datasheet say at ETHCLKSEL, i have three fixed options: 25MHz, 50MHz, 100MHz

I want to use an LAN8720A ETH-PHY

[waclawek.jan]

As I've said above, IMO, what is selected by ETHCLKSEL is *not* the ETH kernel clock, despite what CubeMX2 says. I believe the CubeMX2 authors (nor authors of the ETH example provided for 'C5 Nucleo) don't have deep enough understanding of that detail.

It is the source of signal to be output on ETH_CLK pin. Look at the very figure you've posted above. It's optional. For example, the 'C5 Nucleo board does not use it; the PHY there uses its own crystal, and that is for a good reason, as clock generated from STM32 is often not good enough as far as precision, jitter and stability goes, to be used as PHY primary input clock.

It *may* become source of the true three kernel clocks - eth_rx_clk/eth_tx_clk/eth_ref_clk, confusingly named clk_rx_i/clk_tx_i/clk_rmii_i in the figure above - provided that eth_clk_fb is used by ETHREFCLKSEL; but I wouldn't recommend that, as those clocks are normally to by supplied by the PHY.

In other words, it does not matter, how ETHCLKSEL is set and what's the source of that clock, as long as you don't use ETH_CLK pin as clock output towards the PHY and as long as you don't set ETHREFCLKSEL.

That said, I repeat, I don't use the 'C5 and I don't use CubeMX2. But what could you loose by trying.

JW

[Saket_Om]

Hello @Franzl 

I solved this warning in the ioc2 file attached. 

[Andrew Neil]

What was the key?

[Saket_Om]

Hello @Andrew Neil 

Configure the PSI clock to $\text{MHz}$. Set the PSIK divider to $1$, select PSIK as the clock source for the ETH1 multiplexer, and configure the ETH1 divider to 1.