32F4 - is there a spec on the 50MHz clock from the ETH PHY?

[peter-h]

I have a fairly standard LAN8742 driving a 50MHz clock to the 32F417.

The 32F417 is producing a 25MHz clock to the PHY and that doubles it and sends it back to the 32F417.

All the schematics around have a 22R resistor in that 50MHz track. Mine is about 5cm long and I did the same, so the value can be tweaked if necessary.

The signal out of the 8742 is a super clean square wave - very good for 50MHz (10ns/div on a 350MHz scope)



but after the 22R it isn't so great (but everything works)



I would imagine this 50MHz goes into a logic gate and gets squared up. The risetime is about 2ns and that includes the scope, so it looks fast enough. But I can't find a spec for this anywhere.

The tradeoff is EMC; a sharp 50MHz signal going around the place is not a good idea. The track before the 22R is only about 10mm long.

[paulca]

50Mhz is pretty non trivial RF.  I think when they start putting ** notes on the pinout diagram it means they are serious about the track length and probably that track will need careful routing and maybe capacitance protection with ground guards.  Although I'm not an expert in any of that.

I'm going to assume you have to do it this way for the ETH PHY, because doesn't the STM32 normally take a low but highly accurate HSE signal like 8Mhz and multiply it up to get to FCLK via the PLL?  Doing so lowers the requirements on RF circuitry.

I know on even smaller MCUs with 20Mhz clocks the crystal and load caps were always placed right beside the xtl pins to minimise capacitance issues.

[peter-h]

I've been looking for a spec for the input signal on
ETH_RMII_REF_CLK-------> PA1
which is 50MHz.

[wek]

STM32F417 DS, Dynamics characteristics: Ethernet MAC signals for RMII Table.

Match that with the PHY's specs plus any delay/skew/whatever you have on the signals.

JW

[peter-h]

I saw that, but there is no spec on the clock "quality".

That slower clock may be delaying the effective clock by ~1ns. I can check the data hold time etc, though not easily because I have only one 0.9pF 1GHz ZS1000 probe; they are >£1k

[nctnico]

The 50MHz coming from the PHY doesn't have much of a sharp edge to begin with. I'd replace the 22 Ohm resistor with a 0 Ohm resistor and increase it if it turns out to be a problem.

I'd be more worried about the ethernet side of the PHY leaking RF (multiples of 125MHz) into the ethernet cable. Power supply filtering, power distribution (plane or fat traces) and decoupling of the analog side of the PHY is very important. My goto solution when using low-costs PHYs is to add resistors (ballpark 3 OHm) or ferrite beads in series with the ethernet lines. A bead like 10 Ohm @100 MHz but you need to check the graph for the bead to see how it behaves; for this purpose the peak impedance of the bead should be far beyond 100MHz. Again, tweaking the value in case of trouble passing EMC testing is a good idea.

[SiliconWizard]

What's the problem?

[wek]

I saw that, but there is no spec on the clock "quality".

I don't know what "clock quality" means.

This is a normal digital input as any other. You have thresholds and hysteresis specd in the same DS in I/O static characteristics table. From those and the slopes of your signal calculate min and max sampling point. Hysteresis is to remove effects of noise.

JW

[peter-h]

I'd be more worried about the ethernet side of the PHY leaking RF (multiples of 125MHz) into the ethernet cable.

I am using the RJ45 with integrated magnetics (Hanrun HR911105A) which should help quite a lot with EMC.

The 50MHz coming from the PHY doesn't have much of a sharp edge to begin with

It's as sharp as I am gonna get on a 350MHz DSO

However, on a Tek 2465B 400MHz analog scope and a Tek P6201 FET probe (1.5pF) it looks like this and is almost identical on both ends of the 22R resistor

What's the problem?

There isn't; I am just making sure I have margins

[nctnico]

I saw that, but there is no spec on the clock "quality".

I don't know what "clock quality" means.

Typically: frequency accuracy, rise/fall time, jitter, duty cycle and amplitude are the parameters that are relevant for a clock signal.

[nctnico]

I'd be more worried about the ethernet side of the PHY leaking RF (multiples of 125MHz) into the ethernet cable.

I am using the RJ45 with integrated magnetics (Hanrun HR911105A) which should help quite a lot with EMC.

Famous last words...  It would not be the first time an ethernet interface fails even with such a connector. You better make sure you have the option to include series resistors and capacitors to ground on the signal lines. If EMC fails, you can fix it quickly without a board respin.

[srb1954]

However, on a Tek 2465B 400MHz analog scope and a Tek P6201 FET probe (1.5pF) it looks like this and is almost identical on both ends of the 22R resistor

Am I seeing the occasional bit of jitter on the analog scope trace or it just an imperfection in the scope set-up?

If it is jitter this might be more critical as it could affect timing margins on the internal data recovery circuitry giving rise to errors in received data.

Check the clock signal again with your DSO in infinite persistence mode to see if jitter is present.

[T3sl4co1l]

Was going to say, that rounding could just be probe capacitance.  But the FET probe follow-up seems to confirm that.

Tim

[wek]

I saw that, but there is no spec on the clock "quality".

I don't know what "clock quality" means.

Typically: frequency accuracy, rise/fall time, jitter, duty cycle and amplitude are the parameters that are relevant for a clock signal.

Thanks.

In this particular case, the ETH MAC in STM32 does not care about any of these (well maybe amplitude and rise/fall times - through the decision levels), as long as the timing relationship between clock edges and Rx signal edges are according to the timing table in the STM32 DS. The MAC is a synchronous machine driven by this clock. Heck, it even does not care whether it's 50MHz or not. And again, it will spit out Tx signals towards PHY according to the timing table, related to the clock edges.

So, as long as those parameters given by DS are maintained, MAC will work perfectly OK.

JW

[peter-h]

Am I seeing the occasional bit of jitter on the analog scope trace or it just an imperfection in the scope set-up?

The "jitter" is not really there; the phone picked that up because it was over-exposed, or the trigger level was marginally set. I had a lot of trouble getting that pic while probing a tiny spot on the board.

that rounding could just be probe capacitance

Both probes are FET probes and I would expect the 1GHz £1600 LeCroy 0.9pF one to have less of an effect than the Tek 1.5pF one. I have just looked around the LC scope config and can't see any config for the probe, so this is a mystery.

I am much more inclined to trust the analog Tek scope.

Heck, it even does not care whether it's 50MHz or not.

That's a new one!

[T3sl4co1l]

Both probes are FET probes and I would expect the 1GHz £1600 LeCroy 0.9pF one to have less of an effect than the Tek 1.5pF one. I have just looked around the LC scope config and can't see any config for the probe, so this is a mystery.

Oh... that is mysterious, huh.

Tim

[nctnico]

Heck, it even does not care whether it's 50MHz or not.

That's a new one!

In theory that is true. I have software  bit-banged a MAC interface in some of my projects. However, it is possible a chip uses the absence of an external clock as a reason to produce an internal clock. In such a case the external clock frequency does matter.

[wek]

However, it is possible a chip uses the absence of an external clock as a reason to produce an internal clock. In such a case the external clock frequency does matter.

Not this one. The ETH/MAC in STM32 is known to be "frozen" when the external clock is not present.

Heck, it even does not care whether it's 50MHz or not.

That's a new one!

Why? It's not that much different from SPI, for example, as long as the clock-to-signal relationship goes. At the end of the day, MAC is also only a pair of shift registers (okay, a somewhat weird 2-bit variant), plus an extremely complicated loading/unloading machine.

That PHY won't be happy and other parties on the net won't talk to it, is a different thing.

JW

[SiliconWizard]

AFAIK the STM32F4 have Schmitt trigger on all inputs, so it shouldn't make a difference as long as the signal is not badly asymmetric.

[peter-h]

There is some dodgy stuff going on because the LAN8742 generates the 50MHz from the 25MHz, and how do you do that? With some funky logic and tweaked gate delays?

I would think the 50MHz is needed for 100mbps ETH - simple? How else could you do 100mbps? And the LAN8742 must be generating a 100MHz internal clock, no?

[wek]

With 100BASE-TX hardware, the raw bits, presented 4 bits wide clocked at 25 MHz at the MII, go through 4B5B binary encoding to generate a series of 0 and 1 symbols clocked at a 125 MHz symbol rate. The 4B5B encoding provides DC equalization and spectrum shaping. Just as in the 100BASE-FX case, the bits are then transferred to the physical medium attachment layer using NRZI encoding. However, 100BASE-TX introduces an additional, medium-dependent sublayer, which employs MLT-3 as a final encoding of the data stream before transmission, resulting in a maximum fundamental frequency of 31.25 MHz.

https://en.wikipedia.org/wiki/Fast_Ethernet#Copper

JW

[hans]

Where is the 25MHz coming from? The PLL of the STM32F4 chip? IIRC the PLL of the STM32F4 has quite a lot of jitter. I'm not sure if it's enough to cause issues, but I remember reading about it when I had issues trying to use it for an ethernet phy.

For example, the LAN8742 requires 150ps p-p jitter (not RMS) MAX @ 50MHz.
The STM32F4 has a cycle-to-cycle jitter of 32ps jitter at 50MHz and 40ps jitter at 25MHz. However, this is "TYP", and it's unclear where it's p-p or RMS. For what it's worth, the period jitter @ 120MHz is 200ps p-p and 15ps RMS, which are all lower values (logically) because the period time is much shorter.

So judging from this data, I suspect the listed spec @25M is RMS jitter, and that the p-p jitter is in the order of 500ps p-p. Can't recommended to use it for anything besides diagnostic or asynchronous.

[wek]

Where is the 25MHz coming from? The PLL of the STM32F4 chip? IIRC the PLL of the STM32F4 has quite a lot of jitter.

This is why the 'F4xx DS recommend not to use PLL as clock source for ETH PHY.

JW

[peter-h]

The above is the circuit I am using. It is also what ST use on their dev board.

The 25MHz comes from the 32F4 and goes to the LAN8742, which then sends back a 50MHz waveform to the 32F4.

So the LAN8742 contains a PLL to double the frequency.

[SiliconWizard]

The point was not that a PLL could not be used for this. PLLs are routinely used for very low jitter stuff. It's just that apparently the PLL in the STM32F4 itself is crappy.
I'm sure the LAN8742's PLL has proper characteristics.