STM32F4 RMII ETH external clock source

[totti001]

Posted on September 23, 2013 at 16:03

Hy all,

I've a question about the RMII mode at STM32F4 mikrocontrollers. I checked the datasheet and the stm3240g-eval user guide.

So the eval board user guide say that at page 19:

''In RMII mode the 50 MHz clock must be provided to Ethernet PHY by an external oscillator. This oscillator (ref SM7745HEV-50.0M or equivalent) must be soldered on the U3 footprint (located under CN3) and jumper JP5 must be removed. This oscillator is not provided with the board.''

But the stm32f4 datasheet show that the external 25MHz is enough for the ETH RMII mode via the MCO pin.

My question is what is the correct? The ETH RMII mode need an external 50MHz clock source or I can use the MCO pin, with only one 25MHz clock source for the mikrocontroller?

#worst-forum-software-ever

[Amel NASRI]

Posted on September 23, 2013 at 16:13

Hi Janos,

Discussion in this

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Can%20STM32F207xx%20Generate%2050MHz%20Clock%20for%20RMII%20Ethernet%20PHY&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=68

may be helpful for you.

-Mayla-

[waclawek.jan]

Posted on September 23, 2013 at 16:35

Szia Janos,

> But the stm32f4 datasheet show that the external 25MHz is enough for the ETH RMII mode via the MCO pin.

Surely not, or have I overlooked something? Please provide the number of page where it is said so...

Should you decide for the external oscillator, you might want to read my comments on the topic, too...

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy.st.com%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fEthernet%20through%20RMII%20on%20STM3240G-EVAL%2c%20anyone&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=258

JW

[totti001]

Posted on September 23, 2013 at 17:32

At page 175 the image show that.

Thank you for the link, I read it.

[Tesla DeLorean]

Posted on September 23, 2013 at 17:40

Depends on the PHY. The LAN8720 can take a 25 MHz source. If the processor isn't running at a multiple of 25 MHz, presumably directly from HSE which is.

To get 50 MHz out of MCO (PA8) you'd need to run the processor at a multiple of 50 MHz (ie 150 MHz for the F4), you could perhaps also use PLLI2S and MCO2 to get 50 MHz independently of the CPU clock if you didn't care for I2S.

[waclawek.jan]

Posted on September 24, 2013 at 09:22

> Depends on the PHY. The LAN8720 can take a 25 MHz source.

Yes, but the venerable DP83848C which is used on the STM3240G-EVAL board is not of that kind.

> To get 50 MHz out of MCO (PA8) you'd need to run the processor at a multiple of 50 MHz (ie 150 MHz for the F4),

> you could perhaps also use PLLI2S and MCO2 to get 50 MHz independently of the CPU clock if you didn't care for I2S.

I would be wary of the usage of PLLs inside a SoC for this purpose. While the datasheet specifies ''some'' jitter for PLL as ''Main clock output (MCO) for RMII Ethernet'', it does not say what are the conditions for this (namely used crystal and PLL settings, or any other if applicable), specifies it as ''cycle to cycle at 50MHz on 1000 samples'' as 32ps which is most probably RMS and not peak-to-peak nor cumulative; and it's a typ not a max. I'd also expect some coupling between the digital functions and the PLL. There's also an alarming footnote, saying ''the use of 2 PLLs in parallel could degraded (sic) the jitter up to +30%. All in all, even if the PHY's documentation (AN-1548) claims workability up to 4ns jitter and its datasheet guarantees working with 800ps jitter, I personally go for an ''extra'' oscillator, rather than potential stability/reliability problems. YMMV.

Another option is to feed the STM32's clock input from the same oscillator (if it supports the load); or go for some of the modern PHYs working out of 25MHz (and supporting a 25MHz crystal, too), as Clive suggested above. The EVAL board is unusable in this respect, but there are 3-rd party devboards out there featuring such PHY.

JW

[RMari]

In a short investigation of postings related to internal PLL-output usage to supply a clock to a LAN8720A, this one fits perfectly to discuss my experiences.

I have designed a board with F407 and in order to be able to update firmware via the USB bootloader I am forced to use a crystal < 16 MHz (I chose 12 MHz). Therefore I have set up I2S PLL to output 25 MHz. This runs quite wel, until... two board samples from a small proto test batch showed spurious connection issues (e.g. ping packet loss).

I felt safe by Refmanual (RM0090) 33.4.2 section "MII clock sources", where PLL usage is mentioned. And that should not depend on MII or RMII. Above that, PLL usage with other MCU (e.g. NXP) is quite a usual practice.

After problems arose, I found the following interesting hint in the RM: It is recommended to select a frequency of 2 MHz to limit PLL jitter. (I realized that 1 MHz is indeed quite low compared to other MCUs that I used)

After scaling up to 1.5 MHz (from 1 MHz), the connection issues disappeared. Then I selected 2 MHz and as expected, the result is also okay, but should be expectedly more reliable, also at elevated temperature. Note: in the "problem" case, the link activity LED blinks quite rapidly also when no connection is made. I obeyed that applying freeze spray on the MCU casing let the LED blink normally (apparently, the jitter increases with temperature).

Given the apparent headroom at 2 MHz PLL input clock, I tend to treat that as sufficient.

(more/other detailed infos on Microchip forum - due to LAN87xx being theirs: https://forum.microchip.com/s/topic/a5CV40000001rYXMAY/t397529)

 

[waclawek.jan]

Interesting piece of information, thanks - although I maintain what I've said 11 years ago, that you should've gone for a second dedicated crystal/oscillator for ETH/PHY.

JW

[waclawek.jan]

Posted on September 24, 2013 at 09:23

Double post, courtesy of this crap forum software...

Oh, and the ''worst forum software ever'' tags got removed from previous posts... I am disgusted.