SLUUDO2 September   2026 AM2611 , AM2612 , AM2612-Q1 , AM2631 , AM2631-Q1 , AM2632 , AM2632-Q1 , AM2634 , AM2634-Q1 , AM263P2 , AM263P2-Q1 , AM263P4 , AM263P4-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Acronyms
  5. 2Introduction
  6. 3Introduction to CPSWSS and ENET-LLD
    1. 3.1 Hardware
    2. 3.2 Software
    3. 3.3 Application Software
      1. 3.3.1 Board and Peripherals Initialization (SYSCFG)
      2. 3.3.2 CPSW Configuration (ENET-LLD)
      3. 3.3.3 Operating System (FreeRTOS or NoRTOS)
      4. 3.3.4 Middleware Stack (LwIP, Arm® Mbed™ Platform TLS, TSN)
      5. 3.3.5 Application Layer
  7. 4Debugging Hardware and Software
    1. 4.1 Hardware Debugging
      1. 4.1.1 Schematic Review Checklist
        1. 4.1.1.1 Management Data Input/Output (MDIO and MDC)
        2. 4.1.1.2 RGMII Interface
      2. 4.1.2 PHY Debug
        1. 4.1.2.1 PHY Bootstrap Settings
        2. 4.1.2.2 Trace Length
        3. 4.1.2.3 Clock Configuration
        4. 4.1.2.4 Mode Settings
        5. 4.1.2.5 IO MUX and SW Switch Settings
        6. 4.1.2.6 PHY Troubleshooting Guides
        7. 4.1.2.7 Custom Pin MUX Settings
      3. 4.1.3 Test Setup
      4. 4.1.4 Software Debugging
        1. 4.1.4.1 Using GEL Scripts in CCS
          1. 4.1.4.1.1 Statistics Using GEL Scripts
          2. 4.1.4.1.2 Statistics Using Expressions
      5. 4.1.5 Debugging Custom Ethernet Software
        1. 4.1.5.1 Debugging Initialization Sequence
        2. 4.1.5.2 PHY Debugging
        3. 4.1.5.3 MAC Port Debugging
        4. 4.1.5.4 TX Path Debugging
        5. 4.1.5.5 Systematic Debugging Checklist
          1. 4.1.5.5.1 RX Path Debugging
          2. 4.1.5.5.2 Multicast or Broadcast Does Not Work, But Unicast Works
    2. 4.2 Custom Hardware Bring-Up Process
      1. 4.2.1 Example 1: CPSW PHY Loopback
        1. 4.2.1.1 Failure: PHY Not Detected or MDIO Bus Not Alive
        2. 4.2.1.2 Failure: TX Packets Transmitted But RX Count = 0
      2. 4.2.2 Example 2: CPSW MAC Loopback Example
        1. 4.2.2.1 Failure: MAC Loopback Initialization Fails
        2. 4.2.2.2 Failure: TX Packets Increase But RX = 0
        3. 4.2.2.3 Failure: Nonzero Error Counters
      3. 4.2.3 Example 3: Enet_Layer2_CPSW and Enet_Layer2_cpsw_switch
        1. 4.2.3.1 Hardware Setup
        2. 4.2.3.2 Failure: Link Never Comes UP
        3. 4.2.3.3 Failure: Link is Up But No Frames Are Received or Transmitted
        4. 4.2.3.4 Failure: RX and TX Counters Increase But Error Rates Are High
      4. 4.2.4 Example 4: Enet_lwip_cpsw_example
        1. 4.2.4.1 Failure: Link Never Comes Up
        2. 4.2.4.2 Failure: Links Up But No IP Address Is Assigned
        3. 4.2.4.3 Failure: Ping Fails Despite Link and IP Address
    3. 4.3 Debugging Packet Forwarding Issues (ALE and Statistics)
      1. 4.3.1 CPSW Statistics Architecture
        1. 4.3.1.1 What Each Block Measures
        2. 4.3.1.2 Counter Reference Tables
          1. 4.3.1.2.1 MAC Port – RX Counters
          2. 4.3.1.2.2 MAC Port – TX Counters
          3. 4.3.1.2.3 MAC Port and Host Port – ALE and FIFO Drop Counters
          4. 4.3.1.2.4 Host Port – ALE Flood and Overrun Counters
          5. 4.3.1.2.5 MAC Port RX Issues
          6. 4.3.1.2.6 MAC Port TX Issues
          7. 4.3.1.2.7 Host Port RX Issues
          8. 4.3.1.2.8 Host Port TX Issues
    4. 4.4 Custom Board Enablement in SYSCFG
    5. 4.5 LwIP Debug Guide
      1. 4.5.1 LwIP Stack Configuration
      2. 4.5.2 lwip_stats
  8. 5Conclusion
  9. 6References

4.1.5.4 TX Path Debugging

This section describes the steps for debugging the TX port.

TX path failures are easier to diagnose than RX failures because the flow is simpler, but these failures still require systematic analysis to isolate whether the problem is in packet submission, DMA transfer, ALE forwarding, or MAC transmission. Understanding the complete packet flow from application to wire helps quickly identify the failure point.

  1. Step 1: The expected TX packet flow.

    When your application transmits a packet, the application follows the following sequence:

    1. The application submits the packet → The EnetDma_submitTxPktQ() function returns success.
    2. DMA transfers the packet from the CPU to the CPSW → The hostStats.txGoodFrames increments.
    3. The ALE examines the destination MAC and determines the output port → The ALE completes the look up.
    4. The MAC port transmits the packet to wire → The macStats.txGoodFrames increments.
    5. Packets are dropped or never reach the wire if any of these steps fail.
  2. Step 2:
    1. Setting a breakpoint at the EnetDma_submitTxPktQ() function in your transmit function.
    2. Examine the packet queue being submitted before the call executes.
    3. Inspect the txSubmitQ structure.
    4. Check the status code after EnetDma_submitTxPktQ() returns.
      1. If the status is ENET_SOK and the submission succeeded, and the packet is handed to DMA.
      2. If the status is ENET_EINVALIDPARAMS and the packet structure is malformed, check if the bufPtr is valid, the segmentFilledLen is reasonable, and verify the packet queue was initialized correctly.
      3. If the status is ENET_ENOMEM, the DMA descriptor ring is full, and the transmitted packets are not being retrieved and freed, set the breakpoint in the EnetDma_retrieveTxPktQ() function to verify this is called regularly.
  3. Step 3: TX descriptors must be retrieved after transmission completes to free the descriptors for reuse.
    1. Set a breakpoint at the EnetDma_retrieveTxPktQ() function, typically called from a periodic timer or completion callback.
      Note: If this function is never called or called too infrequently:
      • The TX descriptor ring fills up overtime and the EnetDma_submitTxPktQ() function starts returning ENET_ENOMEM.
      • The transmission stops silently, even though link is up. The descriptor ring is finite (configured in SYSCFG). If packets are submitted faster than completed descriptors are retrieved, the ring exhausts. Verify retrieval happens after each transmit or on a periodic timer fast enough to keep up with the transmit rate.
  4. Step 4: Statistics counters show exactly where packets are dropped in the TX path.
    1. Read the host port and MAC port statistics before and after transmission. The pattern of counter changes identifies the failure point in the following scenarios:
      1. Scenario 1: hostStats.txGoodFrames does NOT increment →
        • The packet never reached DMA (submission failed).
        • Check the EnetDma_submitTxPktQ() function return code.
        • Verify the TX channel opened successfully (hTxCh is valid).
        • Check the DMA descriptor ring is not exhausted (retrieve completed packets).
      2. Scenario 2: hostStats.txGoodFrames increments and macStats.txGoodFrames does NOT.
        • DMA accepted the packet but MAC did not transmit.
        • The ALE is dropping a packet or forwarding to a wrong port.
        • Check the hostStats.portMaskDrop counter.
        • If portMaskDrop increments, destination MAC entry has the wrong port mask.
        • Dump the ALE table and verify the destination MAC address entry exists with the correct output port.
      3. Scenario 3: Both hostStats and macStats txGoodFrames increment, but link partner identifies nothing.
        • The packets transmitted but did not reach link partner.
        • Check the MAC port link status (must be UP).
        • Verify the cable is connected and the link partner is listening.
        • Use the Wireshark® on link partner to confirm frames are not arriving at all.
      4. Scenario 4: Link partner receives packets but identifies CRC errors.
        • The packets transmitted but are corrupt.
        • Check the packet buffer contents before submission.
        • Verify segmentFilledLen matches the actual frame data length.
        • Enable the CPSW automatic CRC append if the application does not calculate a CRC.