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.

using EPHY_BMCR_SPEED in EMACPHYWrite prevents link on TM4C

Other Parts Discussed in Thread: EK-TM4C1294XL

Hello,

I am adding a feature in our product that has been requested by our customers. The feature requested is the ability to disable auto-negotiation and set the link duplex and speed staticly.

So far I can set the link to 10Mbps Half duplex and 10Mbps Full duplex (which negotiates to half due to IEEE standards) however when I attempt to set it to 100Mbps full or 100 Mbps Half the device is unable to establish a network link. (LINKSTAT on MR1 is reporting 0)

Due to some existing issues in the tiva_tm4c129.c file I have already been required to make modifications to disable auto-negotiation. I removed:

EMACPHYWrite(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_BMCR, (EPHY_BMCR_ANEN | EPHY_BMCR_RESTARTAN));

to prevent negotiation.

When I write the following to the EMACPHY the link cannot be established.

EMACPHYWrite(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_BMCR, (EPHY_BMCR_DUPLEXM | EPHY_BMCR_SPEED));

or

EMACPHYWrite(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_BMCR, (EPHY_BMCR_SPEED));

However when I write this to the same register the link works fine:

EMACPHYWrite(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_BMCR, (EPHY_BMCR_DUPLEXM));

or

EMACPHYWrite(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_BMCR, 0);

Any ideas what I might be doing wrong?

Thanks,

Jonathan L Clark

  • Hello Jon,

    Are you performing the experiments on a known example or is it a custom code?

    Regards
    Amit
  • It is custom code, but the code I am modifying to make this happen is part of the code that comes with the Tiva MCU. The lwiplib.c and tiva-tm4c129.c are the same as what comes with the TM4C connected-launchpad sample.

    Thanks,

    Jonathan L Clark

  • Hello Jonathan,

    Can you please attach the files w.r.t qs_iot example (or whichever example you are referring to) that have been modified?

    Regards
    Amit
  • Hello Amit,

    So the only files that are the similar from the example are the low level lwip files previously mentioned. We had a contractor port our entire code base from the Stellaris to the Tiva. The only reason I know that our lwip files are similar is because I inspected them briefly during the porting process. We are currently using FreeRTOS, lwip and our own code base. Which of those files do you need? I don't think I am supposed to give out our own proprietary base code, but I think I can give you some of the lwip files.

    Thanks,

    Jonathan L Clark
  • Hello Jonathan,

    OK. Let me try the qs_iot example with the changes you have posted.

    Regards
    Amit
  • Hello Amit,

    How do you want me to post the files? Just add all the code in this form?

    Jonathan L Clark
  • Hello Jonathan,

    If the lines of code change in your original post is the only configuration difference, then no need to. Otherwise, the changes that you have made, please give the file name, line number where it has been added (with before and after code shown so that it becomes a reference) and the code change

    Regards
    Amit
  • Hello Amit,

    Yeah those are the only changes.

    I just had a meeting with my managers and they have informed me that this issue is now critical. They have told me that the company is willing to pay for support from TI to get this resolved. They also would like to setup a conference call with someone from TI support (you perhaps?) to go over the issue.

    In the mean time I am going to get a hold of a TM4C connected launchpad. I am going to attempt to reproduce the problem with a basic setup.

    What do we need to do to get additional support (maybe a Ticket) from TI?

    Thanks,

    Jonathan L Clark

    Firmware Engineer

    Telect https://www.telect.com/ 

  • Hello Jonathan,

    If you have an assigned FAE from TI, you may want to contact them. Else you may want to contact the local sales office in your region.

    Regards
    Amit
  • Hello Jonathan,

    So on my EK-TM4C1294XL I tried the settings. The example that I am using enet_lwip.

    In the file tiva-tm4c129.c I commented out the line for BMCR re-configuration

    /* Tell the PHY to start an auto-negotiation cycle. */
    // EMACPHYWrite(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_BMCR, (EPHY_BMCR_ANEN |
    // EPHY_BMCR_RESTARTAN));

    In the project header file lwipopts.h I changed the lines

    #define EMAC_PHY_CONFIG (EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | \
    EMAC_PHY_AN_100B_T_FULL_DUPLEX)

    to

    #define EMAC_PHY_CONFIG (EMAC_PHY_TYPE_INTERNAL | \
    EMAC_PHY_FORCE_100B_T_HALF_DUPLEX)

    Recompiled the project and ran it. It works. Also tried changing EMAC_PHY_FORCE_100B_T_HALF_DUPLEX with EMAC_PHY_FORCE_100B_T_FULL_DUPLEX and it works as well.

    What I believe is happening, is that you are trying to reconfigure the BMCR register while the PHY is transmitting energy on the line. There is a specific sequence that is needed as described in the data sheet.

    Regards
    Amit
  • Hello Amit,

    Thanks! This has solved the problem! I verified on a connected launchpad that this did indeed fix the issue and the settings can now be set correctly!

    Thanks,

    Jonathan L Clark
  • Hello Jonathan

    Also this should allow you to revert the earlier change and use the lwipopts.h to use Forced 10/100 Half or Full duplex mode.

    Regards
    Amit
  • Amit Ashara said:
    In the file tiva-tm4c129.c I commented out the line for BMCR re-configuration

    /* Tell the PHY to start an auto-negotiation cycle. */
    // EMACPHYWrite(EMAC0_BASE, PHY_PHYS_ADDR, EPHY_BMCR, (EPHY_BMCR_ANEN |
    // EPHY_BMCR_RESTARTAN));

    In the project header file lwipopts.h I changed the lines

    #define EMAC_PHY_CONFIG (EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | \
    EMAC_PHY_AN_100B_T_FULL_DUPLEX)

    to

    #define EMAC_PHY_CONFIG (EMAC_PHY_TYPE_INTERNAL | \
     EMAC_PHY_FORCE_100B_T_HALF_DUPLEX)

    The change to EMAC_PHY_CONFIG removed the EMAC_PHY_INT_MDIX_EN option, which disables auto-MDI/MDIX crossover. When I tried making changes to set a forced speed and duplex, but without removing the EMAC_PHY_INT_MDIX_EN option, found that the link wasn't established. The BMCR re-configuration was also commented out from the tiva-tm4c129.c file.

    The test setup has a EK-TM4C1294XL connected to a remote LAN8710A Phy via a straight-though Ethernet cable, with the LAN8710A connected to a CPSW port in a AM3552. Different combinations of EMAC_PHY_CONFIG were tested with forced speed and duplex. The remote LAN8710A Phy was set to auto negotiate speed and duplex, with Auto-MDIX enabled.

    The results are:

    1) With:

    #define EMAC_PHY_CONFIG (EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | \
                             EMAC_PHY_FORCE_10B_T_FULL_DUPLEX)
    

    The link was not established.

    2) With:

    #define EMAC_PHY_CONFIG (EMAC_PHY_TYPE_INTERNAL | \
                             EMAC_PHY_FORCE_10B_T_FULL_DUPLEX)
    

    The link was established as 10M half-duplex.

    [While the link was forced to 10M full-duplex at the Tiva end, the link actually operates at half-duplex as per the IEEE standard]

    3) With:

    #define EMAC_PHY_CONFIG (EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | EMAC_PHY_INT_ROBUST_MDIX | \
                             EMAC_PHY_FORCE_10B_T_FULL_DUPLEX)
    

    The link was established as 10M half-duplex.

    4) With:

    #define EMAC_PHY_CONFIG (EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | \
                             EMAC_PHY_FORCE_100B_T_FULL_DUPLEX)
    

    The link was not established.

    5) With:

    #define EMAC_PHY_CONFIG (EMAC_PHY_TYPE_INTERNAL | \
                             EMAC_PHY_FORCE_100B_T_FULL_DUPLEX)
    

    The link was established as 100M half-duplex.

    6) With:

    #define EMAC_PHY_CONFIG (EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | EMAC_PHY_INT_ROBUST_MDIX | \
                             EMAC_PHY_FORCE_100B_T_FULL_DUPLEX)
    

    The link was established as 100M half-duplex.

    The tests show that to establish a link with forced speed and duplex, if Auto-MDIX is to be enabled then Robust MDIX also needs to be enabled.

    The description of Robust Auto MDI/MDIX in the TM4C129 datasheet confirms this:

    Robust Auto MDI/MDIX

    If link partners are configured to operational modes that are not supported by normal Auto MDI/MDIX mode (like Auto-Neg versus Force 100Base-TX or Force 100Base-TX versus Force 100Base-TX), this Robust Auto MDI/MDIX mode allows MDI/MDIX resolution and prevents deadlock.

    Value Description

    0         Normal Auto MDI/MDIX mode.

    1         Enable Robust Auto MDI/MDIX resolution.

  • Hello Chester,

    Very interesting data, And could this be because I have connected it to a n/w switch which would be negotiating both speed and crossover?

    Regards
    Amit
  • Amit Ashara said:
    And could this be because I have connected it to a n/w switch which would be negotiating both speed and crossover?

    I believe so, in that most modern switches will be default negotiate both speed, duplex and crossover.

    Looking at a D-Link DES-3526 the default is to negotiate Speed/Duplex. The Speed/Duplex can be changed from negotiate to fixed values, but there is no option to control if crossover is negotiated or forced.

  • Hello Chester

    And I am not sure either if the switch I have does that either. Let me check though

    Regards
    Amit