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: Long Ethernet link up time

Part Number: TM4C1294NCPDT


Hi. We are using TM4C1294 MCU in internal PHY mode for Ethernet.

Problem: Linking sometimes takes up to 30 seconds, sometimes doesn't even link, rare cases it gets link in few seconds.

My observations:

With oscilloscope I see FLP(fast link pulses) and their timing seems ok. But what is strange is what happens right after few FLP bursts. It seems like the PHY starts sending some data. When I check the tivaif_transmit function(which is furthest I can get with transmition in software) it shows no activity - so this data(if it is data) is not originated from software.

Also I noticed that I get very similar pulses at the same time on both Tx and Rx pair. I don' know if FLPs should be sent out on both pair at the same time, but I doupt it - so pulses at the same time would mean that it is interference caused by crosstalk? 

This test mentioned above was done without cable plugged in the RJ45 socket.

I also checked PHY registers, and what seemed strange is that LPANABLE and EPHYANLPA registers change their value at the same time very few seconds. 

LPANABLE  = 4, EPHYANLPA = 0

LPANABLE  = 5, EPHYANLPA = 16865

From these registers and all other observations I think what is happening is that MCU detects its own FLP pulses and think's it can autonegotiate and then fails, and this happens all the time and interferes with the real autonegotiation process.

I already tried different RJ45 mag jack but with no positive results. 

In attachment you can see some images with FLP and the "data" or whatever that is send afterwards.

Can you please help? We have customers, waiting for solution... Thanks in advance.

images.zip

  • Here is schematics of our Ethernet connection. Connector used is 6605834-1. I also tried LMJ2018814100DT1 but with no positive results.

  • Hi,
    I'm not sure what the problem is. My understanding is that the auto-negotiation is a protocol. This means that the auto-negotiation will only works if it’s running on both sides of the link. You are saying that you don't have the cable plugged. I don't understand how you can auto-negotiate without the cable. I'm not an expert the PHY though. Can you try plugging a good quality CAT5E cable to your network and run some TCP/IP applications and do you see the link up time differently or the same? Can you also try the same with the launchpad board?
  • The problem is that the linking happens way too long, and my observation is that it is because of the internal PHY thinking it has connected and starts transmitting something.

    From this I understood that  FLP bursts should happen all the time even without cable connected.

    I think I managed to find the issue. I soldered new TM4C on the same board and everything works fine. There is no "garbage/fake" data comming without cable, and 2 registers which I mentioned does not change their values randomly without cable plugged in. Refer to images added to the first post- there you can see the FLP bursts and random data comming without cable plugged in.


    My guess is that the internal PHY has been damaged through electric fast transients, ESD or surge induced currents/voltages. This did not kill the PHY, but it just works very strangely. We have no protection on board for Ethernet so I think that might be the cause of problems. Can someone from TI with experience with internal PHY of TM4C approve my thoughts?

  • Hi Karlis,
    Glad that you are able to isolate the problem. Yes, you will need ESD protection for the PHY. Please follow the recommendation as depicted in the TM4C129 system design guideline. www.ti.com/.../spma056.pdf.
  • Hi Karlis,
    I will close this thread for now. If you have questions you can open a new thread or reopen this thread.