MCO out from stm32f107 is weak at 25 MHz and non-existing at 50 MHz... I'm obviously doing something wrong, but what?

[Torkel]

I am debugging why Ethernet is not working on a setup with stm32f107 + DP83848. Right now I was verifying that the MCO (main clock out) from the stm32f107 is doing what it should by checking with a scope. But MCO output doesn't seem to be working at all, and I can't understand why.

The setup: A 25 MHz crystal drives the f107 and is passed to a pll and from that the MCO should output 50 MHz. (Cube is used to set it all up visually.)

The f107-PA8 MCO is connected to f107-PA1 (ETH_RMII_REF_CLK) and to DP83848-X1. It's a 4-layer pcb with a proper signal and ground plane between red and blue, with only the vias through it:

On my scope I failed to see any signal on the clock output when it runs at 50 MHz. I tried google and this forum, and found something that seemed to indicate that a resistor should be used in series from f107-MCO to dp83848-X1. So I cut off the trace using a knife (under C37). Still no signal. Then I also cut off the trace from f107-PA8 to f107-PA1 (at C20). But even with traces cut (multimeter tested) I see no signal on MCO:

I then suspected that something could be wrong with the setup in Cube, so I lowered the frequency to 25 MHz, and then I see the signal. But to me it looks weak and distorted?

So my question here is: does anyone have any idea what I am doing wrong here?

I'm probably doing some newbie mistake - I was thinking that there could be some capacitive coupling on the trace... the vias and running it on the bottom layer felt like it could have been done better? But from googling on 50 MHz signal routing it seems like that should not be so bad that it would cancel out the whole signal? Could it be misconfiguration - but should I have to worry about that given that Cube sets it all up for me?

I do have a second board (jlcpcb - 10 pcbs with 2 boards smt assembled), so if no ideas come here I will populate the debug and other headers on that one and see if it behaves the same.. (To me it seems really unlikely that it would be the board or component damage though.)

[berendi · Accepted solution]

Set the output drive strength for the MCO pin in the GPIO CRL or CRH register. See the reference manual and the datasheet for details.

[Torkel]

Thank you!!!

If I am analyzing this correctly it turns out MX_GPIO_Init() is called after SystemClock_Config(), and for some reason the following code is generated for me in MX_GPIO_Init():

  /*Configure GPIO pin : PA8 */
  GPIO_InitStruct.Pin = GPIO_PIN_8;
  GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
  HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

From my Cube setup I fail to see why this would happen, but changing GPIO_SPEED_FREQ_LOW to GPIO_SPEED_FREQ_HIGH gives me the following waveform, which looks much more like I expect it would:

[berendi]

Never assume that CubeMX or the HAL functions do what you think they should do.

[Piranha]

Take a note that PLL has a significantly higher jitter than the oscillator. As a comment on datasheet figure 56 notes, this particular PHY should tolerate that level of jitter, but overall that is not the best scenario. A better solution is to output the 25 MHz HSE signal directly to MCO and use PHY chip with an integrated PLL. Microchip has plenty of such and they are cheaper than the DP83848.