Ethernet Initialization Issues

Hello Ralph,

We are currently speculating that it is something regarding the timing but haven't found a way to prove it yet.

Our code already utilizes the SysCtlPeripheralReady() call which has us stumped.

Hello Jacob,

That the order of APIs matters so much really makes me wonder about the pre-fetch buffer errata I called out. It is possible that shifting the commands around would avoid an issue related to the prefetch buffer. Perhaps try the work around to disable and then enable it and see if that impacts the results.

Another thing to try would be the following code where the EPHY is not enabled until the EMAC is ready. I really haven't seen a past issue where that was needed but it'd be good to understand if that works and lets the Enable for EPHY occur next without issues.

SysCtlPeripheralEnable(SYSCTL_PERIPH_EMAC0);

//
// Wait for the MAC to be ready.
//
while(!SysCtlPeripheralReady(SYSCTL_PERIPH_EMAC0))
{
}

SysCtlPeripheralEnable(SYSCTL_PERIPH_EPHY0);
SysCtlPeripheralReset(SYSCTL_PERIPH_EMAC0);
SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0);

Hello Ralph,
 
We have done some more investigation and have found that when we are able to establish communication, EMACStatusGet returns zero and EMACIntStatus returns that EMAC_INT_TRANSMIT is set (presumabley from a successful transmittion).

When the communication issues are presenting themselves the EMAC_INT_TRANSMIT bit in EMACIntStatus is clear and EMACStatusGet returns that EMAC_STATUS_TX_NOT_EMPTY, EMAC_STATUS_TFC_STATE_WAITING, and EMAC_STATUS_TRC_STATE_READING are set forever and EthernetIntHandler stops being exectued. Hopefully, this is a bit more specific.

Note: in both instances the EPHY_STS register reports that auto-negotiation has completed with an active link at 100Mb/s Full Duplex (0x0715)

Hi,

Jacob Charlebois said:

We currently have a system comprised of multiple modules communicating over Ethernet in a half duplex setup. When reconfiguring the system to a full duplex auto negotiation mode, some modules continue to communicate normally while others loss communications.  We found that changing:

This,
//
// Enable and reset the Ethernet modules.
//
SysCtlPeripheralEnable(SYSCTL_PERIPH_EMAC0);
SysCtlPeripheralEnable(SYSCTL_PERIPH_EPHY0);
SysCtlPeripheralReset(SYSCTL_PERIPH_EMAC0);
SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0);

To this,
//
// Enable and reset the Ethernet modules.
//
SysCtlPeripheralEnable(SYSCTL_PERIPH_EMAC0);
SysCtlPeripheralReset(SYSCTL_PERIPH_EMAC0);
SysCtlPeripheralEnable(SYSCTL_PERIPH_EPHY0);
SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0);

Solves our communication issue.

I wonder if you do like below, will it make a difference? The idea is wait until the peripheral is ready after you enable it. 

SysCtlPeripheralEnable(SYSCTL_PERIPH_EMAC0);

while(!SysCtlPeripheralReady(SYSCTL_PERIPH_EMAC0))
{
}

SysCtlPeripheralEnable(SYSCTL_PERIPH_EPHY0);

while(!SysCtlPeripheralReady(SYSCTL_PERIPH_EPHY0))
{
}

SysCtlPeripheralReset(SYSCTL_PERIPH_EMAC0);
SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0);

Hi Charles,

Unfortunately throughout our testing that is an approach that we have attempted and it still failed to communicate. We are continuing to test this and will respond to our original post once we find something insightful.

Hi Jacob,

Jacob Charlebois said:

When reconfiguring the system to a full duplex auto negotiation mode, some modules continue to communicate normally while others loss communications

I'm going back to your original post and I want to understand your described problem. Below are some tips I hope you can provide that will give us some more insights to the problem. 

  - When you say some modules continue to communicate while others lost communications, can you elaborate if all the modules are running the same firmware and if they are all the same board?

  - How many modules are we talking that are still running and how many lost communication?

  - If you limit the number of modules running on the network will it make a difference? I don't know how many total you have. Suppose you have 10 running with some working and some not, can you reduce the total number to like 4 including the ones that was failing before. Will you see any difference? This is to check if there is any network level issue.

  - Can you change the Ethernet cable on the ones that lost communication? Does it make a difference?

  - Can you run the TivaWare Ethernet example on all the modules? Will you see those that lose communication running your own application continue to lose communication running the TivaWare example? This is to check if the problem is software related. 

  -  Can you run your application on the LaunchPad board? Will you see any communication problem?

  -  Let's suppose you have two modules: module_A and module_B. A is good and B will lose communication.  Can you do a ABA swap test meaning swap the MCU on module_B (the bad board) to module_A (the good board) and swap the MCU on module_A to module_B. Will the bad MCU continue to lose communication? This is to check if there is any board related issue with the module_B.