I'm trying to bring up FNET on an MK60FN1M0XXX15 device, interfacing to a KSZ8895 ethernet switch.
I've configured the FNET stack correctly for our CPU and I've installed the relevant interrupt vectors as well as updating the configuration flags to indicate that vectors are not in RAM.
When calling the following function:
fnet_netif_init(FNET_CPU_ETH0_IF, &hw_addr, 6);
I get a hard fault following the auto-negotiation phase (fnet_fec.c, fnet_fec_init, line 400) and when trying to set the HW address (fnet_netif.c, line 304) the _fnet_netif_set_hw_addr() function returns with FNET_ERR with ultimately results in no interface being initialized.
Would this be indicative of a hardware issue? For example, bad connections between the Kinetis and the switch? Our hardware engineer has NOT connected the MDC/MDIO signals from the Kinetis to the KSZ8895 - are these necessary for correct operation?
Thanks in advance
jingpan thank you for your reply. To confirm, without connecting the MDC/MDIO signals, I will fail to get a network interface via FNET because the `fnet_netif_init` function uses the MDC/MDIO pins for communication with the KSZ8895?
Is the KSZ8895 known to work ok with the Kinetis K60 range and FNET? butok, are you able to advise please?
EDIT: Also, I need to add that I need the KSZ8895 to operate in MAC-to-MAC mode.
Note that the uTasker project supports the KSZ8863, which is a 3 port version of the switch. It uses the MDIO interface to realise the SMI mode of communication, which allows access to all internal registers but also SPI or I2C are possible (also having full internal register access). I do have a board with the device using I2C which simply polls the link state to get information about its connection type.
If SPI is connected you won't have any restrictions either.
As discussed in the networking document (link below) it integrates tail-tagging features of the device (including inter-operation with this mode and TCP/IP checksum off-loading, which requires some manipulation of the frames to allow it to work and take advantage of the Kinetis Ethernet's offloading features - which is a major performance advantage).
This allows the switch ports to be used as multiple individual (isolated) Ethernet interfaces to make the board appear as multiple isolated ones even though the Kinetis has only a single Ethernet controller (one can define which physical interfaces belongs to which networks or logical interface, or allow switch operation on individual networks too).
For basic applications it is also possible to not do any configuration to get switch operation since it will default to auto-negotiation switch mode, so communication is already possible.
For better, faster, cheaper product developments consider the uTasker developer's version, professional Kinetis support, one-on-one training and complete fast-track project solutions to set you apart from the herd : http://www.utasker.com/support.html
Thanks for your response and the uTasker links.
You mentioned that you've worked with the KSZ8863, did you have to perform anything special when configuring the device? I have since realised that I haven't written to the START_SWITCH bit of the CHIP_ID_0 register. Given that I'm using SPI mode, the datasheet indicates that the switch does not automatically start when using SPI mode - not starting the switch definitely isn't helping things!
My thoughts are that as and when I enable the switch, the default configuration should be enough to allow things to work out-the-box if you will.
Since FNET is not supported by nxp, I have no ideals about this protocol stack. But I believe there must be a PHY init code in FNET. So what you must to do is not only connect MDIO/MDC, but also do some config to port KSZ8895. IEEE-802.3 has defined some basic register in PHY. But each chip has there own special define. Sometimes this can not be ignored.
So if you don't config it, K60 will not know how to work with LSZ8895.
jingpan thank you for your response.
As mentioned in my previous comment, the KSZ8895 is running in MAC-to-MAC mode. The configuration is such that the KSZ8895 is configured for RMII (using strapping resistors) so therefore I do not think that we need the MDIO/MDC (the KSZ documentation seems to indicate this) but we do have SPI access to the device to configure alternate registers.