DP83822HF: No communication when speed is set to 10 Mbps, 100 Mbps is working properly

Hi Bart,

Thanks for the information. Could you kindly answer the following:

1. When setting the DP83822 to force 10Mbps speed, is this done through straps or register writes? If register writes, what setting is used?

2. Register 0x10 read shows MDI normal for 10 Mbps but pairs swapped for 100 Mbps, is this intentional?

3. Can you kindly provide a read for registers 0x467 and 0x468?

4. I want to confirm, it seems auto-negotiation is complete and valid link is established in both cases. When you say "connection goes silent/connection is lost" can you clarify what this means? Is link dropped? Are packets sent but dropped? 

Thank you,

Nikhil

Hi Nikhil,

Thanks for your responds!

Regarding the questions:

1. This is done trough register writes: 0x0004 set bit 6 to 1 (Advertise10 Base-Te Full-Duplex ability) - Clear bit 5,7 8 and 9 ->  0x000 set bit 9 to 1 (Restarts Auto-Negotiation)
2. No this is not done intentionally, this is detected / set after the auto-negotiation.However the polarity should not make any difference for the 100 Mbps, as far as I know. But it is certainly strange, any ideas what can cause this behavior?
3. Those are:   0x467: F6F- 0x468: 0x0
4. Thats right, the auto negotiation is working properly on both cases, Whenever it is forced by setting the register, or when the PC is forced to a 10Mbps connection.

What I meant by "connection goes silent/connection is lost" is that there is no data transferred whatsoever from the DP83822HF. At the connected PC I see no incomming data (checked with WireShark), no ACK or any other packet.

Whenever I repeat the steps at 1, but instead of bit 9 I set bit 7 or/and 8 (100Mbps), and restart the auto negotiation then the connection is working again (as expected).

I will attempt to check if any data is received on The Sitara side when set to 10Mbit.

Any suggestions / pointer?

Thanks,

Bart

Hi Bart,

Some further follow up questions:

1. What MAC interface is being used? 

2. As device is showing link, register access is available, I assume RX_CLK is active, but can we confirm?

3. Again to clarify, in 10 Mbps mode, when "connection goes silent," Sitara processor is still generating packets sent to the PHY across the MAC interface, but PC does not receive them? If this is a correct assessment, is data observable on the TX/RX pins?

4. Is this behavior also observed when setting 10Mbps speed through hardware straps? This may be a good exercise as a debug step.

Thank you,

Nikhil 

Hi Nikhil,

Thanks for the response.

1. We are using the EMAC provided by the Sitara (AM3356) processor
2. We are using RMII, therefore the RX_CLK and TX_CLK is not used. The REF_CLK is used, at pin 1 on the Phy (RX_D3/GPIO3). Here we see at both 100Mbit and 10Mbit a frequency of: 50MHz. Which is what we expect in RMII mode.
3. This is correct. On the Sitara side I can confirm the following at this moment: On both 100Mbit and 10Mbit I see that the auto negotiating is successful. When set  to100Mbit I receive data from the MAC (get an interrupt), when set to 10Mbit I don't get any data (no interrupt is triggered). Must investigate this further.
4. Unknown at the moment, must be tested, will report results later.

Kind regards,

Bart

Hi Bart,

Please try setting 10Mbps mode using hardware straps and see if similar behavior is observed. Additionally, can provide a schematic?

Thank you,

Nikhil

An update,

Can confirm that data is transmitted from the phy to the MAC in both 100Mbps and 10Mbps.

When a connection is negotiated I see data transmitted (presumably a LLDP Multicast packet). Output seen in the scope output below:

100Mbps

10Mbps

On 100Mbps valid data is detected, at 10Mbps dont get any valid data. When I take a look at the Ethernet Statistics (CPSW_STATS Register on the AM3356) Then I see that he RX_ALIGN_ERRORS and RX_JABBERS are incremented (which is not the case on 100Mbps).

Dump of the ethernet statistics (10Mbps):

R CPSW_STATS_GOODRX 0x0000000B 0x00000000
R CPSW_STATS_BROADCAST_RX_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_MULTICAST_RX_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_PAUSE_RX_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_RX_CRC_ERRORS 0x0000000B 0x00000000
R CPSW_STATS_RX_ALIGN_ERRORS 0x0000000B 0x00000110
R CPSW_STATS_OVERSIZE_RX_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_RX_JABBERS 0x0000000B 0x0000002F
R CPSW_STATS_UNDERSIZE_RX_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_RX_FRAGMENTS 0x0000000B 0x00000000
R CPSW_STATS_RX_OCTETS 0x0000000B 0x00000000
R CPSW_STATS_GOOD_TX_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_BROADCAST_TX_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_MULTICAST_TX_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_PAUSE_TX_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_DEFERRED_TX_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_COLLISIONS 0x0000000B 0x00000000
R CPSW_STATS_SINGLE_COLLISION_TX_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_MULTIPLE_COLLISION_TX_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_EXCESSIVE_COLLISIONS 0x0000000B 0x00000000
R CPSW_STATS_LATE_COLLISIONS 0x0000000B 0x00000000
R CPSW_STATS_TX_UNDERRUN 0x0000000B 0x00000000
R CPSW_STATS_CARRIER_SENSE_ERRORS 0x0000000B 0x00000000
R CPSW_STATS_TX_OCTETS 0x0000000B 0x00000000
R CPSW_STATS_RX_TX_64_OCTET_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_RX_TX_65_OCTET_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_RX_TX_128_OCTET_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_RX_TX_256_OCTET_FRAMES 0x0000000B 0x00000000
R CPSW_STATS_RX_TX_512_OCTET_FRAMES 0x0000000B 0x000000F1
R CPSW_STATS_RX_TX_1024_OCTET_FRAMES 0x0000000B 0x0000001F
R CPSW_STATS_NET_OCTETS 0x0000000B 0x00073DEB
R CPSW_STATS_RX_START_OF_FRAME_OVERRUNS 0x0000000B 0x00000000
R CPSW_STATS_RX_MIDDLE_OF_FRAME_OVERRUNS 0x0000000B 0x00000000
R CPSW_STATS_RX_DMA_OVERRUNS 0x0000000B 0x00000000

Can someone confirm the validity of the RMII data sent (as seen above)?

Thanks in advance.

Bart

Hi Bart,

Thanks for the update. I have the following questions:

1. Can you confirm whether 10 Mbps mode was set by straps or register writes in the data above? 

2. You mention PHY is sending packets to the MAC. Is PHY receiving packets across a cable from a link partner at this time (the network adapter you mentioned)?

3. Can you provide a schematic?

Hi Nikhil,

Thanks for you response (again :) )!

1. The 10Mbps mode was set by register write. By default we have the phy configured for 100Mbps, but 10Mbps must also be supported.  The configuration is as described below:

   1. Pin Name	Pin Number	Configuration
      COL	29	Default: PHY_AD0=1, FX_EN =0
      RX_D0	30	Default: AN_1=1, PHY_AD1=0
      RX_D1	31	Default: EEE_EN=0, PHY_AD2=0
      RX_D2	32	Default: FLD_EN=0, PHY_AD3=0
      RX_D3	1	Default: AN_EN=1, PHY_AD4=0
      LED_0	17	AN_0=1
      CRS	27	LED1=SPEED, LED0=LINK+ACT
      RX_ER	28	RGMII=0, AMDIX=1
      RX_DV	26	XI_50=1, RMII=1

   2. FX_EN,AN_0,AN_1,AN_EN = 10/100baseT half/full duplex
   3. RGMII, RMII, XI_50 = RMII, 50MHz clock

2. Yes, that is correct.
3. Unfortunately not at this moment, will see what I can and cannot share.

As mention earlier, the (E)Mac on the AM3356 respond upon data by increasing the jabber / align error count register on 10Mbp,  this raises the question if this is a issue in the phy or the MAC on the am3556. Is there a quick way to determine where the problem lies?

Kind regards,

Bart

Hi Bart,

Thanks for the detailed, easy to analyze, strap setting report. Using different loopback modes, we can determine if the issue is on the cable side or the MAC side.

1. Far End Loopback: If the link partner can be configured to generate packets and count errors, similar to our PHYs PRBS checker and BIST capability, the PHY can be set to Reverse Loopback mode. While our PHY is in Reverse Loopback mode, the link partner can be set to generate packets across the cable, and our PHY will loop the data back across the cable to the link partner before sending to the MAC. If the current link partner in your system does not have this capability, another DP83822 can be used. Please review sections 8.4.8 and 8.4.9 of the datasheet for more information.

2. Near End Loopback: If the processor can be configured to generate and count packets across the MAC interface, the PHY can be set into one of the near-end loopback modes, such as Digital or Analog Loopback. Again, please review section 8.4.8 for more information.

Please let me know if you have any further questions, and please keep me updated.

Thank you,

Nikhil

Hi Bart,

Glad to hear that we are making some progress. Should any additional guidance be needed from our end, please feel free to open a new thread linking this one.

Thank you,

Nikhil