TM4C1294KCPDT Link strange problem

Not sure if the following errata could cause a failure for the link to fail to be established with some external devices:

Has the work-around for ETH#02 been implemented?

If you are using the TI-RTOS Ethernet driver, http://processors.wiki.ti.com/index.php/TI-RTOS_TM4C129_Emac_Issues describes where to check for the work-around being applied.

Hello Chester,

Yes, the WA has been implemented, in TI RTOS drivers, in the latest release made.

Regards
Amit

Hello, Amit!

We have fixed in our software the ETH#02 error, which is described in ERRATA. After we done this, some devices started to work properly.

But the error isn't still solved completely.
We still have a LINK problem with a lot of devices. One of the list of devices, with wich our boards can't establish a Link is a router HUAWEI quidway S2326TP-EL.

Could you please propose what else has to be checked?

Hello Vyacheslav,

Can you please check if after the PLL is locked the Flash Memory content is the same as the original image? For this when the code the stuck connect the debugger without resetting the core or reloading the image and open memory browser with address 0x0-0x110 and compare the same against the first loaded image in the same location.

Also is the issue after a system reset or does it happen on the very first load?

Regards
Amit

Amit, I've never done such operation before. Which tools (hardware and software) could you recommend for doing this?

Maybe I got something wrong - but your distinction between "good" and "bad" external devices suggests that the problem lies not entirely inside the TIVA device.

Have you tried Wireshark, and investigated why establishing the link to the "bad" devices fail ?

Hi, f.m.!
It's not completely clear yet. All external devices work fine with each other. But TIVA doesn't work properly with several of them.

Now we are shure, that HUAWEI-router works fine with other devices, but TIVA can't connect to HUAWEI.
At the same time, TIVA can establish the link to other devices, and other devices can connect to HUAWEI.
What's the reason of such behaviour - we don't know and try to understand.

We haven't any experience with Wireshark before. Can it be used as a sniffer between two devices?

Sure it can. It's quite powerful, and I must admit I had used it just superficially up to now.
It traces all packets in the network (my advice - reduce the number of devices/traffic to a minimum), and allows you to filter packets according to protocol, address, packet data, etc.
Finding/setting up the proper filter might take some time, but you can always save and reload a whole trace, and inspect it later.
I have used it a few times to investigate vaguely similiar issues - for instance with a device that kept certain TCP connection open when not closed in the expected way, and flooding the system's file/socket handles the process.
Your problem might be a timing issue, or some implementation-dependant issue with your network protocol.

Hello f.m.

And a managed switch for Wireshark to snoop the ports

Regards
Amit

Vyacheslav Prokopiy said:

Our device can establish link (EN0LED0 turns ON) with some external devices (NoteBooks, Network Adapters of standalone PC's, routers etc.), let's call them "Good devices". And there are also several other devices (also PC's, laptops, etc.), the link with them can not to be established, and EN0LED0 never turns ON with them. We call this devices "Bad devices".

The default display state of EN0LED0 is "Link OK". The data sheet doesn't seem to explicitly define what drives "Link OK", but I guess "Link OK" reflects the state of the LINKSTAT (Link not established or Valid link established) bit in the Ethernet PHY Basic Mode Status - MR1 (EPHYBMSR) register.

If "Link OK" is off I think this means the Ethernet phy hasn't established a link, and so Wireshark won't show any traffic.

To start investigating the cause of the "Link OK" problem on the "Bad devices" suggest:

1) Compare the contents of the Ethernet PHY Basic Mode Status - MR1 (EPHYBMSR) register between good and bad devices. As well as the LINKSTAT bit, the state of the RFAULT (Remote Fault) bit would be interesting.

Note that the Ethernet phy registers aren't directly visible in the debugger, I found that needed to call EMACPHYRead() to obtain the Ethernet phy registers (there are some examples in )

2) With the "Bad devices" does changing between using a straight through and cross-over Ethernet cable make a difference to "Link OK"?

This is to see if the problem is related to Auto MDI/MDIX.

3) The EMACPHYConfigSet TivaWare function allows the TM4C Ethernet phy to advertise different capabilities for auto-negotiation of link speed and duplex, or to force the link speed and duplex. By trying the different combinations, do any combination(s) allow the TM4C to establish the link with the bad devices?