9 Follow the Packet

Once an Ethernet link is established between two link partners, one can trace the steps of the packet sent from the DUT to the link partner and then packets from the link partner back to the DUT. This only works if you have access to the Ethernet MAC statistics on both sides of the link. This is also made simpler if the network topology consists of a direct connection shown by Figure 3-1.

As described in Section 8, you do not need to set IP addresses to initiate network traffic. When using the TI default filesystem on the DUT, there is an attempt to acquire IP addresses after a link is detected. This network communication is sufficient to trace successful reception of transmitted packets from the DUT to the link partner. Broadcast packets from the link partner are sufficient to prove that no corrupted packets were received on the DUT.

Before connecting an Ethernet cable between the DUT and the link partner, use ethtool to verify that the Ethernet MAC statistics are 0 for the RX and TX counters. The recommendation is to use a Linux® operating system (OS) on the link partner platform. This can be another working EVM or an Ubuntu PC. ethtool is only available for platforms running a Linux OS.

As Figure 9-1 shows, start with examining if packets sent from the DUT are received by the link partner by using ethtool on the link partner and checking the RX counters. If the link partner is not running on a Linux OS, ethtool is not available. The RX counters give an indication to how many good frames are received and more importantly, how many corrupted frames are received. If the packets received are error free, then the transmit path from the DUT is working as expected. If the RX error counters on the link partner are nonzero (for example, RX CRC errors), then a conclusion can be made that there is an issue to investigate for the transmit path of the DUT.

Figure 9-1 DUT Transmit Path

There are typically two issues that can be observed by a receiving link partner: no packets received or CRC errors. If the link partner is not receiving any packets, then something is corrupting the Ethernet frame from the DUT to the point of the frame not being recognized by a MAC interface. When either no packets or CRC errors are detected, the MAC or PHY interfacing on the DUT needs to be examined more closely.

Analyzing the receive path to the DUT is similar to how the transmit path from the DUT is analyzed. Observe in Figure 9-2, that the receive packet count and some errors that can happen. As indicated previously, a receive path is functioning correctly when the error counters are zero and the received good frame count is increasing. At this level, it does not matter the types of packets, just that the packets are being received and no error packets are being detected.

Figure 9-2 DUT Receive Path

There are usually two possible causes of when the Ethernet MAC receive error counters are nonzero. The most common is due to an incorrect RX clock timing, when the PHY interface mode is RGMII. The second most common issue is a hardware issue such as incorrect in-line resistor values or a board layout issue.

If the error counters from analyzing the DUT transmission and reception paths are zero, then basic Ethernet packets are being sent and received error free. At this point, a DHCP server can be added to assign IP addresses to the DUT dynamically or an IP address can be assigned statically with ip addr add <ip address/subnet mask> dev <interface name> on the DUT. However, after this step is performed, if there is still no IP address assigned when the link is detected as up and the Ethernet MAC statistics are not showing any errors, then the next step is to consider possible network reasons. Review Section 10 for examples of network issues.

Section Summary:

• This section shows how to analyze basic Ethernet packet transmission and reception using the FTP method.
• If packets are error free and no IP address is obtained, then this can allude to a network-level issue.