using KSZ8863 with lwip

[tbiberdorf]

Has anyone been able to connect the Mitrel switch KSZ8863 to  K64F with MCUXpresso + lwip?

I have the PHY register communication working with the KSZ8863 and I believe I'm able to instruct it to auto-negotiate.  But after I init my lwip stack I don't see any network traffic being received.  Is there any other special register setup needed in the KSZ8863 for network traffic to start?

Thanks

Terry

[mjbcswitzerland]

Hi Terry

If you have the PHY's HW straps set up in their standard way you can communicate without commanding anything.

You can get KSZ8863 code from the Open Source uTasker project, which also allows the KSZ8863's tail-tagging mode to be used to create multi-homed and multi-interface interface (two independent Ethernet interfaces on one Ethernet controller with multiple IP settings).
http://www.utasker.com/docs/uTasker/uTaskerNetworking.pdf

The project has been used in numerous industrial products (based on K53, K60, K61, K64, K65, K66 and K70) whereby (apart from one or two pin configurations and clock settings - notably the K65/K66) the code is compatible on all.

Regards

Mark

uTasker developer and supporter (+5'000 hours experience on +60 Kinetis derivatives in +80 product developments)
Kinetis: http://www.utasker.com/kinetis.html

[tbiberdorf]

Hello Mark:

I was able to download the basic project and get it to run on the FRDM-K64 board.

I believe I was also able to modify the needed configurations to match our development boards clocks (we have a 24Mhz crystal).  I created a new board type using examples between the FRDM-K64 and TEENSY_3_5 to match our clocks.  But somewhere in the nested macros I'm missing something in the configuration to support the KSZ8863.  My code only gets as far as fnMIIread() where it will fault waiting for the read action to complete.

Terry

[mjbcswitzerland]

Terry

Make sure that _PHY_KSZ8863 is defined "somewhere".
You can then also choose between PHY_MICREL_SMI (of not) since you need the SMI interface (which is partly bit-banged) in order to use all of the PHY's features.

The only reason for a failure in the fnMIIread() that I know is a missing clock to the module (however, again check the PHY_MICREL_SMI setting because this routine is dependent on it).

Disable STOP_MII_CLOCK (if enabled) for first work since this allows the MII clock to be stopped between activity (to reduce power and radiation) but there is a risk that if fnMIIread() is being called without first enabling the clock again it will hang. If the line state is being polled (this is an option when no interrupt line is used) this may be possible if not set up entirely correctly - disabling this ensures no potential issue.

Note that the Ethernet driver 'expects' the PHY to be recognised and will power off the interface again if it doesn't match.

if ((ulPhyIdentifier & PHY_MASK) != (PHY_IDENTIFIER & PHY_MASK)) {

should be checked as being true (PHY connection is good) before continuing.

It can however be disabled if ALLOW_PHY_ERROR is set, which would allow HW with no PHY communication capability to still use the Ethernet.

Regards

Mark

[tbiberdorf]

Hi Mark

This was a big help, I'm now seeing the identifiers from the KZS8863.

How do I change the debug port?  I know the FRDM-K64 dumps data to the UART1, PTB16 and PTB17.  I cannot find the configuration needed to change it for my board?

Thanks

Terry

[mjbcswitzerland]

Terry

FRDM-K64F uses these pins (it is however UART0).

To use a different UART you can set the value in the file app_hw_kinetis.h where you will find the UART defined by

#define DEMO_UART    0

You can change it to any other available UART (1..5)

However, there are various pin muxing options and you may need to match to your HW.
eg. if you choose UART 3 there is a default pin pair  which can be optionally overwritten with defines like

      //#define UART3_ON_B                                               // alternative UART3 pin mapping
      //#define UART3_ON_F                                               // alternative UART3 pin mapping on port F

which will move them to port B or F as desired.

To see the choice, take a look in the routines fnTxOn() and fnRxOn() in kinetis_UART.h.
The options change to a degree for different processors and if you find a set missing it is simple to extend the choice - just add a new option in the style of

_CONFIG_PERIPHERAL(B, 17, (PB_17_UART0_TX | UART_PULL_UPS));     // UART0_TX on PB17 (alt. function 3)

eg. if there were a UART0_TX possibility on alternative function 6 on PTC19 (which there isn't in reality) one would add

_CONFIG_PERIPHERAL(C, 19, (PC_19_UART0_TX | UART_PULL_UPS));     // UART0_TX on PC19 (alt. function 6)
which requires PC_19_UART0_TX to be added to kinetis.h with the value PORT_MUX_ALT6.

Since (in this case) PC_19_UART0_TX is not a valid pin-out for UART0 it will never actually exist in (or be added to) the header) so trying to move to an inappropriate pin will always result in a build error (a build error is always better than an error on the board that then needs in circuit debugging to work out why).

I am however a little worried about the fact that mentioned a 24MHz clock in your design. The K64 NEEDS a 50MHz clock to be able to operate with Ethernet since it is used to synchronise the PHY with the Ethernet controller. Is this a possible reason why you had difficulties with your original SW?

In comparison: The K65/K66 has a new Ethernet clock input that can be used instead, which allows the processor itself to be clocked with 24MHz (for example) since its HW USB requires the 24MHz (or one of a couple of other potential frequencies) to be available to generate its internal HS USB clocks from. In this case the developers needed to allow the Ethernet to be decoupled from the CPU's clock so that the two requirements could be met at the same time.

Regards

Mark

[tbiberdorf]

Mark

Thanks for the direction to getting the debug port working, I'm now seeing some status being returned.

As for the 50Mhz question, we're following a previous K60 design with a KSZ8081 where the KSZ8081 (and now in this case with our KSZ8863) has its own 25Mhz crystal, this in turn sends a 50Mhz sync OSC to the K64's ENET_1588_CLKIN, which I have configured in kinetis_ENET.h 

   _CONFIG_PERIPHERAL(E, 26, PE_26_ENET_1588_CLKIN);

You may be correct on a problem with the h/w, my debug output after reset does not reflect a network connection.

From my KSZ8863 build, I get the following message after reset:

   Hello, world... GC100-K64F [Software]
   Static memory = 0x00001080
   OS Heap use = 0x3840 from 0xc000
   Initial stack margin 0x00002ddf

When I run the branch of code on the FRDM-K64 board I see that it detects the ETH0 link is present:

   Hello, world... FRDM-K64F [Lockup]
   Static memory = 0x00001078
   OS Heap use = 0x3838 from 0xc000
   Initial stack margin 0x00002de7
   Eth0 link-up 100 full-duplex

This seems to be giving me the indication that the KSZ8863 network signals are not being passed to my K64.  I can see that it does communicate via the MDIO/MDC pins so I know the K64 does detect that its there.  Reading though the KSZ8863 documentation it talks about a bypass that does not provide communication to port 3 which is in turn sent to my K64.  Could this be happening?

Thanks again 

Terry

[mjbcswitzerland]

Hi Terry

In fact I haven't used the K64 clocked from the 1588 clock input before and I though that only the K65 and K66 allowed this but in fact the K64 is the same, so your circuit is OK.
Nevertheless, in order to use this you not only need to configure the pin but you also need to select the input in the SIM_SOPT2 register. I checked the open source version and found that it didn't do this so checked in a change to do it correctly.

    _CONFIG_PERIPHERAL(E, 26,  PE_26_ENET_1588_CLKIN);                   // select the pin function for external 50MHz clock input
    SIM_SOPT2 |= (SIM_SOPT2_RMIISRC_ENET_1588_CLKIN);                    // select the ENET_1588_CLKIN as clock source (rather than EXTAL)

You can simply add SIM_SOPT2 | 0x80000; if defines are missing.

The fact that you don't get a link up is not connected to the port 3 or the RMII. You will get a link up when the PHY detects the Ethernet, even if it doesn't actually communicate yet.

Note that if you enable the define DEVELOP_PHY_CONTROL in the file debug.c it will add a PHY register dump. I use this will new PHY types to see their register content when disconnected or connected to certain connection types (10/100M duplex/simplex). I think that it is usable for the KSZ8863 since all PHYs have a few base registers that are defined by IEEE.

The next question is whether you have configured the link detection interrupt (which will also need the correct K64 port to be set) or are polling it.
The FRDM-K64F doesn't connect an interrupt line and so uses the polling method, which is configured with:

        #define PHY_POLL_LINK                                            // no interrupt line connected so poll the link state
        #define INTERRUPT_TASK_PHY     TASK_NETWORK_INDICATOR            // enable link state output messages

which configures the network indicator task (NetworkIndicator.c) to check the state periodically and print out its details each time there is a change. This is the easiest method since it neither requires a port interrupt to be used nor the interrupt to be enabled in the PHY.

In any case the link state change is the next thing that will confirm the HW is connected correctly to the Ethernet.

Regards

Mark

[tbiberdorf]

Hi Mark

I'm another step closer, but not there yet.

After making both the clock enable change you suggested, RMII clock source select:

 SIM_SOPT2 |= 0x80000;

I also added the selection to use the IEEE 1588 timestamp clock source select:

 SIM_SOPT2 |= 0x300000;

I also found that my code still had the following define in place (so I took it out):

#define _KSZ8081RNA

Note: My code still have the define for: _PHY_KSZ8863, and I do have the define for PHY_POLL_LINK

Now my code is getting as far as detecting the Eth0: 

   Static memory = 0x00001080
   OS Heap use = 0x3840 from 0xc000
   Initial stack margin 0x00002d9f
   Eth0 link-up 10 half-duplex

But I still fail to receive a valid IP address and DHCP reports that it fails to complete.  So my belief is that there is no ethernet communication is getting through.

Thanks

Terry

[mjbcswitzerland]

Hi Terry

Are you expecting 10Mb/s half-duplex? This would be an old hub connected.

Next check is to see whether the EMAC is detecting any activity. To do this go to the I/O menu (3) and do "md 400c0284 l 23" which will display the RX MIB counters (see the description of these in the user's manual). These are counters in the HW that count good and bad frames.

There is also a block for Tx counters.

In the LAN manu (1) do

"arp -a" to see whether any IP addresses have been collected form the network activity and try to  ping something from the board with "ping 192.168.0.1" for example.

Good luck

Regards

Mark

[tbiberdorf]

Hi Mark

This is a very interesting.  I found that when I moved the same network cable between my hardware and my FRDM-K64 board that my KRDM-K64 board reports back the expected statistics 
Eth0 link-up 100 full-duplex
DHCP successful: 192.168.50.101

but my hardware seems to be stuck reporting the: 
Eth0 link-up 10 half-duplex

DHCP failed

So something is still not correct in the configuration.  I'm still trying to better understand just what configuration settings the KSZ8863 should power up with, as something still does not seem correct.  I've been attempting to read the special registers of the KSZ8863 and the results do not seem correct.

Terry

[tbiberdorf · Accepted solution]

Hi Mark

The problem has been found.  It had to do with the Advanced Control Registers, Forward Invalid VID Frame and Host Mode Register 198, in the KSZ8863.  The power up straps should have set the P3 RMII Clock to use the Internal, but for some reason it was still set to external.  When I changed the register to use the Internal clock all network communication started to work!

Thanks

Terry