2397364_en-US

[#1]

ls1021a eTSEC tx timeout

I have a LS1021A IOT and a prototype board based on this cpu. On both we use our boot loader.

It works perfectly in the IOT board but on my board I get TX timeout on the Ethernet port. I get a few pings going and then tx timeout and more pings.  This makes tftp rarely possible.

There are hardware difference of course. Our MAC is connected to a BCM54616S then to a LAN9514. The autonegotiation is limited to 100FD. TX timeout also happens in loopback mode.

In order to transmit data, I had to set bit SGMII_AN bit in the TBI PHY on my boards while I did not have to on the IOT (IOT can negotiate at 1000FD).

Not sure why the TX is so intermittent. Could it be related to this speed limitation?

Re: ls1021a eTSEC tx timeout

Hello,

For 100FD SGMII , verify these items in your boot loader on the prototype board:

1. Set LS1021A eTSEC for SGMII 100 Mbps

   • ECNTRL[TBIM] = 1
   • ECNTRL[SGMIIM] = 1
   • ECNTRL[R100M] = 1
   • MACCFG2[I/F Mode] = 01 for 10/100 mode
     The LS1021A RM specifically notes setting R100M = 1 for SGMII 100 Mbps.

2. Reset and program the internal TBI PHY The RM states that SGMII uses the TBI register set and that it is important to reset the TBI for all interface modes, including SGMII.

3. Keep SGMII_AN set The TBI SGMII_AN bit is documented as “must be set to 1.” So the fact that your board only transmits after setting this bit is not surprising; it suggests your boot-loader initialization was incomplete for this PHY/MAC mode.

4. Do not rely on 1G-style SGMII AN behavior at 100 Mbps There are known LS1021A reports where 100 Mbps SGMII operation shows “SGMII link is not ok” or intermittent no-packet behavior after link cycling, while 1G operation is clean. That does not prove your exact TX timeout root cause, but it makes 100FD SGMII configuration a strong suspect.

The loopback result matters. If your “loopback mode” is external PHY loopback or SGMII-side loopback, the 100FD SGMII/TBI setup can still be involved. If it is internal MAC/eTSEC loopback , then the external BCM54616S/LAN9514 path is mostly out of the picture, and I would focus on eTSEC initialization, descriptor-ring handling, cache coherency, and TX halt/error status.

For debugging, check the eTSEC TX halt status when the timeout occurs. The RM says the transmit halt bits are set when eTSEC is no longer processing transmit frames from a TxBD ring; repeatable causes include bus errors, invalid BD/data addresses, uncorrectable BD/data read errors, and TxBD programming errors such as Ready = 1 with length 0 . Also check whether you are seeing IEVENT_BSY ; NXP material describes BSY as dropped RX frames due to lack of buffers/software not servicing the BD ring fast enough, which is a software/BD-ring symptom rather than a pure SGMII electrical symptom.

Recommended isolation sequence:

1. Force external PHY to 100FD, no autoneg toward copper if needed.
2. Force LS1021A MAC/eTSEC to SGMII 100 Mbps:
   TBIM=1, SGMIIM=1, R100M=1, MACCFG2 I/F mode=10/100.
3. Reset/reinitialize TBI after setting SGMII mode.
4. Set TBI SGMII_AN=1.
5. Confirm TBI link/AN status, eTSEC ECNTRL/MACCFG2, and PHY SGMII-side status.
6. On timeout, dump IEVENT, TX halt registers, DMA status, and TXBD ring contents.

regards 

Re: ls1021a eTSEC tx timeoutForgot to say my port is set for SGMII mode.