TM4C129ENCPDT: Ethernet port cannot transmit packet

Hi Tianlei,
How many boards have you subject to the ESD tests and how many are experiencing the behavior? Can you probe the EN0TXON and EN0TXOP signals from the MCU? I kind of want to know if anything in between the MCU and the RJ45 jack can play a role in the problem you are seeing. Can you also try to reset only the PHY instead of the entire MCU and see if it makes a difference?

Hi Charles,

This is the first board for ESD test. Here is the new findings.

I created a function InitializeEthernet()  ( see following) that basically resets the whole port. This function works and can actually recover the Ethernet function from the error condition. At this moment I am looking for the indications from Ethernet port so that I can use it to trigger this function. I am not sure at this moment if the error is in DMA, MAC or PHY.

Is calling SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0) enough to reset the PHY?

Thanks,

Tianlei

void
InitializeEthernet()
{
    //
    // Enable and reset the Ethernet modules.
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_EMAC0);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_EPHY0);
    SysCtlPeripheralReset(SYSCTL_PERIPH_EMAC0);
    SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0);
    //
    // Wait for the MAC to be ready.
    //
    while(!SysCtlPeripheralReady(SYSCTL_PERIPH_EMAC0)) {
        WdogTemporyFeed();
    }
    //
    // Configure for use with the internal PHY.
    //
    EMACPHYConfigSet(EMAC0_BASE, (EMAC_PHY_TYPE_INTERNAL | EMAC_PHY_INT_MDIX_EN | EMAC_PHY_AN_100B_T_FULL_DUPLEX));
    //
    // Reset the MAC to latch the PHY configuration.
    //
    EMACReset(EMAC0_BASE);
    //
    // Initialize the MAC and set the DMA mode.
    //
    EMACInit(EMAC0_BASE, SysClock, EMAC_BCONFIG_MIXED_BURST | EMAC_BCONFIG_PRIORITY_FIXED, 4, 4, 0);
    //
    // Set MAC configuration options.
    //
    EMACConfigSet(EMAC0_BASE, ( EMAC_CONFIG_FULL_DUPLEX | EMAC_CONFIG_CHECKSUM_OFFLOAD |     EMAC_CONFIG_7BYTE_PREAMBLE |
                                EMAC_CONFIG_IF_GAP_96BITS |    EMAC_CONFIG_USE_MACADDR0 | EMAC_CONFIG_SA_FROM_DESCRIPTOR |
                                EMAC_CONFIG_BO_LIMIT_1024),
                              ( EMAC_MODE_RX_STORE_FORWARD | EMAC_MODE_TX_STORE_FORWARD | EMAC_MODE_TX_THRESHOLD_64_BYTES |
                                EMAC_MODE_RX_THRESHOLD_64_BYTES), 0);
    //
    // Initialize the Ethernet DMA descriptors.
    //
    InitDescriptors(EMAC0_BASE);
    //
    // Program the hardware with its MAC address (for filtering).
    //
    EMACAddrSet(EMAC0_BASE, 0, MacAddr);

    //
    // Enable the Ethernet RX Packet interrupt source.
    //
    EMACIntEnable(EMAC0_BASE, EMAC_INT_RECEIVE | EMAC_INT_PHY);

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
    GPIOPinTypeEthernetLED(GPIO_PORTF_BASE, GPIO_PIN_0 | GPIO_PIN_1);
    GPIOPinConfigure(GPIO_PF0_EN0LED0);
    GPIOPinConfigure(GPIO_PF1_EN0LED2);

    EMACPHYExtendedWrite(EMAC0_BASE,0,EPHY_LEDCR,EPHY_LEDCR_BLINKRATE_20HZ);
    EMACPHYExtendedWrite(EMAC0_BASE,0,EPHY_LEDCFG,EPHY_LEDCFG_LED0_LINK | EPHY_LEDCFG_LED2_RXTX);

    // The driver lib is not correct. This bit actually controls the polarity of LED indicator
    //
    HWREG(EMAC0_BASE + EMAC_O_CC) |= EMAC_CC_ECEXT;
}

Hi Tianlei,
The SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0) will reset the PHY.

Hi Charles,

I reduced the function to only have this statement (SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0)) and it also works (can recover the Ethernet port under the error condition) . This means that it's the PHY's problem and reset it will cure it.

I also tried to look at the signal between EN0TXON and EN0TXOP. But it seems that the prob is affecting the Ethernet function. With the prob connected, the port will not come up(link not established).

Anyway, is there any way I can check the PHY's status and discover the error condition from the code?

Thanks,
Tianlei

Hi Tianlei,
Can you read the EPHYBMSR (MR2) register to find out the PHY status? Are any bits set?

Hi Charles,

I put in code to dump the value of EPHYBMSR(MR1) to my serial terminal. There is no bit set during error except for EPHY_BMSR_LINKSTAT, which correctly reflects the Link status.

I also monitored the value of EPHYSTS(MR16) and caught something:
1. in normal working state the value is 0x0715
2. in error state the value is 0x0f15
3. the transition of the value: 0x0715 --> 0x0d15 --> 0x0f15

According to the datasheet:
1. FCSL bit is set, which means False Carrier event has occurred
2. DL bit is reset, which means Descrambler Lock. This bit is set once the register is read.

Is DL bit related to the error state? I am not clear about the technical detail around this bit.

Thanks,
Tianlei

Hi Tianlei,
I'm not an expert in the PHY design. When FCSL bit is set it means the false carrier sense counter has changed since last read. In general, this counter increments when the controller sees unexpected behavior of the MAC/PHY interface signals. I think the PHY incremented the counter when it detected problem sensing the signal (the carrier wave is modulated to form the 0's and 1's). When the signal between nodes is disrupted a carrier error occurs. If the PHY does not receive a normal link pulse it will generate a carrier error.
I tend to think the DL bit is not related to the error. I did some reading, the PHY has both the scrambler and the descrambler. The 100Base-TX transmission requires scrambling to reduce the radiated emissions on the twisted pair cable. So when the DL bit is reset it probably means the PHY is in the state to descramble the received data.

Tianlei Zhang said:

I reduced the function to only have this statement (SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0))

Seem to recall reading anytime the PHY is reset it has to be reconfigured.

Getting back to ESD test locking up the PHY, we can only imagine how your custom PCB is designed to handle such events. Is not the general idea to block ESD event before it enters the PHY and what level ESD is being applied 2Kv or 20Kv?

BP101 said:

Seem to recall reading anytime the PHY is reset it has to be reconfigured.

And that assumes there was no damage done to other network layers in the IP stack. This idea you can reset the PHY and go forward like U don't have a flat tire, eventually the smell of burning rubber will over take the driver.

Hi all,

Thanks for all the responses.

Since I continuously read1 from FCSL, it means the False Carrier event is occurring all the time during the error state (otherwise once I read the register, the bit should be cleared).  This probably means that the carrier detection logic in PMD has gone wrong (given the fact that if I reset the switch, the firmware can see the link is established, but the problem remains). 

At this moment, I am using FCSL as the indication of the error to reset the PHY. This method works. I know this is not the ultimate solution but it helps with our problem at the moment.

Tianlei