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.

TM4C1294NCPDT: 100Base-TX Full Duplex Auto MDI-X problem

Part Number: TM4C1294NCPDT

Good day everyone.

I have ran into a problem where I don't get link for around 90 seconds with crossover cable on 100mbit full duplex settings.

Is it normal for it to take this long? I am using robust MDI-X as without it I don't get link at all at these settings.

If I use auto negotiation (and normal MDI-X, not robust) then everything works within a second. It's just this particular setting that is causing me trouble.

I am using internal PHY.

This is how I configure ethernet hardware:

  // Enable and reset the Ethernet
  SysCtlPeripheralEnable(SYSCTL_PERIPH_EMAC0);
  SysCtlPeripheralEnable(SYSCTL_PERIPH_EPHY0);
  SysCtlPeripheralReset(SYSCTL_PERIPH_EMAC0);
  SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0);
// Wait for the MAC to be ready while (!SysCtlPeripheralReady(SYSCTL_PERIPH_EMAC0));
// Stop transmitting on the line EMACPHYConfigSet(EMAC0_BASE, EMAC_PHY_INT_HOLD);
// Enable PHY SysCtlPeripheralEnable(SYSCTL_PERIPH_EPHY0);
// Wait for the PHY to be ready while (!SysCtlPeripheralReady(SYSCTL_PERIPH_EPHY0));
// Set speed and duplex settings EMACPHYConfigSet(EMAC0_BASE, EMAC_PHY_FORCE_100B_T_FULL_DUPLEX | EMAC_PHY_INT_ROBUST_MDIX | EMAC_PHY_INT_MDIX_EN); EMACPHYWrite(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_BMCR, EPHY_BMCR_DUPLEXM | EPHY_BMCR_SPEED);
// Set configuration DONE EMACPHYWrite(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_CFG1, EPHY_CFG1_DONE);
// reset EMAC EMACReset(EMAC0_BASE);
// init EMAC EMACInit(EMAC0_BASE, ADN_SYS_CORE_FREQ, (EMAC_BCONFIG_FIXED_BURST | EMAC_BCONFIG_PRIORITY_FIXED), 1, 1, 0);
// configure EMAC EMACConfigSet(EMAC0_BASE, (EMAC_CONFIG_FULL_DUPLEX | EMAC_CONFIG_100MBPS | EMAC_CONFIG_CHECKSUM_OFFLOAD | EMAC_CONFIG_USE_MACADDR0 | EMAC_CONFIG_STRIP_CRC), (EMAC_MODE_RX_STORE_FORWARD | EMAC_MODE_TX_STORE_FORWARD | EMAC_MODE_RX_FLUSH_DISABLE), 0); EMACAddrSet(EMAC0_BASE, 0, psNetif->hwaddr); /* Initialize the DMA descriptors. */ InitDMADescriptors(); /* Clear any stray PHY interrupts that may be set. */ ui16Val = EMACPHYRead(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_MISR1); ui16Val = EMACPHYRead(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_MISR2); /* Configure and enable the link status change interrupt in the PHY. */ ui16Val = EMACPHYRead(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_SCR); ui16Val |= (EPHY_SCR_INTEN_EXT | EPHY_SCR_INTOE_EXT); EMACPHYWrite(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_SCR, ui16Val); EMACPHYWrite(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_MISR1, (EPHY_MISR1_LINKSTATEN | EPHY_MISR1_SPEEDEN | EPHY_MISR1_DUPLEXMEN | EPHY_MISR1_ANCEN)); /* Read the PHY interrupt status to clear any stray events. */ ui16Val = EMACPHYRead(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_MISR1); /** * Set MAC filtering options. We receive all broadcast and mui32ticast * packets along with those addressed specifically for us. */ EMACFrameFilterSet(EMAC0_BASE, (EMAC_FRMFILTER_HASH_AND_PERFECT | EMAC_FRMFILTER_PASS_MULTICAST)); // IMPORTANT on TM4C129!!! // Disable all the MMC interrupts as these are enabled by default at reset. HWREG(EMAC0_BASE + EMAC_O_MMCRXIM) = 0xFFFFFFFF; HWREG(EMAC0_BASE + EMAC_O_MMCTXIM) = 0xFFFFFFFF; /* Clear any pending MAC interrupts. */ EMACIntClear(EMAC0_BASE, MAP_EMACIntStatus(EMAC0_BASE, false)); EMACTxEnable(EMAC0_BASE); EMACRxEnable(EMAC0_BASE); // reenable MAC interrupts after configuring EMAC IntEnable(INT_EMAC0); /* Enable the Ethernet RX and TX interrupt source. */ EMACIntEnable(EMAC0_BASE, (EMAC_INT_RECEIVE | EMAC_INT_TRANSMIT | EMAC_INT_TX_STOPPED | EMAC_INT_RX_NO_BUFFER | EMAC_INT_RX_STOPPED | EMAC_INT_PHY));

  • Hi,

      90 seconds certainly is not expected.

      Doesn't your partner support Auto-MDI-X?

       Can you try below? Do you see any differences?

    EMACPHYConfigSet(EMAC0_BASE, EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | EMAC_PHY_AN_100B_T_FULL_DUPLEX); 
    or
    EMACPHYConfigSet(EMAC0_BASE, EMAC_PHY_FORCE_100B_T_FULL_DUPLEX | EMAC_PHY_INT_FAST_MDIX | EMAC_PHY_INT_MDIX_EN);
    

    
    

     

  • My partner does not support Auto-MDI-X. It's just a simple network hub with uplink/downlink button.

    I was able to get link with

    EMACPHYConfigSet(EMAC0_BASE, EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | EMAC_PHY_AN_100B_T_FULL_DUPLEX);

    but I can see in the PHY status and BMCR registers that the auto negotiation is enabled and completed. So the devices settings are not FORCED which was the goal in the first place.

    Or does the auto-negotiation always need to be ON for auto MDI-X to work?

  • I have an update. I have tried to change the init sequence according to some random code that I have found on these forums.

    The link up time is now roughly 10 seconds.

    This doesn't make much sense to me as I am deviating from what datasheet specifies as correct PHY configuration sequence.

    Nevertheless 10 seconds is still 2,5 times the time that IEEE 802.3 allows.

    The new initialization is as follows (up to the physical address setting. After that everything is kept the same):

      // Enable and reset the Ethernet modules
      MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_EMAC0);
      MAP_SysCtlPeripheralReset(SYSCTL_PERIPH_EMAC0);
    
      MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_EPHY0);
      MAP_SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0);
      
      while(!MAP_SysCtlPeripheralReady(SYSCTL_PERIPH_EMAC0)) {}
      
      MAP_EMACPHYConfigSet(EMAC0_BASE, (EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | EMAC_PHY_INT_ROBUST_MDIX | EMAC_PHY_FORCE_100B_T_FULL_DUPLEX));
      
      // init EMAC
      MAP_EMACInit(EMAC0_BASE, ADN_SYS_CORE_FREQ, (EMAC_BCONFIG_FIXED_BURST | EMAC_BCONFIG_PRIORITY_FIXED), 1, 1, 0);
      // configure EMAC
      MAP_EMACConfigSet(EMAC0_BASE, (EMAC_CONFIG_100MBPS | EMAC_CONFIG_FULL_DUPLEX | EMAC_CONFIG_CHECKSUM_OFFLOAD |
      EMAC_CONFIG_USE_MACADDR0 | EMAC_CONFIG_STRIP_CRC), (EMAC_MODE_RX_STORE_FORWARD | EMAC_MODE_TX_STORE_FORWARD |
      EMAC_MODE_RX_FLUSH_DISABLE), 0);

     

  • Hi,

    user5339916 said:
    I have tried to change the init sequence according to some random code that I have found on these forums.

    Is the below random code you are referring to as reducing the link time down to 10 seconds?

      MAP_EMACPHYConfigSet(EMAC0_BASE, (EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | EMAC_PHY_INT_ROBUST_MDIX | EMAC_PHY_FORCE_100B_T_FULL_DUPLEX));
    

    user5339916 said:
    This doesn't make much sense to me as I am deviating from what datasheet specifies as correct PHY configuration sequence.

     The datasheet says "Auto-MDIX can be used in the forced 100Base-TX mode. Because in modern networks all the nodes are 100Base-TX, having the Auto-MDIX working in the forced 100Base-TX mode resolves the link faster without the need for the long Auto-Negotiation period."

      With the above statements, it seems the datasheet is suggesting Auto-MDIX (my interpretation is just normal Auto MDI/MDIX) rather than robust MDIX will resolve the link time. It also qualifies the statement by saying "without the need for the long Auto-Negotiation period". This seems to imply that Auto-Negotiation is also turned while the Auto-MDIX is enabled. 

      Honestly, I don't have the PHY expertise to explain why the link time is taking 90 or 10 seconds. I wonder if you try with other models of hubs will you see any differences? How about changing the cable?

     Can you try Fast Auto MDI/MDIX mode? Will you see difference?

  • This is the code that I have used as an "inspiration":

    https://e2e.ti.com/support/microcontrollers/other/f/908/t/493117

    The difference is that now I do not hold the PHY from transmitting energy on the line during configuration and I do not set the DONE bit in the Ethernet PHY Configuration 1 as recommended by the tm4c1294ncpd datasheet at chapter "20.5.1.2 Custom Configuration".

    At forced 100Base-TX mode the robust MDIX is the only setting that works for me.

    If I use plain Auto MDI-X or Fast MDIX I get no link at all.

    I have tried various hubs and cables (up to just 30cm long shielded CAT6 cable) but with no difference.

    As you have mentioned, the datasheet clearly states that Auto-MDIX can be used with forced 100Base-TX mode. As there is no further explanation or example I would assume that it is as straight forward as setting the interface to forced settings and turning on the Auto-MDIX. Yet it's clearly not that easy.

  • Hi,
    I'm not really an expert in the PHY. I'm a bit confused with you trying to force 100Base-TX mode with robust MDIX when you earlier said that you could get it to work without the robust MDIX. Earlier you said that below configuration will work. If this is the case, why do you need to force it manually? What is the reason that you don't want to use auto-negotiation?


    EMACPHYConfigSet(EMAC0_BASE, EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | EMAC_PHY_AN_100B_T_FULL_DUPLEX);
  • Charles Tsai said:
    why do you need to force it manually? What is the reason that you don't want to use auto-negotiation?

    Because I am developing a commercial product with set requirements. I can't tell the customer what the device can and can not do. If TI claims support for some functionality I expect it to work.

  • Hi,
    Sorry for getting back to you now. Are you making any progress as far as the link time? It seems to me that if you use the below config then it works for you. This is also the configuration we use in all the ethernet examples.

    EMACPHYConfigSet(EMAC0_BASE, EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | EMAC_PHY_AN_100B_T_FULL_DUPLEX);
  • No further progress. The link time is still roughly 10 seconds.

    I am not sure why you are bringing up again that it works with auto negotiation settings. This is not what this thread is about. The issue is that it performs poorly with forced settings and does not work at all when you stick to the configuration sequence suggested by datasheet.

  • Hi,

     I tried both the below configurations on the TivaWare enet_lwip example and I couldn't find much difference in terms of the link time. I have the LaunchPad running the enet_lwip connected to a switch. I don't have a hub.

    /* the first one is what is originally used in the example */

    #define EMAC_PHY_CONFIG (EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN |  EMAC_PHY_AN_100B_T_FULL_DUPLEX)

    /* The second one is what you used to force robust MDIX */

    #define EMAC_PHY_CONFIG (EMAC_PHY_FORCE_100B_T_FULL_DUPLEX | EMAC_PHY_INT_ROBUST_MDIX | EMAC_PHY_INT_MDIX_EN)

    Below are the results I found.

    Using EMAC_PHY_FORCE_100B_T_FULL_DUPLEX | EMAC_PHY_INT_ROBUST_MDIX | EMAC_PHY_INT_MDIX_EN



    Using EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN |  EMAC_PHY_AN_100B_T_FULL_DUPLEX



    As you can see in both the wireshark captures, the time from DHCP Discover until the beginning of the ARP is about 1 second. Can you try with a switch and see if you see any differences between the two configurations? 

    In either case for me, it was pretty fast between Waiting for link and Waiting for IP address. 

  • Hello Charles,

    couple of questions here.

    • Are you using cross cable and are you sure that your switch does not have Auto MDIX capability?
      Because even if you use the cross cable and the switch is auto mdix capable than the whole auto mdix process could have been done by the switch itself. This had happened to me in past. Turns out the TIVA did not contribute to the fast link acquiring. It was the switch.
    • How is time between DHCP discover and first ARP related to the link time? Maby I am missing something but I don't see any connection as you already had link at DHCP discover. Otherwise you would not be able to send any frame.
    • I am not that familiar with the enet_lwip example but from a brief look traces "Waiting for link" and "Waiting for IP address" are triggered only by change in IP value, not in actual physical link state in any way. Did I miss something?

  • Hi,
    I'm not using cross over cable and my switch does have auto-mdix capability. What I tried to demonstrate is that I don't see any difference between the two different PHY configurations (auto-negotiate vs forced) from the MCU side point of view. I must admit you know more than me in this regard. You seem to suggest that if the switch is auto-MDIX capable then it doesn't really matter how the PHY is configured for auto-negotiate or forced. I understand you are using a hub. I'm curious the issue you have is only when the hub is used or the link partner doesn't support auto-MDIX.