Introduction
In this article, we discuss some debugging tips when the Ethernet is not working as expected.
When working with the Ethernet peripheral on an STM32 either through a costume board and firmware or with one of ST provided boards and middlewares, it is crucial to get a deeper practical understanding of the internal processing scheme of Ethernet to be able to solve problems and find which component is blocking the proper workflow of the Ethernet peripheral.
1. Hardware and PHY related problems
1.1. How to ensure that PHY is working correctly
In the PHY library (lan8742.h), the LAN8742_GetLinkState function is utilized to check the state of the PHY device specified in the parameters. As illustrated below, this function returns status codes that indicate the link status. It informs us if the link is up or down, the result of the autonegotiation process, and the selected speed and duplex settings. Additionally, it could signal if an error occurred during the read/write process to or from the registers.
When we are not getting the proper response from PHY, we can focus on the following potential causes
- The crystal oscillator providing the source of a clock, which is propagated to the Ethernet peripheral is present and within the PHY specifications
- Depending on the mode we are trying to configure (MII, RMII) we need to make sure that we are using the correct pins as the pins generated by an MX project could not be in line with the hardware mapping done with the board
- Refer to the schematics provided by ST Nucleo, evaluation, or discovery boards as a reference design
- Refer to the documentation of the PHY that you are using to see if there is any requirements or limitations related to hardware mapping, spacing, and pullup resistors.
- Special care should be taken with the reset circuit as it can cause the PHY to desynchronize after reset.
If the hardware implementation is done correctly, we should at least be able to see the Ref_clk throw a scope and get a response after the PHY init sequence.
2. Ethernet peripheral related problems
2.1. How to ensure that Ethernet is working correctly
Ensuring the correct functionality of an Ethernet peripheral involves checking specific key registers and verifying that they contain the correct values. Like other peripherals, Ethernet has numerous registers associated with each layer of its architecture. This can make the debugging process time-consuming and difficult without knowledge of the critical areas to examine. To streamline this process, here are some key registers that can significantly reduce the time spent when debugging an Ethernet application:
2.2 Debug status register (ETH_DMADSR)
This register provides us with the state of the Finite State Machine (FSM) for both DMA channels, transmit (Tx) and receive (Rx). It allows us to determine whether the Ethernet is functioning correctly. If there are issues, the register can help pinpoint the exact stage where the process is experiencing a hang-up.
2.3. Channel status register (ETH_DMACSR)
During each interrupt routine, the application reads the status register to determine the current status of the DMA. This status can be found in the ETH_DMACSR register, which provides information on whether the transmit or receive process has been completed or if it has been halted due to an error. The types of errors that can be detected include unavailable receive or transmit buffers (RBU/TBU), context descriptor errors (CDE), or even fatal bus errors.
2.4. How to trace received packets in each layer
Before starting the tracing process, we need to make sure that the Ethernet has been initialized successfully by reading the value of the debug register (ETH_DMADSR). It should contain the value 3 (011) which indicates that the receive process is running correctly. Next, we can start checking the following registers:
2.5. Rx unicast packets good register (ETH_RX_UNICAST_PACKETS_GOOD)
As implied by its name, this register increments with each detected unicast packet. By monitoring this register, we can determine whether the packet sent is recognized by the first layer of the board's networking hardware.
Upon reception, each packet is forwarded to the MAC Transaction Layer (MTL), where it is temporarily stored. Subsequently, the DMA engine is responsible for transmitting the packet to the system memory. Therefore, the next critical step in the debugging process is to verify the buffer address pointer. This should reference the memory location where the packet data is to be stored or retrieved correctly. Ensuring that this pointer is accurate is vital for the seamless transfer of data between the MTL and system memory.
2.6. Channel current application receive buffer register (ETH_DMACCARXBR)
This register is updated by the DMA during read operations and holds the destination memory address where the received data is transferred from the MAC transaction layer.
3. Possible errors that prevent packets from reaching system memory
3.1. Ethernet not initialized correctly
This issue could stem from various causes, most notably when the PHY does not complete the autonegotiation process. In such instances, the problem could be as straightforward as an improperly connected RJ45 cable. Additionally, misconfigured descriptors can also lead to communication failures. It is critical to ensure that each descriptor is correctly associated with a memory block where data is stored.
3.2. Undersized packets
To address the issue of packets that are error-free but shorter than 64 bytes, there are a couple of solutions. One approach is to increase the size of the payload being sent to meet the minimum length requirement. Alternatively, the FUP (forward undersized good packets) bit in the ETH_MTLRXQOMR (MAC transaction layer receive queue operation mode register) can be toggled to allow these undersized packets to bypass the length check and be forwarded as valid packets.
3.3. CRC error
The Ethernet peripheral includes a mechanism for offloading CRC (cyclic redundancy check) calculation and verification. When a packet is prepared for transmission, a checksum is calculated and appended to the end of the frame to ensure data integrity. Similarly, upon receiving a frame, the CRC field is examined to verify the packet's integrity. If the packet is found to be erroneous, it is immediately discarded. However, if we want to bypass this integrity check, the corresponding bit in the ETH_MTLRXQOMR can be toggled. This action disables the CRC error checking, allowing frames to be accepted even if the CRC does not match.
