MCO capability

[RussP]

I'm working on a board redesign due to supply chain issue with a NXP MK70 MCU. The previous design clocked both the MK70 and a Spartan 6 FPGA with an external 50MHz crystal oscillator.

The new design is using the STM32L4R9AII6 MCU -- max HSE input freq of 48MHz. I'm considering the following:

• an external 8MHz crystal oscillator driving the HSE input
• internal PLL generating a SYSCLK of 100MHz
• drive the MCO Source MUX with SYSCLK & divide its output by 2
• Use the MCO pin to drive the FPGA clock input

Questions

1. Sanity check: is this a valid use of the MCO pin (or is it just handy for debug)?
2. A conservatively estimated max routed length for MCO pin to FPGA clock input is 25mm. Would an external driver be recommended?

[Tesla DeLorean]

This is a common use for MCO, the ST-LINK (F1/F7) designs use it to supply 8 MHz on NUCLEO/DISCO designs to the Target MCU. I think the MCO pin should have more than enough drive, and 25mm seems quite short.

On boards using Ethernet 25 MHz is often fed-thru from the HSE source, but not the PLL, as this is a bit jittery for that application, would probably also avoid for radio. Many STM32 are capable of taking 25 or 50 MHz TCXO type sources. Though the L4R9 does state fHSE as 48 MHz.

I might be tempted to take a 50 MHz source, and divide that by two to feed into the STM32. Something like that would give you more flexibility to clock the STM32 at different rates, and hit 120 MHz

[RussP]

Thanks for that feedback -- its good to hear that this idea is a workable alternative.

I agree that one external clock for both devices is the most flexible method -- the lack of immediately available dividing buffers (supply chain issues) forced me to think about using the device resources. I checked again last night and didn't see any improvement.

I will look into utilizing a PLL in the FPGA to operate from 25MHz => use that clk for both devices

[Viktor POHORELY]

This use case is valid for application too, not designated to debug only. However, you need to take into account that MCO is not active in certain cases - reset, some low power modes etc.

[RussP]

Thank you for this comment.

Although my application won't be using any low power features, I think the reset case should be considered carefully.