• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 680 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3357: ICE Ver 2; PRU-ICSS-EthernetIP_Adapter_01.00.03.04; Question referring Half-Duplex (non) support

Stefan Mätje
Prodigy 70 points

Part Number: AM3357

Hi,

TI provides the PRU-ICSS-EthernetIP_Adapter software package together with the ICE Ver 2 evaluation board to implement an Ethernet/IP Adapter.

The "PRU-ICSS EtherNet/IP Adapter Firmware Data Sheet" states that the connection of the prX_miiY_crs and prX_miiY_col signals for half duplex support is optional but on the ICE V2 these pins are connected.

I have to implement the EtherNet/IP Adapter stuff on a custom board where the mentioned prX_miiY_crs (carrier sense) and prX_miiY_col (collision detect) signals are not connected.  Two questions arise so far:

1) Is the PRU firmware capable of operating without these signals?

2) Where in the software do I disable the half duplex capability? I didn't find the right code line yet.

Best regards,

    Stefan

  • 0
    TI__Mastermind 40580 points
    Hi Stefan, I will do a quick confirmation with our developers, but I am pretty sure you don't need MII collision signal, nor MII CRS for full duplex.

    From code inspection, I see you can set Interface speed/duplicity via API EIPHAL_setInterfaceSpeed (C:\TI\PRU-ICSS-EthernetIP_Adapter_01.00.03.04\examples\ethernetip_adapter\hal.c). This function calls MDIO_setPhyConfig().

    Alternatively, In eip_main.c, you can add (or modify) an option in console menu in order to disable auto negotiation and Force Full Duplex. It could be an addition to EIPAPP_resetImplement() setting up below variables

    stEthControl.bAutoNegotiate = 0;
    stEthControl.bForceFullDuplex = 1;
    stEthControl.wForceInterfaceSpeed = 1;

    Another option is to use external Molex tool to set the interface speed/duplicity

    thank you,
    Paula
  • 0 in reply to Paula Carrillo
    Prodigy 70 points
    Hi Paula,

    I think forcing the speed and duplicity of the link is not the best way to go. Because this will only work as intended if both link partners are in force mode and set the same speed and duplicity setting.

    The worst case would be if my device is set to force 100MBit and Full-Duplex and a link partner is in Autonegotiate mode. Then the link partner will see the 100MBit speed but fall back to Half-Duplex because my device sends no negotiation information.

    I believe the right thing on my side would be to set my phy devices to autonegotiate but in the Autonegotiation Advertisement Register (reg #4) to disable the "100Base-TX Half-Duplex" bit (bit #7) and the "10Base-T Half-Duplex" bit (bit #5) in that register and then restart the autonegotiation. Then the PHYs never would establish a Half-Duplex connection with a link partner.

    After examining the example source code I found in "PRU-ICSS-EthernetIP_Adapter_01.00.03.04\examples\ethernetip_adapter\main.c" the line

    switchEmacCfg->halfDuplexEnable = 1;

    which is only documented for the Switch PRU firmware here:
    processors.wiki.ti.com/.../Processor_SDK_RTOS_ICSS-EMAC-Design

    If I would set the halfDuplexEnable=0 for the EtherNet/IP PRU firmware can you please confirm that this firmware won't use the collision nor the CRS signal?

    Also it is not clear to me at the moment if the PRU firmware will autonomously take over the speed and duplexity settings from the PHY devices after a link change / autonegotiation complete event. Can you please comment on this.

    Best regards,
    Stefan
  • 0 in reply to Stefan Mätje
    TI__Mastermind 40580 points

    Hi Stefan, thanks for explaining better your use case. Below answers:


    Q1) Board doesn’t connect MII collision signal, nor MII CRS. Does this lack of Collision and CRS presents any issues for FD?

    PC-- This isn’t an issue as long as those pins are not connected to something else which might assert them, which I believe is the case.

    Q2) Could/should HD be disabled directly in PHY?.

    PC-- No need, better to disable HD from application via EMAC configuration. You can set to 0 halfDuplexEnable in orde to disabled it. You pointed out to Processor_SDK_RTOS_ICSS-EMAC-Design. Just FYI, this is also documented in ICSS_EIP_Adapter_Developer_Guide under Half Duplex section.

    Q3)Do PRU Firmware would change the speed and duplexity set by PHY devices after a link change and/or  autonegotiation event?

    PC-- There is a link interrupt once autoneg or link up/down occurs where we detect speed/duplexity and write to DMEM0 and DMEM1.

    thank you,

    Paula

  • 0 in reply to Paula Carrillo
    Prodigy 70 points
    Hi Paula,

    I did a proof of concept implementation on the ICE Ver 2 evaluation board. It showed that it is not enough to set
    "switchEmacCfg->halfDuplexEnable = 0;" to make the PHY not advertise the Half-Duplex mode. It seems that it only configures the
    switch implementation in the PRU not to support Half-Duplex.

    Very early in the EIPAPP_main() function (after the call to EIPUTILS_displayApplicationDetails()) I added a call to a function that
    removed the Half-Duplex Capability bits from the Autonegotiation Advertisement Register (reg #4) in both PHY devices. It seems
    that neither the EtherNet/IP software nor the PRU switch firmware touch the Autonegotiation Advertisement Register so that
    the Half-Duplex Capabiltity advertisement being disabled survives the normal operation of the application and any link loss and
    regain events.

    Thank you for your support.

    Best regards,
    Stefan