AM2434: Half-duplex communication in DUAL MAC and MII modes with ICSS

Hi Daisuke,

Our domain expert is Out for office for the next 2 days, please expect some delay in response time.

Thank you for your patience.

Regards,

Nitika

Hi Daisuke,

Daisuke Maeda said:

They are testing between two AM2434 prototype boards

This is a custom board based on Am243x-SOC. correct ?

Daisuke Maeda said:

half-duplex communication (10BASE-T1S) in DUAL MAC and MII mode

Which PHY customer is using here ?

Regards

Ashwani

Hi Ashwani-san,

Thank you for your reply.

Ashwani Goel said:

This is a custom board based on Am243x-SOC. correct ?

Correct. It is a custom board using AM2434 (ALX). They are testing with two custom boards.

Ashwani Goel said:

Which PHY customer is using here ?

They are using "Microchip LAN8672C1T-E/LNX".

Best regards,

Daisuke

Hi Ashwani-san,

I got additional information.

Daisuke Maeda said:

They are testing between two AM2434 prototype boards, but a frame length is limited to 128 bytes when the CRS input is enabled.

The active (high) period of both the TX_EN output (AM2434 to PHY) and CRS (PHY to AM2434) is limited to the same period of 128 bytes if the CRS input is set to enabled.

Best regards,

Daisuke

Daisuke Maeda said:

It is a custom board using AM2434 (ALX)

I would recommend you to review your board design/ schematic with TI HW team.

Daisuke Maeda said:

Microchip LAN8672C1T-E/LNX

I will check on this and get back to you.

Hopefully, you are following below documentation

Custom Board Support

AM243x MCU+ SDK: Enet Migration Guide

AM243x MCU+ SDK: Ethernet PHY Integration Guide

Regards

Ashwani

Hi Ashwani-san,

Thank you for your reply.

Has the PRU-ICSS firmware on AM64/AM243x been tested by TI for half-duplex communication using CRS and COL in MII mode?

TMDS64EVM/TMDS243EVM supports MII mode with ICSS, but does not support half-duplex communication since CRS and COL are not used. LP-AM243 does not support MII mode.

Best regards,

Daisuke

Daisuke Maeda said:

how should the MCU+ SDK be modified for half-duplex in DUAL MAC and MII modes?

• Open example.syscfg
  • TI BOARD DRIVERS -> ETHPHY

• TI NETWORKING -> Enet(ICSS)

• Step 3:
  • Check SYSCONFIG settings for PHY reset and Pinmux. Add these configurations (if not working for your use case) in main.c
  • Custom PHY drivers are not added to the MCU+ SDK libraries. Copy these files to the project.
  • Enable custom board config in SYSCONFIG, copy the enet_custom_board_config.c file to the project and make changes to PHY conifgs.

Regards

Ashwani

Hi Ashwani-san,

Thank you for your reply.

The active (high) period of the TX_EN output (AM2434 to PHY) is NOT limited to the same period as 128 bytes if the CRS input is NOT enabled in SYSCONFIG. Even in half-duplex communication, a ping is successful regardless of frame length by alternately transmitting and receiving to prevent collisions. So the basic configuration of ICSS Ethernet and PHY for half-duplex in DUAL MAC and MII modes should be correct.

Does the active (high) period of the CRS input affect the active (high) period of the TX_EN output?

Should our customer pull up the CRS input without connecting it to the PHY to check if it affects the TX_EN output?

Best regards,

Daisuke

Daisuke Maeda said:

Does the active (high) period of the CRS input affect the active (high) period of the TX_EN output?

You are asking it from MAC (ICSSG) point of view ?

Daisuke Maeda said:

Should our customer pull up the CRS input without connecting it to the PHY to check if it affects the TX_EN output?

If customer have a test case. It will be good to see the result/ observation.

Regards

Ashwani

Hi Ashwani-san,

Thank you for your reply.

We suspect that the active (high) period of the TX_EN output when the CRS input is enabled on the ICSSG is limited to a period similar to 128 bytes.

Daisuke Maeda said:

The active (high) period of both the TX_EN output (AM2434 to PHY) and CRS (PHY to AM2434) is limited to the same period of 128 bytes if the CRS input is set to enabled.

Daisuke Maeda said:

The active (high) period of the TX_EN output (AM2434 to PHY) is NOT limited to the same period as 128 bytes if the CRS input is NOT enabled in SYSCONFIG.

Ashwani Goel said:

Daisuke Maeda said:

Should our customer pull up the CRS input without connecting it to the PHY to check if it affects the TX_EN output?

If customer have a test case. It will be good to see the result/ observation.

I requested to our customer the observation.

Best regards,

Daisuke

Thanks Daisuke Maeda,

Just for clarification:

Case1:

Daisuke Maeda said:

The active (high) period of both the TX_EN output (AM2434 to PHY) and CRS (PHY to AM2434) is limited to the same period of 128 bytes if the CRS input is set to enabled.

Case2:

Daisuke Maeda said:

The active (high) period of the TX_EN output (AM2434 to PHY) is NOT limited to the same period as 128 bytes if the CRS input is NOT enabled in SYSCONFIG.

 In both case, MAC and PHY are communicating in 10M Half duplex + MII + DUAL MAC mode. correct?

Daisuke Maeda said:

I requested to our customer the observation.

Hopefully, this will provide us more clarity.

Regards

Ashwani

Hi Ashwani-san,

Thank you for your reply.

Ashwani Goel said:

 In both case, MAC and PHY are communicating in 10M Half duplex + MII + DUAL MAC mode. correct?

Yes. In both cases, the MAC (AM243x) is configured in 10M Half duplex + MII + DUAL MAC mode and the PHY is be configured in 10M Half duplex + MII. The PHY (Microchip LAN8672C1T-E/LNX) only supports 10BASE-T1S half duplex. The only difference is whether the CRS input is enabled in SYSCONFIG.

Can the MAC (ICSSG) be set to half duplex in SYSCONFIG?

Ashwani Goel said:

If customer have a test case. It will be good to see the result/ observation.

If the CRS input is enabled in SYSCONFIG, TXDs are also limited to the same period of 128 bytes.

If the CRS input is fixed low, all transfers succeed regardless of data length.

If the CRS input is fixed high, all transfers fail regardless of data length.

The MAC (ICSSG) seems to stop transmitting midway when CRS is input high.

Is it acceptable for the PHY to drive CRS high when transmitting?

Best regards,

Daisuke

Hi Ashwani-san,

Thank you for your reply.

Is this half-duplex issue an ICSS firmware issue or an R5 software issue?

If it is an ICSS firmware issue, do we have to wait for the next MCUSDK release to fix it?

If it is an R5 software issue, could you please provide a workaround to fix it?

Best regards,

Daisuke

Hi Ashwani-san,

Thank you for your reply.

Ashwani Goel said:

Planned to be fixed in SDK 10.0

When is SDK 10.0 planned to be released?

Best regards,

Daisuke

Hi Ashwani-san,

Thank you for your reply.

Our customer is waiting for SDK 10.0 to be released.

Best regards,

Daisuke