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.4 Custom Board Enablement in SYSCFG

This section explains how to enable Ethernet features on a custom board. The examples provided in MCU+SDK are tested on TI EVMs like the LaunchPad™ development kit, control-cards, and systems on module devices. Such devices have EEPROMs and IO expanders configured to route Ethernet signals from the SoC to the PHY and to store data like the Ethernet MAC address. These examples cannot be directly ported to custom hardware because custom hardware generally lacks EEROMs and IO expanders.

In scenarios where users want to run SDK examples on custom hardware, the user must adapt the contents of the ti_board_config.c file based on the custom hardware. This file has mainly two board level dependencies:

  • EEPROM Dependency: An EEPROM dependency is present because the MAC address of the device is stored in EEPROM.
  • IO Expander: The IO expander dependency is present because EVMs use this to route signals from the SoC to the PHY.

Please use the following steps for enabling Ethernet support on custom hardware.

  1. Expand the board configuration section.
    • The Custom Board option is now visible. The Custom Board option is disabled by default. This option must be enabled.
  2. Select the check box to enable the Custom Board option.
    • The ti_board_config.c and ti_board_config.h files generate when the Custom Board check box is enabled.
  3. Manually reconstruct the .c file based on the custom board design.
    • The file is responsible for the following:
      • PHY driver function registration
      • PHY driver configuration
      • MAC port configuration
      • Getting MAC address list
Note: An example demonstrating the custom board integration is available in SDK. The file is available at source\networking\enet\core\examples\enet_layer2_multi_channel\am263x-lp\r5fss0-0_freertos\enet_custom_board_config.c.

For users, the same file can be chosen as a reference while developing the board_config.c file.

The following is an overview of the contents of the file:

  • const EnetPhy_DrvInfoTbl gEnetPhyDrvTbl: This is a table of ENET PHY drivers supported on the board. Refer to the ENET Custom PHY Integration Guide for details on how to populate this table. This guide can be referenced from the MCU+SDK documentation.
    • If the Ethernet PHY used in the custom board is supported in MCU+SDK out-of-box, include the appropriate header files and populate the table.
    • Pay attention to the data structures mentioned in Figure 4-19 and Figure 4-20 and populate the structures accordingly.
    • AM2612 AM2611 AM2634 AM2632 AM2631 AM263P4 AM263P2 AM263P4-Q1 AM263P2-Q1 AM2612-Q1 AM2634-Q1 AM2632 ENET PHY Driver Table Figure 4-19 ENET PHY Driver Table

      AM2612 AM2611 AM2634 AM2632 AM2631 AM263P4 AM263P2 AM263P4-Q1 AM263P2-Q1 AM2612-Q1 AM2634-Q1 AM2632 ENET PHY Driver Configuration for Custom Board Figure 4-20 ENET PHY Driver Configuration for Custom Board

  • EnetBoard_setupPorts(): This function sets up any board-level muxes and configures any SoC-level RGMII internal delay or RMII configuration for the specific port. In some AM26x EVMs, like the AM263P CC, there are some board-level muxes that are used to route MDIO and RGMII signals from the SoC to the PHY using an IO expander. This file has the configuration related to that set-up. If the custom board lacks these IO expanders, then the EnetBoard_setMacPort2IOExpanderCfg() function must be removed. If the IO expander is used, then the corresponding logic must be implemented.
  • EnetBoard_getPhyCfg(): This function returns the ETHPHY specific configuration for a given port including any extended PHY configuration.
  • EnetBoard_getMacAddrList(): This function returns the board-specific Ethernet MAC addresses that are available. The MAC address can be statically configured in code or can be stored in some non-volatile memory. In any case, the corresponding logic must be implemented in this function.
  • EnetBoard_getId(): This function returns the board ID. This function is not used anywhere outside this file, so the board ID returned depends on the implementation of the EnetBoard_setupPorts() function.
  • EnetBoard_getPhyCfg(): This function returns the Ethernet PHY specific configuration for a given port including any extended PHY configuration.
    • The function basically returns the configurations in the structure shown in Figure 4-21. Please pay attention and configure this structure correctly.

    AM2612 AM2611 AM2634 AM2632 AM2631 AM263P4 AM263P2 AM263P4-Q1 AM263P2-Q1 AM2612-Q1 AM2634-Q1 AM2632 ENET PHY Driver Configuration Figure 4-21 ENET PHY Driver Configuration

To summarize, to run SDK examples on a custom board, enable the Custom Board option in SYSCFG and create a replica of the ti_board_config.c file based on the custom board hardware design.