Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83TC811EVM: Ping dropping packets

Part Number: DP83TC811EVM
Other Parts Discussed in Thread: DP83TC811

I have an application that requires data to be carried over 2-wire and had built a prototype base on the DP83TC811EVM. The board has two circuits of Ethernet PHY (DP83822) connected to DP83TC811 and shared a common clock from a 1 to 4 clock buffer driven by  a 25MHz oscillator. 

When I loop back the 2-wire circuit (one as master and another as slave), the two Ethernet connections are able to have throughput of ranging from 60 - 90Mbps. However, there are occassional dropping of packets when I do continuously ping across the two Ethernet connections. I tried both small packet of 64 bytes and large packet of 1024 bytes, and the ping will time out randomly, rougly around once every 15 to 20 pings. 

Is this normal behaviour for the 2-wire PHY? If not what could be a possible cause of this behaviour? The 2-wire PHY as unmanaged as set a autonomous mode.

  • Hello Teck,

    Can you share the block diagram of the overall data path and clock scheme? Just want to make sure that I understood the data flow correctly.

    --

    Regards,

    Vikram

  • The block diagram is as above. The 25MHz crystal oscillator sources a clock buffer that distribute the 25MHz reference to all the Ethernet PHY and 2-wire PHY.

  • Hello Teck,

    Thanks for the diagram. It is clear to me now and we can try a few things to understand why ping is getting dropped. Do you also have access to registers of 811? We can try polling register 0x0001 and 0x0198 to check the quality of link over the cables used to do loopback. Also did you try using crystal instead of oscillator?

    --

    Regards,

    Vikram

  • Hi Vikram,

    We did not route out the access to the register.

    We were using MEMS oscillator with +/-50ppm accuracy initially, but could only send at less than 2Mbps across different boards. Now we replace the clock source using TCXO +/-2.5ppm. This is over spec according to the datasheet requirements, and able to get >60Mbps across different boards, but still the random dropping of packets persist. We test using ping command of various packet length. 

    The two ends of the 2-wire connects to a short flex printed cable (FPC) of 75mm and then connects using a pair of CAT5E twisted pair.

  • Hello Teck,

    Optimized system should give throughput much higher than 60Mbps (> 90Mbps for shorter IPG). I see that there are two differences in your application than the normal one :

    1. You are using non automotive standard cable. But as it is short so it may still be ok. But can you try using a single continuous cable instead of using interconnects?

    2. Using on board oscillator and not crystal. What is the expected jitter, duty cycle and rise/fall time on TCXO outputs?

    Do you have an LED on led_0 pin to indicate the link status? Without register access, this is the only way to check if something is marginal on the copper cable side connection? We should have register access to PHY to understand what is going inside the PHY and to try any configuration to improve the PHY's performance for your system.

    --

    Regards,

    Vikram

  • 1. Yes, I only need to connect the two boards over around 2m of CAT5E twisted pair. The FPC connects to the chassis mounted connector from which the twisted pair cable connects to another chassis with the connector.

    2. The TCXO partnumber is  ECS-TXO-2016-33-250-TR. This part is over spec in my opinion as we initially had very low throughput with MEMS oscillator.

    led_0 is available for the master board and is lighted when we connect the loop back wire.

    This picture is the link throughput test for 1min. In general, the sped seems ok, but when our problem is the ping test dropping packets randomly and we foresee will affect our real time udp traffic.

  • Hello Teck,

    For 811 normal usecase is automotive cable but if you are using CAT5 cable then can you solder it directly to the board?

    In your prototype based on 811 EVM, have you retained the whole hardware from PHY to connector as it is?

    Jitter spec will mainly be decided by the clock buffer you are using. What is the output jitter spec for it ? 

    Without reading the PHY register it will be difficult to find out that how the performance can be improved. We strongly recommend having read/write access to the registers. For time being, can you check if link led also stops glowing when you the ping is dropped?

    Another thing that you can do is to do the same test with two 811 EVMs instead of your prototype and see how the performance is.

    --

    Regards,

    Vikram

  • From the data throughput test, the performance of the prototype is sufficient for our application in terms data rate. We are characteristizing the 2-wire channel and will be getting the application to run over it in the later phase. Ping test is done to assess the UDP packet loss rate and that does not seem good so far. I do not have the actual EVM to perform the same ping test.

  • Hello Teck,

    We expect the PHY's performance to be same between your normal throughput test and ping test. We can look at it further with above suggested steps.

    --

    Regards,

    Vikram