> 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
