VF61 second ethernet can't ping

I built a custom carrier board implementing 2nd ethernet port for VF61 using KSZ8041TL chip. I followed the Colibri VFxx 2nd Ethernet Reference V1.0A Schematics.pdf as a guide, and wired the KSZ8041TL to the VF61 exactly as shown on the reference schematic. I am running the Toradex console Linux image 2.8.6 with the unmodified vf610-colibri-dual-eth.dts device tree file.
I see both eth0 and eth1, and can set static IP addresses for the ports using connmanctl. I have set the primary ethernet port to IP address 192.168.1.123 and the secondary port to 192.168.2.123. I can ping 192.168.1.123 from a Windows computer (on subnet 192.168.1.xxx) connected to that port. But another Windows computer (on subnet 192.168.2.xxx) cannot ping the second port. I tried swapping the IP addresses and swapping the connections to the computers. Still I can only ping the primary ethernet port (eth1, the one with the PHY built onto the VF61). I cannot ping the second ethernet port (eth0).

After several attempts, ifconfig reports the following:
eth0      Link encap:Ethernet  HWaddr 00:14:2D:2E:48:52
          inet addr:192.168.2.123  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::214:2dff:fe2e:4852%lo/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1079 errors:0 dropped:0 overruns:0 frame:0
          TX packets:269 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:147538 (144.0 KiB)  TX bytes:36455 (35.6 KiB)

eth1      Link encap:Ethernet  HWaddr 00:14:2D:3E:48:52
          inet addr:192.168.1.123  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::214:2dff:fe3e:4852%lo/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:768 errors:0 dropped:0 overruns:0 frame:0
          TX packets:263 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:90025 (87.9 KiB)  TX bytes:37341 (36.4 KiB)

I see both RX packets and TX packets from both ports, yet I cannot ping (or otherwise communicate with) eth0. Is this a hardware or a software issue?

I have attached PDF copies of my schematic showing how I connected the KSZ8041TL to the VF61 and the ethernet jack. Any help would be appreciated.
Attachment

No answer yet? Toradex, please help me. My project is stalled until I can get the second ethernet port working.

Hi @irbsd

Sorry for the delayed answer.

I checked the hardware schematic. It seems to be correct.
Could you share your kernel config and the serial boot log?

Have you made any other changes to the Software. If yes, please share them.

Thanks and best regards,
Jaski

I’m not sure what you mean by the kernel config. Attached is the boot log (output of dmesg)link text

I am running a small application on the cortex M4 processor. I have also installed my main application as a service, but it is currently set to disabled so it is not running.

I have also configured uboot with the following commands:

env default -a
setenv defargs 'clk_ignore_unused initcall_blacklist=sram_init'
setenv fdt_fixup 'fdt addr ${fdt_addr_r} && fdt rm /soc/aips-bus@40000000/serial@40029000'
setenv set-io gpio set 103
setenv bootcmd 'run set-io;' ${bootcmd}
saveenv

ifconfig eth0 shows the following:
eth0      Link encap:Ethernet  HWaddr 00:14:2D:2E:48:52
          inet addr:192.168.1.123  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::214:2dff:fe2e:4852%2123791088/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2247 errors:0 dropped:0 overruns:0 frame:0
          TX packets:64 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:215703 (210.6 KiB)  TX bytes:8466 (8.2 KiB)

I still cannot ping the port from a Windows computer on subnet 192.168.1.xxx. Windows 10 reports destination host unreachable, Windows XP reports timeout.

HI @irbsd

Is it possible to ping other devices using the second Ethernet port?

Best regards,
Jaski

With eth0 set to 192.168.2.123 subnet 255.255.255.0 and eth1 set to 192.168.1.123 subnet 255.255.255.0 and my Windows 10 computer set to 192.168.1.4 subnet 255.255.255.0. I can connect my Windows 10 computer to eth1 and ping from Windows to 192.168.1.123 perfectly. I can also ping from the VF61 to 192.168.1.4 perfectly. This tells me that eth1 (the port with the phy built into the VF61) works just fine.

With eth0 set to 192.168.1.123 subnet 255.255.255.0 and eth1 set to 192.168.2.1 subnet 255.255.255.0 and my Windows 10 computer still set to 192.168.1.4 subnet 255.255.255.0 I connected my Windows 10 computer to eth0. In this case Windows cannot ping 192.168.1.123. It shows destination host unreachable. If I try to ping from the VF61 to 192.168.1.4 I see PING 192.168.1.4 (192.168.1.4): 56 data bytes, and nothing more. When I terminate the ping by hitting CTRL-C it reports 9 packets transmitted, 0 packets received, 100% packet loss.

So I can ping in either direction using eth1, but I cannot ping at all in either direction using eth0. Help.

Hi @irbsd,

I like to see how you routed the RMII Lines on you circuit board. There could be an issue.
also, the Ethernet MDI signals are analog differential pair signals which need to be routed carefully. Try to keep the MDI signals as short as possible and keep them away from digital signals. Try to avoid any stubs on these signals.

Also, I see that you are connecting the Center tap reference together and you are using one cap instead. High frequency wise this is not the same. Also to be future proof to have the ability via 0Ohm resistors to split the two references and have them not connected and each their own cap is a good idea especialy for the first ethernet. since newer Colibri modules might use voltage mode Phys instead of current mode once.

Also, keep in mind the Microchip offers a free design check for there Ethernet Phys. called LANCheck a microchip trademark.
https://www.microchip.com/design-check-services

Thanks and best regards,
Matthias

Also, check our PCB layout design guide.
https://docs.toradex.com/102492-layout-design-guide.pdf

Also I do not see where you did connect the shield of the MagJack.

Best Regards,
Matthias

The attached PDF file shows the layout of the VF61, KSZ8041TL, and dual MagJack. The board is a 4 layer board with internal 3.3V and GND planes. The shield of the dual MagJack is connected to chassis ground, which must be isolated from signal ground in our application. We did this in our earlier single ethernet design as well, and it caused no problems. Also, in this design both eth0 and eth1 are wired to the same dual MagJack with the same shield, and eth1 functions perfectly.link text

Could you tell me how your board connected to a network? Are you using switches or have a direct connection? If you are using switches do you have 2 separate one for each subnetwork or both eth0 and eth1 connected to the same switch? Could you also try to disable speed auto negotiation and set it manually to 10 Mb using ethtool?

HI @irbsd

Thanks for your Input. I tested already on our reference dual Ethernet Board where the pinging and the Ethernet connection is working fine with Bsp 2.8 and the dual-eth devicetree on both Ethernet Ports.

The difference between your board and our is that your are not using exactly the same PHY. I am not sure if you need a different driver/settings for this PHY. Unfortunately this is hard to say without having the custom hardware.

The best would be that you ask Microchip what is the difference between your and Toradex’s PHY. If the PHY you are using needs special settings/driver on Linux Side. Further you can also try to get an Evaluation Board for your PHY and check if you can connect this to the Vybrid module using the Colibri Evaluation Board.

Thanks and best regards,
Jaski

As suggested I opened a support request with Microchip design check services. I sent then the complete schematic on my dual ethernet carrier board. They reviewed the design and told me they could find no problems.

I ran further tests using an unmodified Toradex Linux 2.8 console image with an unmodified colibri dual ethernet device tree file. I can still ping only eth1 (the built in interface), but cannot ping eth0 (the additional interface).

I have run tests with a direct ethernet connection between my board and a Windows computer, and I have run tests going through a switch (using subnet 192.168.1.xxx only for the switch). I see the same results with or without the switch.

With Wireshark running on the Windows machine, if I attempt to ping from Linux to Windows, Wireshark sees no packets received from the Linux machine. If I attempt to ping from Windows to Linux, Wireshark sees the packets sent from Windows, but sees no packets coming back from Linux.

I then tried one more test. With an oscilloscope on the RMIITX0 data signal I see no data whatsoever with no pings in progress (as expected). Then I sent some pings from Windows to the Linux board, and observed a burst of data on the RMIITX0 signal each time Windows sent a ping. This tells me that the ping was received and processed properly by the Linux board, and the VF61 module did try to send an answer to the ping. However, Wireshark received no packet from the Linux board. This tells me that the packet was not properly transmitted by the Linux board. So receiving appears to be working, but transmitting is not working.

Since I followed the Colibri dual ethernet reference design exactly, and am running unmodified Toradex Linux 2.8 console with unmodified Toradex Colibri dual ethernet device tree file, I would like you to try this same software configuration on one of your Colibri Dual Ethernet reference design boards and see if you can ping both ethernet ports. I look forward to your results.

According to the Toradex VF61 dual ethernet reference schematic (Colibri VFxx 2nd Ethernet Reference V1.0A Schematics.pdf) the PHY used is a KSZ8041NL. I am using a KSZ8041TLI, which essentially the same part but in a 48 lead TQFP package instead of a 32 pin QFN package, and industrial temperature range. We are not able to solder QFN packages, but are able to solder TQFP packages.

My testing seems to indicate that I can receive ethernet packets fine, but cannot transmit ethernet packets. I am beginning to suspect the RC filters on the TXD0 and TXD1 signals. The Toradex reference schematic shows 33 ohm and 22 pF RC filters on each of these signals, so that was what I implemented. I would like to know the following:

  1. What is the exact part number of the PHY chip being used for the ethernet port which is included on the VF61 module (the built-in ethernet port).?

  2. Does the built-in ethernet PHY on the VF61 module use an RC filter on the TXD0 and TXD1 signals?

  3. If the answer to question 2 is yes, what are the values of the resistor and capacitor used on the RC filters?

Hi @irbsd

You could be right about the RC filters on TXD0 and TXD1 signals. The values for those filters in the reference design are the values which works for our design. Depending on your design and Layout, you might need different values, since the resistance varies with the length of the track on the layout.

This RC Filter is only needed due to the Errata e8052 mentioned in the Hardware Development Guide.

Further, you have to use an active testing probe for the measurement of the TXD0 and TXD1 signals.

Best regards,
Jaski

Did you not read my previous post? I asked three specific questions. I even numbered the questions 1, 2 and 3. Yet you did not answer any of them. I am trying desperately to get some information to help me solve this problem, and I am finding it difficult to get the information I need.

Can you PLEASE answer my three questions from my previous post?

Also, do you really think that the resistance of the track on my layout has a significant effect on the RC time constant? The maximum track length on my layout (for the TXD0 and TXD1 signals) is 2.13 inches. The track width is 0.010 inches, and the copper is 1 oz/square foot. The track resistance works out to 0.106 ohms. This adds only 0.32% to the series 33 ohm resistor. This is insignificant compared to the tolerances of the resistors and capacitors, which are +/- 1% at best. I think we cane safely ignore the resistance of my PCB tracks!

Hi

I gave you a general answer but if you want to be specific, here are the answers:

  1. What is the exact part number of the PHY chip being used for the ethernet port which is included on the VF61 module (the built-in ethernet port).?

KSZ8041NL

  1. Does the built-in ethernet PHY on the VF61 module use an RC filter on the TXD0 and TXD1 signals?

Yes, due to the Bug in the SOC.

  1. If the answer to question 2 is yes, what are the values of the resistor and capacitor used on the RC filters?

R=33Ohm, C= 22pF.

Did you measure the signals on the TXD0 and TXD1?

Best regards,
Jaski

Yes, I did look at the TXD0 and TXD1 signals with an oscilloscope. Unfortunately I do not have an active probe, so I had to use a standard probe in x10 mode, which has a 10 M ohm / 20 pF impedance. I found the signals looked very bad. The RC time constant was obviously way too long. The signals did not even come close to GND or VCC before starting to transition to the opposite state again. I realize the scope probe adds 20 pF, and adds to the signal distortion, but the signal was so bad that I knew it couldn’t work even with no scope probe on the signal.

I decided to modify my device tree file to reduce the output impedance of the pins used for the TXD0 and TXD1 signals. The sample Toradex dual ethernet device tree file was initializing those pins with an output impedance of 50 ohms. Note that this is in series with the external 33 ohm resistor, for a total output impedance of 83 ohms. I change the device tree file to initialize those pins with a 37 ohm output impedance. The signals looked much better on my oscilloscope, and I found I could actually ping the port! However, the port would stop functioning as soon as I touched a scope probe to either of the TXD0 or TDX1 pins.

Next I reduced the pin output impedance to 30 ohms. The signals looked better still, and I could ping the port with or without a scope probe on the TXD0 or TXD1 pins. Finally I reduced the pin output impedance to 20 ohms. The signals looked better still, and the port continued to function with or without a scope probe touching the pins.

I suspect that having the TXD0 and TXD1 signals connected outside the VF61 module (i.e. routing them through the SODIMM socket) adds considerable capacitance to these signal lines. While the DC resistance is negligible, the added capacitance is enough that the port will not function with the recommended 33 ohm and 22 pF RC filter unless the pin output impedance is reduced significantly. I could not find a specification of the pin capacitance of the KSZ8041TL in a TQFP package. Perhaps this increases the RC time constant a little bit as well. However, reducing the pin impedance to the minimum of 20 ohms in the device tree file has resolved my problem.

Hi @irbsd

Perfect that you found a solution. Thanks very much for your valuable feedback.

Best regards,
Jaski