• State TI Thinks Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 1326 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.

RTOS/TM4C129XNCZAD: Auto-Negotiation Problem

Erman Oezdemir
Prodigy 180 points
Part Number: TM4C129XNCZAD


Tool/software: TI-RTOS

Hello,

We have a PCB with a TM4C129X and I will try to state the problem we are facing:

1- We are using TI-RTOS. TIRTOStivac:2.16.1.14. We are using EMAC_init(). This eventually initializes the PHY according to EMAC_PHY_CONFIG define in EMACSNOW.c .  EMAC_PHY_AN_100B_T_FULL_DUPLEX . 

2- From product requirement point of view, this is exactly what we want. We want the customers to be able to connect with our devices, as fast as their device allows.

2- When we connect the PCB with many network adapters, for example to a USB-Ethernet Adapter,  D-Link DUB-E100, everything goes on as expected. Auto-negotiation results in a very stable link that is established at 100Mbps with Full Duplex. This is verified with reading the Phy status register also. ( with EMACPHYRead(EMAC0_BASE, 0, 0x010) ).

3- However, when we connect the to "some" ethernet hubs/switches, to give an example, Allied Telesis AT-FS705EFC, auto-negotiation fails with this setting. How it fails is as follows (from now on i will just say switch for AT-FS705EFC)  :

  • It connects, link is up, Ethernet PHY status register value becomes 0x0F15 (Link is up, 100Mbit, Full duplex, bit4 is 1 so auto negotiation is complete)
  • At the same time Ethernet PHY Basic Mode Status (0x01) has the value of  0x786D.
  • In about 1 sec, link is broken. At the FW poll time when the link is broken,
    • Ethernet PHY Basic Mode Status (0x01) : 0x7849
    • Ethernet PHY Status (0x10)  : 0x0902

4- When i force the connection with 100Mbit full duplex, with changing the config to, EMAC_PHY_FORCE_100B_T_FULL_DUPLEX, it doesnt work. Connection can not be established, link is never up.

5- When i force the connection with 10Mbit full duplex, or 100Mbit half duplex, ceteris paribus, with just changing the config to, EMAC_PHY_FORCE_10B_T_FULL_DUPLEX or EMAC_PHY_FORCE_100B_T_HALF_DUPLEX, it does work. Very stable connection is established  to the AT-FS705EFC with no problems.

6- When i connect any other 3rd party device to the AT-FS705EFC switch with 100Mbit full duplex, switch can establish a connection. So switch does not have an innate problem of not being able to establish 100Mbit Full duplex.

7- Also worth noting, EMAC_PHY_AN_100B_T_HALF_DUPLEX, EMAC_PHY_AN_10B_T_FULL_DUPLEX, does not work (same as connect disconnect cycles above) with switch, but EMAC_PHY_AN_10B_T_HALF_DUPLEX works (end result is 10B half as the name suggests, Ethernet PHY Status (0x10) = 0x117). I also fail to understand, specifiying other parameters along with auto-negotiation, and what do they really make.

So now we are coming to the question part:

1) Why our device with EMAC_PHY_AN_100B_T_FULL_DUPLEX config, does not work with the  AT-FS705EFC (and some other) switches/adapters ?

2) Why our device with EMAC_PHY_AN_100B_T_HALF_DUPLEX config, does not work with the switch but  EMAC_PHY_FORCE_100B_T_HALF_DUPLEX works?

3) Does these connect/disconnect cycles have some meaning that i didnt understand ? Should i poll some other registers or am i missing something ?

In case someone is interested links to datasheets of the devices mentioned:

https://eu.dlink.com/uk/en/-/media/consumer_products/dub/dub-e100/datasheet/dub_e100_d1_datasheet_en_eu.pdf

https://www.alliedtelesis.com/sites/default/files/documents/datasheets/fs705efc_ds.pdf

https://www.alliedtelesis.com/documents/installation-guide-fs705efc-and-fs706efc

  • 0
    TI__Guru**** 191906 points

    Hi Erman,

      Did you have a chance to debug a bit further with wireshark when  EMAC_PHY_AN_100B_T_HALF_DUPLEX, EMAC_PHY_AN_10B_T_FULL_DUPLEX are specified with the Allied Telesis AT-FS705EFC switch? I will suggest that you also compare the wireshark traces when you use other settings that works such as EMAC_PHY_FORCE_10B_T_FULL_DUPLEX or EMAC_PHY_FORCE_100B_T_HALF_DUPLEX. 

      Although you said that other 3rd party devices work fine with Allied Telesis AT-FS705EFC switch, the Tiva device also works with other switches such as USB-Ethernet Adapter,  D-Link DUB-E100 when auto-negotiation is specified. Therefore, it is hard to make a conclusion that the problem is not switch dependent. 

      Is it possible for you to run the TivaWare Ethernet example such as enet_io or enet_lwip? These are non TI-RTOS examples. However, they use EMAC_PHY_AN_100B_T_FULL_DUPLEX configuration. Please see below.  Not sure if you have the MDIX enable in your TI-RTOS project.

    #define EMAC_PHY_CONFIG (EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | EMAC_PHY_AN_100B_T_FULL_DUPLEX)

  • 0 in reply to Charles Tsai
    Prodigy 180 points

    Hello Charles,

    Thanks for your reply.

    1) I was unable to anything useful with wireshark. Please see the post below:

    www.wireshark.org/.../msg00117.html

    Do you know any method/guide to use wireshark for autonegotiation problems ?

    2) Even if it is a switch dependent problem, i want to understand, what is exactly the problem.

    Why do switch+tiva system, auto negotiate to a speed where they can not communicate ?

    How can i avoid / block it ? That is my main point.

    3) Full form of EMAC_PHY_CONFIG is as you said. I just changed the speed/duplex part of the define.
    (EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | EMAC_PHY_AN_100B_T_FULL_DUPLEX)

    4) I can not directly try the examples due to board design, but i will have a look for non TI-RTOS, direct Tivaware examples. But i am just curious, what is the difference in the end, or how they would configure the autonegotiation differently, so it may work ? Do you think one of the auto-negotation advertisement register/bits can be the answer ?

    Best regards,

    Erman

     

  • 0 in reply to Erman Oezdemir
    TI__Guru**** 191906 points

    Hi,

      My understanding is that in order for auto-negotiation to work, both sides of the link must be running/supporting auto-negotiation. Auto-negotiation is a protocol and both sides must handshake to determine the ultimate speed and duplex. If one side is not in auto-negotiation mode then auto-negotiation cannot work. This leads to the question if the Allied Telesis AT-FS705EFC switch is supporting and also configured to operate in auto-negotiation mode. Will you be able to find out?

      The reason I asked to run the non TI-RTOS TivaWare examples is just to make sure that there is not anything to do with the TI-RTOS. The TI-RTOS uses a slightly older version of the TivaWare libary. I agree that whether running the TI-RTOS or non TI-RTOS should show the same result but just wanted to make sure this is the case. While you try out the non TI-RTOS example, would you mind to also try the TI-RTOS Ethernet examples. Again, just wanted to make sure TI-RTOS examples and your own application are producing the same behaviors. 

  • 0 in reply to Charles Tsai
    Prodigy 180 points

    Hello Charles,

    I am %100 sure AT-FS705EFC supports and operates auto-negotiation mode. I verified this with 3rd party devices and our old projects. 

    Today, a colleague gave me a "TM4C129X Development Board" and i had a chance to try the following examples with the AT-FS705EFC switch

    • \ti\TivaWare_C_Series-2.1.4.178\examples\boards\dk-tm4c129x\enet_lwip\ccs\Debug\enet_lwip.bin
    • \ti\TivaWare_C_Series-2.1.4.178\examples\boards\dk-tm4c129x\enet_io\ccs\Debug\enet_io.bin

    Both of binaries are working without any problems and stable link is established.

    Which TI-RTOS example(s) would you recommend ?

    Best regards,

    Erman

  • 0 in reply to Erman Oezdemir
    Prodigy 180 points

    I attached the relevant part of our schematic, in case if you think it might be due to our PCB design.

  • 0 in reply to Erman Oezdemir
    TI__Guru**** 191906 points

    Hi,

      Can you try these TI-RTOS examples as shown below? Please use the CCS resource explorer to download these examples into your workspace. 

  • 0 in reply to Charles Tsai
    TI__Guru**** 191906 points

    Hi,

      To determine if the problem is related to the software or your custom hardware can you please do the below experiments. We already know that the TivaWare examples are running fine in the development board.

      1. Run the TI-RTOS Ethernet examples on development board

      2. Run the TI-RTOS Ethernet examples on your custom board

      3. Run the non TI-RTOS TivaWare examples on your custom board. You already reported earlier that it works on the development board.

      4. Run your own application on the development board. 

      I think with the results of the above experiments we can narrow down further the area of the problem. 

  • 0 in reply to Charles Tsai
    Prodigy 180 points

    Hello Charles,

    1- TI-RTOS Ethernet example runs on the development board and communicates with the switch.

    2-3- I implied this earlier, examples dont run on our custom PCB, since its a part of a system and without other peripheral settings in place, it can not start ethernet. I tried running both Tivaware and TI-RTOS and both dont run "as-is". I prefer to avoid making changes to examples to make them "work" in my custom PCB, this would be quite some work.

    4- Our own application runs on the development board and communicates with the switch.

    Does this prove that it is a hardware issue ? 

  • 0 in reply to Erman Oezdemir
    TI__Guru**** 191906 points

    Hi Erma,

      Your #4 result does provide some evidence that it may be hardware related. I will suggest you compare your PCB particularly the Ethernet interface with the recommendation in the TM4C129 system design guideline. I will also take a look at your schematic too. 

      The system design guideline can be found at the below link.

    You seem to be using the RJ45 with the built-in magnetic. Correct me if I'm wrong. The system design has reference schematic for an external magnetic (between the PHY and the protection diodes) Below is a link to a TI design that implements the RJ45 with the built-in magnetic. Take a look at and compare with its Ethernet hookups. 

    http://www.ti.com/tool/TIDM-TM4C129POE

  • 0 in reply to Charles Tsai
    Prodigy 180 points

    Hello Charles,

    Yes, we have internal magnetics. Our hookup and the example hookup you posted are almost same. RJ45 connectors with external magnetics are different brands but they have same properties too.

    Best regards,

    Erman

  • 0 in reply to Charles Tsai
    Guru 55963 points

    Charles Tsai said:
    My understanding is that in order for auto-negotiation to work, both sides of the link must be running/supporting auto-negotiation. Auto-negotiation is a protocol and both sides must handshake to determine the ultimate speed and duplex

    I don't think that is entirely true. We used to set Cisco switch ports fixed 10Mbps for certain Windows XP network cards set to auto negotiate would then connect at 10MBPS,  otherwise not at all.

    I would be more concerned if a custom PCB layout was more the issue.

  • 0 in reply to Erman Oezdemir
    Guru 55963 points

    Hi Erman,

    Regarding C3304/5 (100nF) if +3v3 is spikey (noisy) or single trace versus wide copper plane you might try 1000nF to 4700nF. Check all points with scope, not DMM.

  • 0 in reply to Erman Oezdemir
    TI__Guru**** 191906 points

    Hi Erman,

      If your application runs on the development board but not your custom board then it is enough evidence to suggest some differences in your board is causing it not to work in a robust/stable way. I understand there is some effort involved but I will still suggest if you could modify/port the TivaWare example to your custom board to further isolate the problem. If the TivaWare examples on your board doesn't work with a particular switch but ok with others then it again reinforces our understanding of the problem.

      I also wanted to give you a heads up that I will be out of office for a week starting tomorrow with very limited access to the forum.  

  • 0 in reply to Charles Tsai
    TI__Guru**** 191906 points

    Hi Erma,

      Did you have a chance to port the TivaWare examples to your custom board as I suggested to further prove that it may be a hardware problem on the board? I also notice that you didn't have the ESD diodes between the RJ45 and the PHY as recommended in our system design guideline as well as in the TI design that uses the RJ45 with the built-in transformer. Although I can't say for sure if this is the root cause of your problem, it is quite important to have the ESD diodes on the Ethernet interface to protect the transient threats. 

      I find this article  useful for your understanding. 

    https://interferencetechnology.com/defending-ethernet-ports-from-electrical-transient-events/

      Another way to find out if your issue is related to the missing ESD diodes is to insert these diodes at the proper place in your PCB. This is anyway needed regardless of your current issue. 

      I will close this thread for now. I hope I have provided you information for you to make some judgement on your next steps. If you have some updates that you want to share you can just reply back to this thread.