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.5.1 RX Path Debugging

RX path failures are more subtle than TX failures because packets can potentially arrive at the PHY but never reach the application due to ALE filtering or DMA buffer exhaustion. Understanding the complete packet flow from wire to application helps isolate where the failure occurs. The expected RX packet flow is:

When a packet arrives from the network, the packet follows this sequence:

  1. The packet arrives at an external MAC port → macStats.rxGoodFrames increments.
  2. The ALE examines the destination MAC and forwards the destination to the host port → hostStats.rxGoodFrames increments.
  3. DMA transfers the packet to memory → An RX interrupt fires.
  4. The application retrieves the packet → The EnetDma_retrieveRxPktQ() function returns packet.

If any step fails, packets are dropped silently. Start debugging by setting a breakpoint in your RX interrupt handler or callback function, typically named something like EnetApp_rxIsrFxn(). Send a test packet to the device from a link partner. If the breakpoint never hits:

  1. Check that the EnetDma_enableRxEvent() function was called on your RX channel handle during initialization.
  2. Verify the interrupt routing configuration in SYSCFG matches the CPSW interrupt controller setup.
  3. Read the host port statistics directly and check if rxGoodFrames is incrementing.
    Note: If rxGoodFrames increases, but the interrupt handler never called, the problem is in the interrupt configuration not the packet reception.

If the interrupt handler breakpoint does hit, the RX hardware path is working correctly.

  1. Move to the next checkpoint by setting a breakpoint at the EnetDma_retrieveRxPktQ() function inside your RX task.
    Note: This function retrieves packets from the DMA and places those packets in a queue for application processing.

  2. Step through the retrieve call and inspect the returned queue count.

A critical, but often overlooked aspect of RX debugging, is buffer resubmission. After the application processes each received packet, the application must return the buffer to the DMA by calling the EnetDma_submitRxPktQ() function.

  1. Set a breakpoint at this function call and verify the breakpoint executes for every packet retrieved. If buffers are not resubmitted:
    1. The DMA descriptor pool gradually exhausts.
    2. Subsequent packets are dropped even though the packets arrive at the host port.
    3. Manifests as the initial packets being received successfully, followed by complete RX silence.
    4. The rxBottomOfFifoDrop counter in host port statistics increments rapidly.
      Note: Your code flow must be: Retrieve packet → Process data → Resubmit buffer. Missing the resubmit step is the most common RX implementation bug.

Statistics counters provide definitive evidence of where packets are being dropped. Read both the MAC port and the host port statistics before and after sending a test packet in the following scenarios:

Scenario 1: MAC rxGoodFrames increments but the host rxGoodFrames does NOT →

  • The ALE is filtering packets before the packets reach the host (the most common RX failure).
  • Check the hostStats.portMaskDrop counter.
  • If the portMaskDrop increments: The ALE entry exists but the port mask excludes the host port.
  • Dump the ALE table with CPSW_ALE_IOCTL_DUMP_TABLE and verify the destination MAC has entry with the host port included.

Scenario 2: Both MAC and the host rxGoodFrames increment, but the application identifies nothing.

  • The packets reach DMA but the application does not retrieve the packets.
  • Check the RX task is running and being scheduled by RTOS.
  • Verify the EnetDma_retrieveRxPktQ() function is called in response to the RX interrupt.
  • Common bug: Forgetting to post semaphore in the interrupt handler to wake the RX task.

Scenario 3: Counters increment initially, then stop.

  • The RX descriptor pool is exhausted (missing buffer resubmission).
  • Check the rxBottomOfFifoDrop counter.
  • Verify the EnetDma_submitRxPktQ() function is called after processing each packet.

This methodical approach isolates the exact failure point in the RX path.