FRDM-K64F mdio clock

[dsherman]

I'm having a little trouble with the mdio clock on the FRDM K64F.  According to the K64 reference manual, the MDIO clock is derived from the bus clock.  Is this correct?  I can get the ethernet working under FreeRTOS and FreeRTOS-TCP, but only if I run the FRDM-K64F at 50MHz with a 50MHz bus clock.  If I try to use it at 120 MHz with a 60MHz bus clock (FLL engaged external mode), I calculate the MDIO clock and use 11 for the ENET MSCR MII_SPEED register (60/2.5 = 24, (24/2) - 1 = 11).  However, I get 5 MHz out for the MDIO clock, and I cannot read the phy ID correctly.  I'm pretty sure the bus clock is correct, as I have set the clock divider registers accordingly.  I did see an older thread about MDIO communication problems on the FRDM-K64F, so I have the pull up enabled on the MDIO line.

[mjbcswitzerland · Accepted solution]

Hi David

The formula for the value to set is

MSCR = (((ETHERNET_CONTROLLER_CLOCK/(2 * MII_MANAGEMENT_CLOCK_SPEED)) - 1) << 1);

where ETHERNET_CONTROLLER_CLOCK is the system clock (not bus clock) and MII_MANAGEMENT_CLOCK_SPEED is the speed you want (2.5MHz is typically).
With 120MHz system clock this gives MSCR = 0x2e (MII_SPEED is 0x17, which gives a divide by (0x18 x 2) or 48)

120/28 = 2.5MHz

If you use the system clock instead of bus clock you will also get the correct speed.

Possibly your difficulty with the phy is that the clock speed is too high, but could you explain your FLL engaged external mode (which reference input)? Since the 50MHz oscillator is needed for RMII why do you not use the PLL mode?

Attached is a FRDM-K64F binary which runs at 120MHz system clock with 60MHz bus clock which shows exact 2.5MHz MDIO clock. It has a default IP of 192.168.0.5 (configurable in the LAN menu on the OpenSDA VCOm connection at 115200 Baud).
In the MQTT menu you can connect to MQTT brokers and subscribe to topics and publish messages (and see message reception from other broker IoTs).
As you see, I am also playing with the FRDM-K64F today and will be demonstrating a turn-key secure socket (TLSv2) solution for MQTT on the K64 shortly that is fully compatible with Amazon AWS with client certification authentication....

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html
Kinetis K64:
- http://www.utasker.com/kinetis/FRDM-K64F.html
- http://www.utasker.com/kinetis/TWR-K64F120M.html
- http://www.utasker.com/kinetis/TEENSY_3.5.html
- http://www.utasker.com/kinetis/Hexiwear-K64F.html
Networking: http://www.utasker.com/docs/uTasker/uTaskerNetworking.pdf

Free Open Source solution: https://github.com/uTasker/uTasker-Kinetis
Working project in 15 minutes video: https://youtu.be/K8ScSgpgQ6M

Professional Kinetis support, one-on-one training and complete fast-track project solutions: http://www.utasker.com/support.html

[dsherman]

Thanks Mark, I was confused by the clock source because the page that describes the formula and gives an example specifically says:

For example, if the internal module clock (that is, peripheral bus clock) is 25 MHz,
programming MII_SPEED to 0x4 results in an MDC as given in the following equation:
MII clock frequency = 25 MHz / ((4 + 1) x 2) = 2.5 MHz

If I use 23 instead of 11, the MDC is 2.5 MHz and I can read the ID correctly.  Also, I correct myself; I had configured it for PLL operation and not FLL.  Thanks!

[mjbcswitzerland]

David

I don't think that the "internal Module Clock" is actually defined anywhere specifically but from experience is is always the system clock on all Kinetis processors with Ethernet.

The example with 25MHz is a little strange but I expect that it originates from old Coldfire documents since the Ethernet controller in the Kinetis originates from there (although it may have been used in another series before the Coldfire too (?)). At the time, 25MHz may have been a typical clock speed, whereby today 100MHz and greater would be more suitable.

I have also used the same formula in Coldfire V2 projects (since 2005), where the clock is taken from the PLL output - that is, it is also the system clock there too.

Regards

Mark