AM2634: PR0_MDIO0_MDC/MDIO using for the PRU0 ICSSM

Anjana Ramalingam said:

Can ICSSM and CPSW MDIO interfaces operate independently without conflict? How does the SDK handle dual MDIO domains (MDIO0 and PR0_MDIO0)?

Both PRU ICSSM and CPSW have seperate and dedicated MDIO module, so there is not conflict of resource. 

Hi Nilabh

I am currently working with the MCU+ SDK version 10.00.00.35, and testing the example project:
icss_emac_lwip_am263x-cc_r5fss0-0_freertos_ti-arm-clang.

In this example, I have been experimenting with different EMAC operating modes. When the EMAC is configured in "Switch" mode, the application runs correctly — the link is established, and I am able to ping the board successfully from my PC.

However, when I change the EMAC mode to "MAC1" or any of the other MAC modes, I observe that the link is still being detected, but I am not able to ping the board. The network interface appears to be initialized, but there is no response to ICMP echo requests.

My understanding is that modes like MAC1 or MAC2 should also support standard Ethernet communication (including IP and ICMP). Therefore, can  help me to understand the below one:

• Why does ping work in Switch mode but not in other MAC modes?

• Is there something specific I need to configure when using MAC modes instead of Switch mode?

• Are there known limitations or required modifications in the SDK when using ICSS EMAC in MAC mode with lwIP?

I'd appreciate any insights or guidance to help identify what might be missing or misconfigured in other MAC mode that prevents successful pinging.

Hi Nilabh

Any update on this, can you please help me on this urgent basis.

Hi,

https://software-dl.ti.com/mcu-plus-sdk/esd/AM263X/latest/exports/docs/api_guide_am263x/RELEASE_NOTES_10_00_00_PAGE.html#autotoc_md383

In the release notes following issues are listed out as known issue.

Also could you please refer to debug guide to make sure there are no configurations that are done incorrectly: software-dl.ti.com/.../ICSS_EMAC_DEBUG_GUIDE.html

Hi Nilabh

As you previously mentioned, DUAL EMAC mode has known issues, especially when attempting to use both MAC ports simultaneously. However, I wanted to clarify something:

Is it possible to use only one MAC port (either MAC1 or MAC2) in DUAL EMAC mode, as shown in the screenshot — essentially enabling just one of them while leaving the other disabled?

Alternatively, rather than configuring DUAL EMAC, can we use the ICSS in a mode where only MAC1 or only MAC2 is active and expect it to function correctly?

I’m trying to understand whether a partial configuration like this is supported and stable, or whether using only one MAC in DUAL EMAC mode still leads to issues.

Now, to explain my specific requirement:

• On my custom board, we are using PRU0 pins for Ethernet functionality.

• The PRU1 pins are being used for GPIO purposes, so they cannot be assigned to Ethernet.

• Additionally, we are using the PR0_MDIO0_MDC and PR0_MDIO0_MDIO pins for the Ethernet PHY connection.

Given this hardware configuration, I would like to know the correct mode to configure the Ethernet interface:

• I understand that Switch mode is not suitable in this case because the Ethernet interface does not come up.

• Similarly, DUAL MAC mode is not working for me, likely because only one MAC port is used and the other is repurposed for GPIO.

• My question is: Can I configure the ICSS Ethernet in MAC1-only mode and expect it to work with just PRU0 and MDIO lines active?

If this is not a supported configuration, is there any alternative way to make Ethernet work using only the PRU0-related pins and a single MAC port?

Your guidance on how to properly configure this setup — possibly using MAC1-only mode or another workaround — would be greatly appreciated.

Thank you Anjana for the detailed explanation on the issue, now i have a better understanding given its a custom board.

I will try to test MAC 1 only mode on AM263x-CC today, I belive this has been validated by our development team, and will update here by tomorrow.

Hi Nilabh 

Any update on the above case. 

Hi Anjana,

Aplogies for the delay. We had a delay due to SDK release, our team is working on prioritizing the support for this issue

Hi Nilabh,

Any update on the case?

Hi Nilabh,

Thank you for the workaround. On the evaluation board, I was able to successfully ping the device while operating in MAC1 mode using the provided code. The setIOExpMuxSelection() function worked as expected in that setup.

However, when I loaded the same code onto our custom board, I was not able to ping the device. Since our custom board does not include a MUX for selecting the MDIO and MDC lines, I have already removed the setIOExpMuxSelection() function from the code.

Despite that change, the ping is still not working on our custom board. I would appreciate your help in identifying any additional steps or configuration changes that might be required to get Ethernet communication working correctly.

Also, I’d like to highlight that our custom board uses a port mirroring configuration in hardware. Could you please confirm:

• Whether port mirroring requires any software-level configuration (for example, in the ICSS EMAC, CPSW, or ALE settings)?

• If yes, what changes are required in the code or SysConfig to support port mirroring properly?

Please help us troubleshoot this issue. Let me know if you need any specific hardware details to guide the debugging process more accurately.

Hi Nilabh

We are integrating Ethernet functionality on a custom AM263x-based board using the icss_emac_lwip example from MCU+ SDK 10.00.00.35. While the software runs correctly on the TI EVM, we're encountering a persistent issue on our custom hardware — the Ethernet link does not come up.

Unlike the TI evaluation board, our design does not include a MUX for MDIO line selection. Instead, the MDIO signals are routed directly from the AM263x to the Ethernet PHY. To reflect this hardware difference, we removed the MDIO MUX selection logic from the reference example code (icss_emac_lwip_am263x-cc_r5fss0-0_freertos_ti-arm-clang) while retaining all other configurations.

Additionally, in our design, PRU1 is not used for Ethernet communication — it is repurposed for GPIO functionality to control other peripherals. As a result, only PRU0 is active for Ethernet (MAC1 mode), and the second ICSSG MAC port is intentionally disabled.

To support analysis and reduce ambiguity, we’ve included the following resources:

• The updated example.syscfg file reflecting our peripheral configuration.

• The Ethernet PHY schematic from our custom board, highlighting the RGMII and MDIO signal routing.

We would appreciate your insight on the following points:

1. Could simply removing the MDIO MUX control logic — without other adjustments — be insufficient to enable MDIO communication on custom hardware?

2. Are there any specific registers or initialization steps in the driver stack that implicitly assume the presence of the MUX and therefore require modification?

3. Based on the schematic, do the MDIO lines (MDIO/MDC) require explicit pinmux configuration (mode, pull-up, etc.) to function reliably without the MUX?

4. Are there any recommended debug techniques to verify MDIO or PHY activity (e.g., reading PHY registers directly, enabling MDIO logging, or probing MDC/MDIO lines with an oscilloscope or logic analyzer)?

Any recommendations or clarifications you can provide based on our configuration and hardware setup would be greatly appreciated.

/**
 * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
 * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
 * @cliArgs --device "AM263x_beta" --part "AM263x" --package "ZCZ" --context "r5fss0-0" --product "MCU_PLUS_SDK_AM263x@10.00.00"
 * @v2CliArgs --device "AM2631-Q1" --package "NFBGA (ZCZ)" --context "r5fss0-0" --product "MCU_PLUS_SDK_AM263x@10.00.00"
 * @versions {"tool":"1.21.0+3721"}
 */

/**
 * Import the modules used in this configuration.
 */
const eeprom     = scripting.addModule("/board/eeprom/eeprom", {}, false);
const eeprom1    = eeprom.addInstance();
const ethphy     = scripting.addModule("/board/ethphy/ethphy", {}, false);
const ethphy1    = ethphy.addInstance();
const gpio       = scripting.addModule("/drivers/gpio/gpio", {}, false);
const gpio1      = gpio.addInstance();
const i2c        = scripting.addModule("/drivers/i2c/i2c", {}, false);
const i2c1       = i2c.addInstance();
const pruicss    = scripting.addModule("/drivers/pruicss/pruicss", {}, false);
const pruicss1   = pruicss.addInstance();
const debug_log  = scripting.addModule("/kernel/dpl/debug_log");
const dpl_cfg    = scripting.addModule("/kernel/dpl/dpl_cfg");
const mpu_armv7  = scripting.addModule("/kernel/dpl/mpu_armv7", {}, false);
const mpu_armv71 = mpu_armv7.addInstance();
const mpu_armv72 = mpu_armv7.addInstance();
const mpu_armv73 = mpu_armv7.addInstance();
const mpu_armv74 = mpu_armv7.addInstance();
const mpu_armv75 = mpu_armv7.addInstance();
const mpu_armv76 = mpu_armv7.addInstance();
const mpu_armv77 = mpu_armv7.addInstance();
const icss_emac  = scripting.addModule("/networking/icss_emac/icss_emac", {}, false);
const icss_emac1 = icss_emac.addInstance();

/**
 * Write custom configuration values to the imported modules.
 */
eeprom1.$name = "CONFIG_EEPROM0";

ethphy1.$name    = "CONFIG_ETHPHY0";
ethphy1.mdioPort = 0;

gpio1.$name          = "MCA_PHY2_RST";
gpio1.pinDir         = "OUTPUT";
gpio1.defaultValue   = "1";
gpio1.GPIO_n.$assign = "EPWM7_B";

i2c1.$name               = "CONFIG_I2C0";
eeprom1.peripheralDriver = i2c1;
i2c1.I2C.$assign         = "I2C0";
i2c1.I2C_child.$name     = "drivers_i2c_v1_i2c_v1_template1";

pruicss1.$name                           = "CONFIG_PRU_ICSS0";
pruicss1.AdditionalICSSSettings[0].$name = "CONFIG_PRU_ICSS_IO0";

debug_log.enableUartLog            = true;
debug_log.enableCssLog             = false;
debug_log.uartLog.$name            = "CONFIG_UART0";
debug_log.uartLog.UART.$assign     = "UART0";
debug_log.uartLog.UART.RXD.$assign = "UART0_RXD";
debug_log.uartLog.UART.TXD.$assign = "UART0_TXD";
debug_log.uartLog.child.$name      = "drivers_uart_v2_uart_v2_template0";

mpu_armv71.$name             = "CONFIG_MPU_REGION0";
mpu_armv71.size              = 31;
mpu_armv71.attributes        = "Device";
mpu_armv71.accessPermissions = "Supervisor RD+WR, User RD";
mpu_armv71.allowExecute      = false;

mpu_armv72.$name             = "CONFIG_MPU_REGION1";
mpu_armv72.size              = 15;
mpu_armv72.accessPermissions = "Supervisor RD+WR, User RD";

mpu_armv73.$name             = "CONFIG_MPU_REGION2";
mpu_armv73.baseAddr          = 0x80000;
mpu_armv73.size              = 15;
mpu_armv73.accessPermissions = "Supervisor RD+WR, User RD";

mpu_armv74.$name             = "CONFIG_MPU_REGION3";
mpu_armv74.accessPermissions = "Supervisor RD+WR, User RD";
mpu_armv74.baseAddr          = 0x70000000;
mpu_armv74.size              = 21;

mpu_armv75.$name        = "CONFIG_MPU_REGION4";
mpu_armv75.size         = 14;
mpu_armv75.baseAddr     = 0x50D00000;
mpu_armv75.allowExecute = false;
mpu_armv75.attributes   = "Device";

mpu_armv76.$name        = "CONFIG_MPU_REGION5";
mpu_armv76.size         = 14;
mpu_armv76.allowExecute = false;
mpu_armv76.attributes   = "NonCached";
mpu_armv76.baseAddr     = 0x72000000;

mpu_armv77.$name      = "CONFIG_MPU_REGION6";
mpu_armv77.baseAddr   = 0x70000000;
mpu_armv77.size       = 16;
mpu_armv77.attributes = "Cached+Sharable";

icss_emac1.$name            = "CONFIG_ICSS_EMAC0";
icss_emac1.linkTaskPriority = 12;
icss_emac1.txTaskPriority   = 10;
icss_emac1.rxTaskPriority   = 10;
icss_emac1.queue            = "QUEUE4";
icss_emac1.learningEnable   = true;
icss_emac1.phyAddr1         = 1;
icss_emac1.mode             = "MAC1";
icss_emac1.phyAddr0         = 1;

/**
 * Pinmux solution for unlocked pins/peripherals. This ensures that minor changes to the automatic solver in a future
 * version of the tool will not impact the pinmux you originally saw.  These lines can be completely deleted in order to
 * re-solve from scratch.
 */
i2c1.I2C.SCL.$suggestSolution = "I2C0_SCL";
i2c1.I2C.SDA.$suggestSolution = "I2C0_SDA";

Ethernet.pdf

Hi Anjana 

We have not tested this implementation on our side before, for this to work, the two PRU firmware should be decoupled i.e no shared memory being used etc.

For HW schematics review please reach out to your local sales executive and share complete schematics so our HW team can review this properly.