TM4C1294NCZAD: Force 100Base-T Problem

Part Number: TM4C1294NCZAD
Other Parts Discussed in Thread: EK-TM4C1294XL

Hello,

I am trying to adapt the enet_tcpecho_client_tirtos example NDK program to force a 100Base-T connection. Following another user's post, I added the following code to the initEMAC function in the example program. However, my network speed remains at around 10Mbps. See also the next two images showing that ANMODE in the EMAC0 register EMACPC remains 1 (auto negotiation enabled), even though the EMAC_PHY_FORCE_100B_T_FULL_DUPLEX macro should disable auto negotiation.

What am I doing wrong in my code?

initEMAC function with 100Base-T force code:

EMAC0 EMACPC Register view showing ANMODE = 1 (auto negotiation still enabled).

EMAC0 EMACCFG Register view showing FES = 0 (speed = 10Mbps).

  • Hi,

      The PHY configuration is done in C:\ti\tirtos_tivac_2_16_00_08\products\tidrivers_tivac_2_16_00_08\packages\ti\drivers\emac\EMACSnow.c file. The EMAC_PHY_CONFIG is currently defined as:

    #define EMAC_PHY_CONFIG (EMAC_PHY_TYPE_INTERNAL | \
                                                       EMAC_PHY_INT_MDIX_EN | \
                                                       EMAC_PHY_AN_100B_T_FULL_DUPLEX)

    You need to change to:

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

    Since this file EMACSnow.c is part of the driver library, you will need to rebuild the library after the change. However, another easier way is to simply copy EMACSnow.c file to your project directory where your application is. Make the change locally, and then rebuild the application. The local copy will be used instead of the library version.

      

  • Hi,

    Thank you for the response. I followed these steps, but when I change EMAC_PHY_AN_100B_T_FULL_DUPLEX to EMAC_PHY_FORCE_100B_T_FULL_DUPLEX, my MCU no longer connects to my PC over ethernet. Do you have any idea why this might be happening? 

    In that same EMACSnow.c file, I added the EMAC_COFIG_100MBPS macro option to EMACConfigSet, and while that did set the FES (speed) flag to 1 (indicating 100Mbps) in the EMAC_CFG register, the actual speed of communication hasn't changed. Like you said, I believe I need to change the PHY settings to set the speed.

  • Hi,

    I change to bellow in the EMACSnow.c file. I remove the EMAC_PHY_INT_MDIX_EN flag and it seems to work for me as my PC (acting as a client) can connect to the LaunchPad (acting as a server). 

    #define EMAC_PHY_CONFIG (EMAC_PHY_TYPE_INTERNAL | \
    EMAC_PHY_FORCE_100B_T_FULL_DUPLEX)
    #endif 

    To give you a heads-up. I'm on vacation already and will not be able to respond until next Tuesday, 

  • followed these steps, but when I change EMAC_PHY_AN_100B_T_FULL_DUPLEX to EMAC_PHY_FORCE_100B_T_FULL_DUPLEX, my MCU no longer connects to my PC over ethernet.

    Is your PC set to fixed 100Mbps full duplex, or is the PC set to auto-negotiate?

    100mbps Full Duplex vs Auto-Negotiate describes some issue which can occur if one line partner is set to auto-negotiate and the other is set to fixed 100Mbps full-duplex. 

  • Hi Charles,

    Following your advice (removing the MDIX_EN flag) my MCU now communicates with the PC -- but still at a 10Mbps speed. The FES flag is set to 1 now, but I believe that is due to the EMAC_CONFIG_100MBPS flag I added to EMACConfigSet command (also in EMACSnow.c). Also, the AN (auto-negotiation) flag is still set to 1, which leads me to believe that the EMAC_PHY_FORCE_100B_T_FULL_DUPLEX flag isn't entirely working, since according to the TivaWare Peripheral API it should disable auto-negotiation (AN = 0).

  • Hi Chester,

    Thanks for this information. So far changing the PC auto-negotiation settings hasn't affected the performance, but I will keep this in mind for future reference.

  • Hi,

      I try both a lwIP and TI-RTOS tcp_echo examples and as far as ANEN, both show ANEN=0 which means auto-negotiation is disabled. 

    Register setting on lwIP tcp_echo example.

    Register setting on TI-RTOS tcp_echo example. 

  • Thank you for the response... this is interesting.

    In my application the board is the client. Is the ANEN flag successfully set to zero when you use the client example as well?

  • I now try a client example and it show the same. I use a tp-link TL-SG105E switch from home. Not sure if the type of switch makes a difference though. 

  • I'm doing a direct point-to-point connection without a switch (a single Ethernet cable connecting my PC to my board), and am statically assigning an IP address to my board. Not sure if that would affect this auto-negotiation issue though.

    I'll try to troubleshoot more and get back to you. Thanks.

  • I'm doing a direct point-to-point connection without a switch (a single Ethernet cable connecting my PC to my board)

    Do you have a cross over cable (TX-RX and RX-TX) at both ends RJ45 plugs? A straight through cable will only work with switch ports.

  • A straight through cable will only work with switch ports.

    I believe my PC has Auto MDI-X functionality, so it's not a problem. My connection is working now, just not at the desired 100Mbps.

  • I realized that I was using the wrong macro (AN instead of FORCE), and now my ANEN flag is 0. However, according to Wireshark and Task Manager, my speed is still maxing out at about 10Mbps. I'm using a simple modification of the example code to keep sending messages (send() inside an infinite loop) from the board to the PC. Do you know of any better ways of testing speed/bandwidth? Perhaps my current method is limiting my speed.

  • My connection is working now, just not at the desired 100Mbps.

    Generally 10/100 Nic auto negotiate enabled both ends of the connection, will be established 100 MBPS. Unless the cable has a bad RJ45 crimp/s into solid copper wire it might down shift to 10 MBPS. Though some device layer connection issues might not push packets upward into the network or application layers.

  • I see. Thank you for the explanation. I will purchase the TM4C1294XL evaluation kit to test this issue and compare with my custom board's performance.

  • A custom PCB could be Ethernet XFMR issue or differential pairs inductance, even the PCB layout. My PCB has 2 vias for each pair of equal lengths 2-sided  layout. Charles might have some additional pointers to check in that area, posting schematic of Ethernet area would help.

  • I'm using a simple modification of the example code to keep sending messages (send() inside an infinite loop) from the board to the PC.

    TM4C1294KCPDT: Throughput Test in TM4C1294 Micro-Controller contains my notes on the last time I looked at the maximum throughput in a TM4C129 device using the NDK,

    With your hardware you try running the test program in the referenced thread and see if can repeat my previous result of 55.5 megabits/second in each direction.

  • Thank you for this resource! I am on vacation next week, so I will test this when I'm back the following Monday.

  • Hi Chester,

    Using your Throughput Test, I am now achieving around 26megabits/second in each direction (screenshot attached). So, about half of your speed. 

    I tested this on the EK-TM4C1294XL Launchpad, as well as on my custom board, and got the same result for both (~26Mbps). 

    Maybe there is something wrong with how I am setting up my command line instances for running tcpSendReceive? Attached is a screenshot showing my four command line windows running. 

    Note: With one command line instance, Task Manager shows my Ethernet speed as ~21Mbps, and a second instance knocks it up to ~26Mbps. After that (adding a third, fourth), the speed doesn't change.

    Thank you.

    [Screenshot of Task Manager Ethernet Speed]

    [Screenshot of Four Command Line Instances]

  • Running the same test I'm seeing about 28Mbps using Windows task manager for measurement. I don't have much in-depth knowledge on the NDK stack to suggest what else to change to improve though. Please also note that when you say you measure 26Mbps it is separated to TX and RX directions. When you add them together it will be 52Mbps. 

  • Running the same test I'm seeing about 28Mbps using Windows task manager for measurement.

    Looking back at my previous test where said got "Ethernet throughput in each direction was 55.5 megabits/second", at the time was running the tcpSendReceive on Linux rather than Windows.

    The throughput could be limited by either the TM4C or Windows end, depending upon the socket buffering.

    I can try and repeat the measurement at the weekend, including running tcpSendReceive on both Windows and Linux.

  • Good to know, thank you!

  • Note: With one command line instance, Task Manager shows my Ethernet speed as ~21Mbps, and a second instance knocks it up to ~26Mbps. After that (adding a third, fourth), the speed doesn't change.

    I have run the test again, and adding a third or fourth instance isn't increasing the speed.

    Am using a managed switch with 10M/100M/1000M ports. The PC has a 1000M connection to the switch. The switch indicates as expected the port on the TM4C129 is "100M, full duplex".

    To measure the bandwidth looking at Bandwidth Utilization reported by the switch for the port the TM4C129 is connected to.

    When running tcpSendReceive under Windows 10 or Linux (AlmaLinux 8.6 or Ubuntu 18.04) the steady state bandwidth utilization is 35% RX and TX of a 100M link, so 35Mbps in each direction:

    However, if leave the test running at times can samples of 70% (70 Mbps) or even 100% (100Mbps) utilization:

    At the moment not sure how to increase the steady state utilization.

  • Hi Chester,

      Thank you for doing the measurements. The firmware for my switch does not provide the utilization. I wonder if you were to use Windows task manager to measure the Ethernet bandwidth, will you see consistent data compared to your switch utility. 

  • Hi Chester,

    Thanks for looking into this. My team is mostly concerned with making sure that our board's ethernet speed isn't limited by its hardware. Since we have gotten the board's speed to reach ~26Mbps, and a similar limit seems to be repeated on TI launchpads as well, I am fairly comfortable with saying that our board's hardware is not what's limiting the ethernet speed.

    Please let me know if you find a different test method that shows a higher bandwidth utilization percentage. Otherwise, I think this is all the information that I needed.

    Thanks.