ChibiOS Free Embedded RTOS

If the driver works correctly my idea is to backport it.

Giovanni

Thanks you kgysmits for the example.

I'd like to get rid of this external oscillator for the PHY, because we have very nice PLLs onboard of the STM32. My self-designed board with a DP83848 in RMII configuration works fine along with a STM32F1 clocked by 50MHz MCO output of the F1. This is also a recommended solution in the F1 datasheet.
Unfortunately, this does not apply for the F4. The datasheet only mentions the MII mode with 25MHz. When using RMII, an external oscillator is recommended. But why? There are even 2 PLLs in the F4, and the I2C PLL can be configured to output 50MHz on MCO2 pin. This is exactly what I would like to do.

Someone from the German board (http://www.mikrocontroller.net/topic/248796#2607279) tried to do this, but the Chinese PHY board did not work correctly when clocked by the F4...???

kgysmits, when you developed your board with low cost in mind, why did you use one of these expensive external oscillators? I hope it can be avoided.

Another possibility is to use a MII compatible PHY (DP83848, KSZ8051) with 25MHz, but it increases the pincount. I will do some experiments with ChibiOS lwIP demo and MCO clock as soon as my PHY board arrives.

Giovanni, I hope you're not angry that this becomes a hardware related discussion

Hardware discussions are absolutely welcome.

BTW, one of the ChibiOS customers created a control board based on the STM32F4-Discovery, it has the DP83848 in RMII mode clocked by a MCO. I should receive a sample soon and will be able to answer the question.

The only problem I see is that in order to generate 50MHz the MCU clock must be set to 150MHz.

Giovanni

This sounds just perfect. I'm looking forward to hearing your feedback.

You're right, if MCO (on the F4 it is called MCO1) pin is used with 50MHz, this limits the system clock to 150MHz. Loosing 10% of CPU power would be ok for me, but the main disadvantage is that the 48MHz USB clock cannot be generated any more.

So why not use the second PLL (for I2S), which is completely independent? It cannot be routed to the MCO1 pin, but it allows 50MHz on the MCO2 (PC9) pin while having full system clock and USB 48MHz.

By the way, I thought the new alternate function mapping in the F4 would be very powerful and offer more flexibility than the fixed remap options of the F1. But this is not always the case. I used the Ethernet remap on the F1, but this pinout cannot be configured on the F4. In fact, there is absolutely no Ethernet remap possible for the 100 pin package. So I have no analog inputs left

Using the 2nd PLL is a good idea. Probably raising the PLL input frequency to 2MHz would reduce jitter, so it is something to try in case of problems.

Giovanni

Micrel makes several PHY chips that generate the 50 Mhz clock internally with just a 25 Mhz xtal. They are enough cheaper and smaller than the DP83848 that they give you a net savings in cost and board space even with the xtal.

rubenswerk wrote:Thanks you kgysmits for the example.

I'd like to get rid of this external oscillator for the PHY, because we have very nice PLLs onboard of the STM32. My self-designed board with a DP83848 in RMII configuration works fine along with a STM32F1 clocked by 50MHz MCO output of the F1. This is also a recommended solution in the F1 datasheet.
Unfortunately, this does not apply for the F4. The datasheet only mentions the MII mode with 25MHz. When using RMII, an external oscillator is recommended. But why? There are even 2 PLLs in the F4, and the I2C PLL can be configured to output 50MHz on MCO2 pin. This is exactly what I would like to do.

Someone from the German board (http://www.mikrocontroller.net/topic/248796#2607279) tried to do this, but the Chinese PHY board did not work correctly when clocked by the F4...???

kgysmits, when you developed your board with low cost in mind, why did you use one of these expensive external oscillators? I hope it can be avoided.

Another possibility is to use a MII compatible PHY (DP83848, KSZ8051) with 25MHz, but it increases the pincount. I will do some experiments with ChibiOS lwIP demo and MCO clock as soon as my PHY board arrives.

Giovanni, I hope you're not angry that this becomes a hardware related discussion

We did not use the MCO output on the STM32F4 because of some errata document, but i can't exactly remember what the problem was. I can check with my fellow designers if you want to know.

The Micrel phy requires a 25MHz crystal only in RMII mode. It's the large SMD crystal on the right of the board layout picture.
The crystal used was a Farnell No.1611791, 38 eurocents a piece.

The errata was on the F2, MCO could not be used because of jitter, the errata disappeared on the F4 document.

Fixed or just missing? we will know soon enough. MCO out works on the F107 anyway.

Giovanni

thanks Giovanni, we were considering the F2 before ST offered us free F4 samples. I was scratching my head already because I couldn't find the problem in the F4 errata sheet.

Hi,

I'm the engineer who developed the commercial board being quoted by Giovanni. This board will be used into an industrial machine.
Well, IMHO, the F4 PLLs are inadequate to clock an ETH PHY.
I've done many tests before asserting this. I will briefly report it below.

On my board I use MCO2 on PC9 pin to clock the MAC and the PHY (DP83848) in RMII mode. I have been careful in designing the PCB traces, using transmission lines. Of course, I had no control on discovery board pcb.
I used the PHY management interface to check for receiver errors (register 15h).
Since the first tests I noticed a small number of symbol errors over the link at 100Mbits (1-10 errors every 5 seconds).
I immediately examined the clock quality and the signal integrity, while not having the tools to measure the jitter. On the scope (1GHz Te...nix) the MCO2 clock output showed itself to be seemingly good: excellent symmetry (45%), very small over/under shots, very little flickering. On the frequency side, using an Ag....t frequency counter, it was fixed at 50MHz +/- as a rock. It should be noted that this kind of measurement is an average, and isn't able to 'see' the jitter, if any.
Despite this fine picture, and in spite of all my attempts to make it work, i.e.: changing PLL, the receiver errors were there in all their stuffy presence.
To cut the Gordian Knot, I decided to inject an external clock directly on the discovery PC9 pin and then directly over the F4 pin. To do that I used a signal generator (an Ag....t 80MHz waveform generator) after configuring the PC9 pin as input, and ... wow ... the errors had vanished altogether. The RJ45 link led now blinks regularly. In this condition the DP83848 was able to withstand frequency variations up to 800ppm without errors and without losing the link!
This says a lot about the innocence of the discovery pcb layout. In fact, the electrical path was perfectly identical to that taken by the clock signal generated from the MCO2 output via F4 PLLs.
The bottom line is I think there may be a problem in the F4 PLLs (and I'll have to revise my board ).

Isidoro