SPRADJ8 October 2024 AM3351 , AM3352 , AM3354 , AM3356 , AM3357 , AM3358 , AM3359 , AM4372 , AM4376 , AM4377 , AM4378 , AM4379 , AM620-Q1 , AM623 , AM625 , AM625-Q1 , AM62A3 , AM62A3-Q1 , AM62A7 , AM62A7-Q1 , AM62P , AM6411 , AM6412 , AM6421 , AM6422 , AM6441 , AM6442 , DP83822H , DP83822HF , DP83822I , DP83822IF , DP83826E , DP83826I , DP83848-EP , DP83848Q-Q1 , DP83867CR , DP83867CS , DP83867E , DP83867IR , DP83867IS , DP83TC812R-Q1 , DP83TC812S-Q1 , DP83TC813R-Q1 , DP83TC813S-Q1 , DP83TC814R-Q1 , DP83TC814S-Q1 , DP83TG720R-Q1 , DP83TG720S-Q1 , DP83TG721R-Q1 , DP83TG721S-Q1
Review the MAC statistics for errors between the DUT and the link partner to verify that basic transmission and reception of Ethernet packets was successful. Remember that even if basic transmission and reception of packets occur, there can be errors that are limiting network throughput. Some errors and solutions are discussed in this section.
Reviewing the MAC statistics indicates the number of packets sent, received, and the number of ones dropped with errors. Remember that MAC statistics are the results from monitoring the packets directly at the interface.
Analyzing the granularity of an individual packet when examining the interface statistics is not necessary. The main behavior to look out for are incrementing counts for RX and TX good frames and checking that there are no errors detected such as CRC, alignment, and so forth.
Incrementing TX and RX good frames statistics registers are an indication that sending and receiving packets between the MAC and the PHY is working as expected. This is also an indication that the MAC-PHY TX and RX clock is working correctly.
If the MAC statistics error counters are increasing, then there are packets being dropped at the interface. For example, a non-zero RX CRC error counter indicates that packets are received with CRC checksum errors and, as a result, dropped at the interface.
The following MAC statistics are in the context of a TI EVM directly connected to another board by connecting an Ethernet cable between the two link partners. Neither link of the two link partners are running a DHCP server to dynamically assign IP addresses. As Section 3 mentioned, you do not need to obtain an IP address to examine packet traffic. When examining traffic at this level, the key takeaway is to determine that no errors are observed during basic packet send and receive.
Once a link up on an interface is detected and the MAC driver is initialized, there is network traffic initiated in an attempt to acquire an IP address. The following TX and RX are the result of this network traffic, indicating how many packets were transmitted and received.
Specifically, the example snippet of the MAC statistic for TX packets is a result of connecting an Ethernet cable in between the two link partners. Once the link is detected to be up on an interface, the Linux kernel attempts to acquire an IP address. Some of the frames reported on the tx_broadcast_frames statistics are the DHCP request frames from the DUT that are used to acquire an IPv4 address. Furthermore, if the tx_good_frames statistic are incrementing, then this is a good an indication that packets were transmitted from the MAC of the DUT onto the wire.
A portion of an example ethool -S <interface> output showing the TX MAC statistics:
tx_good_frames: 19
tx_broadcast_frames: 2
tx_multicast_frames: 17
The following RX results from the MAC statistics reveal that packets are received as well after connecting an Ethernet cable. These particular statistics show that there are packets correctly received by the MAC. With this example, there is not an IP address assigned to the platform. The actual Ethernet protocol in use does not matter at this level. The main goal is to check that no corrupted packets are received and that packets are properly sent.
A portion of an example ethtool -S <interface name> output showing RX MAC statistics:
rx_good_frames: 104
rx_broadcast_frames: 10
rx_multicast_frames: 94
The next example gives a closer view on the RX error results from the MAC statistics. Here, there are no errors detected. However, if these error statistics are incrementing, it gives an indication to what particular errors caused the packets to be dropped at the interface. For Texas Instruments' processors serving as the DUT, the definitions of each MAC statistics counter can be found in the respective Technical Reference Manual (TRM) for that particular processor.
Portion of sample ethtool -S <interface name> showing RX error statistics:
rx_crc_errors: 0
rx_align_code_errors: 0
rx_oversized_frames: 0
rx_jabber_frames: 0
rx_undersized_frames: 0
Debug Suggestions:
ethtool
utility
tool is not returning any data for either link detection or MAC statistics,
then this indicates the MDIO communication to the PHY is not performing as
expected. Confirm the PHY device driver was loaded and correctly identified
in the Linux boot log. If the PHY was not correctly identified, consult
Section 6.Section Summary:
ethtool -S <interface
name>
for an interface provides data on the send and receive
process.ethtool
without the need for obtaining an IP address.