DP83822I: After Link-Up, first packet is not being transmitted

Hi Stefan,

To help with your problem, please answer the following questions or provide the following information:

1. What MAC interface is being used?
2. Can you share the register dumps for both PHYs?

In addition, can you try sending data and setting the PHYs in loopback mode?

Regards,

Adrian Kam

Hello Adrian,

to your quenstions:

1. The interface to the MAC is a standard MII interface (not RMII or RGMII).

2. I attatched a text file containing the register values for R0-..31 of both PHYs (0 and 1).

I tried to set the PHY into loopback mode (R0.14 = 1 and R22.4..0 = 1). But with this configuration, no link is being established and our application does not transmit any packets.

Can you specify the register settings to enable  the correct loopback mode?

Do you only want to verify, if the first packet successfully proceeds to the PHY?

Best regards

Stefan

PHY 0
------------------------------------------------------------
R0   = 0x3000
R1   = 0x7849
R2   = 0x2000
R3   = 0xA240
R4   = 0x01E1
R5   = 0x0000
R6   = 0x0004
R7   = 0x2001
R8   = 0x0000
R9   = 0x0000
R10  = 0x0100
R11  = 0x1000
R12  = 0x0000
R13  = 0x0000
R14  = 0x0000
R15  = 0x0000
R16  = 0x0882
R17  = 0x010A
R18  = 0x6620
R19  = 0x2800
R20  = 0x0000
R21  = 0x0000
R22  = 0x0100
R23  = 0x0049
R24  = 0x0400
R25  = 0x8000
R26  = 0x0000
R27  = 0x007D
R28  = 0x05EE
R29  = 0x0000
R30  = 0x0102
R31  = 0x0000
------------------------------------------------------------



PHY 1
------------------------------------------------------------
R0   = 0x3000
R1   = 0x786D
R2   = 0x2000
R3   = 0xA240
R4   = 0x01E1
R5   = 0xCDE1
R6   = 0x000D
R7   = 0x2001
R8   = 0x4006
R9   = 0x0000
R10  = 0x0100
R11  = 0x1000
R12  = 0x0000
R13  = 0x0000
R14  = 0x0000
R15  = 0x0000
R16  = 0x4695
R17  = 0x010A
R18  = 0x6420
R19  = 0x2800
R20  = 0x0000
R21  = 0x0000
R22  = 0x0100
R23  = 0x0049
R24  = 0x0400
R25  = 0x8C01
R26  = 0x0000
R27  = 0x007D
R28  = 0x05EE
R29  = 0x0000
R30  = 0x0102
R31  = 0x0000
------------------------------------------------------------

Hi Stefan,

Looking at the register dump file, I did not see any problems with PHY 1, but it seems like there is no established link on PHY 0. Can you provide a schematic of your application so I can look at this problem further?

As for trying loopback, you can enable analog loopback by setting bit[3] in register 0x0016. I suggest trying loopback mainly to verify that the first packet does reach the PHY. Section 8.4.8 of the datasheet provides a more detailed description of the loopback modes and how to enable them.

Regards,

Adrian Kam

Hello Adrian,

the missing link on PHY 0 is correct and intended. I forgot to say that I have tested with only 1 port connected directly to my Intel(R) Ethernet I210-T1 GbE interface card of my PC. The issue can be reproduced on both ports and the register dump has been made, when testing with PHY 1.

Sorry for missing this information.

I will try to realize the loopback test and inform you about the outcome.

Best regards

Stefan

Hello Adrian,

I tried to test the behavior using analog loopback of the PHY. Unfortunately, this seems to be more complicated than expected:

• The ICSS_EMAC, which is responsible for transmitting packets from the application, depends on a link interrupt event gegnerated by the PRU firmware.
• In loopback mode, this link event is not generated.
• I tried to simulate a link by setting bit 6 in register 0x16 (Transmit in MII Loopback). With this setting, the link hets up with an unstable behavior: The MDIO link status is continously switching between up and down status ...

Currently I am not sure, how to establish a loopback application that produces reliable information to verify, if the first packet reaches the PHY. So if I start to change the ICSS_EMAC implementation to simulate a link, the result may not be meaningful.

I will ask Dhaval Khandla, if he has any idea.

Best regards

Stefan

Hi Stefan,

Let me know if you are able to get loopback mode working. In the meantime, can you provide a schematic I can take a look at and see if there are any problems on the hardware side? Or are you using the DP83822I EVM?

Regards,

Adrian Kam

Hello Adrian,

we are using our custom hardware and I am proving, if I can publish our schematics (or parts of it) here in the E2E forum.

Testing with activated MII loopback fails, becasue the PHY does not signal an active link. So the connected PRU and ICSS_EMAC do not get the reuired interrupt events and status information to initialize correctly. In the end, no packts will be transmitted that can be looped-back.

So I adjusted the test by connecting RxD and TxD lines on the Ethernet connector side to establish an external loop-back. I did not change the driver initialization and transmit part. On the receive side I logged all received frames to the internal RAM.

It seems that all transmit packets have been looped back and are then received by the ICSS_EMAC. This test covers the complete receive and transmit path, that seems to be working correctly.

I am still wondering, why I am observing these initial packet losses. As mentioned before, it does not seem to make a difference, if speed and duplex are fixed or automatically negotiated.

Best regards

Stefan

Hi Stefan,

I would like to confirm one thing. For your setup, are the ARP packets coming from the DP83822 side? If that is the case, can you confirm that the DP83822 is sending ARP packets to the cable? You can use the Wireshark tool if you have no other means of doing so.

Regards,

Adrian Kam

Hello Adrian,

I attatched a picture that shows both setups I used. In the picture, I connected Port 0 but Port 1 can be used instead.

In both setups, the AM4376 is connected to two PHys of type DP83822 unsing MII-0 and MII-1. After power-on, the AM4376 initializes the physical network interface containing PHY configuration and driver initialization (ICSS_EMAC, etc.). When the DP83822 detects a link-up an interrupt event is being issued in the AM4376 and the application starts the network configuration by assigning an IP address (here static IP) to the logical network interface. After assignment of an IP address, multiple ARP telegrams (at least 6) are sent to inform the network and to detect IP address conflicts. The fist 4 identical ARPs are sent soon after receiving the link-up interrupt (< 300 ms).

Setup A (original, without loopback)

• Port 0 of our device is directly connected to the  test PC's NIC of type "Intel(R) Ethernet I210-T1 GbE".
• The incoming traffic is captured on the NIC using Wireshark.
• When performing a power cycle of our device 1-3 of the initial ARP frames are not detected.
• Using a Tap between the NIC and port 0, the Wireshark capture seems not to be reliable, becasue the Tap needs some initialization after link detection.

Setup B (with loopback on port 0)

• A loop-back adapter is plugged at port 0 connecting rx and tx signals.
• The received traffic is captured to a ring-buffer in the DDR-RAM.
• After power-on, the receive capture buffer contains all expected ARP frames.

So using Setup B, I could not detect any packet loss. But in this setup I do not expect issues, becasue I assume that this is a mandatory test for PHY devices. Further, this setup omits any interaction with different link partners. When using Setup A, I can see differences when chnaging the link-partner. E.g. when using a NIC of type "Intel(R) PRO/1000 PT" I did not observe packet losses.

It is thinkable that NICs or commonly other network interfaces have additional setup times resulting a delay between stable link-up and being able to process/forward received telegram. If this is the case and we can exclude other issues, there are two options: We can add a software delay in the link-up to application event chain (not very attractive). Or we can trust in network initialization protocols that deal with repetitions to cover this behavior.

Best regards

Stefan

Hi Stefan,

I have two questions:

1. Is there any difference between the link-partners in how the packets are received?
2. Do the link-partners have any timing differences between link-up and data transfer?

Regards,

Adrian Kam

Hello Adrian,

both link partners are standard PC network cards using the standard INTEL drivers supplied with Windows 10. There are no additional hardware or software changes. For testing, I start Wireshark and selected the appropriate interface. I do not have any information about the packet receive process or timing differences for these cards.

Didn't you observe similar behavior when testing with different link partners (PC-NICs, managed/unmanaged/old switches, hubs, devices, etc.)?

Best regards

Stefan

Hi Stefan,

We did not observe similar behavior when testing with different link partners. Can you try one more thing? Instead of using an external loopback adapter, try connecting port 0 to port 1 with a standard ethernet cable and seeing if you are able to transmit and receive all ARP packets.

If the above scenario results in no packet loss, then from the DP83822I side of things, there does not seem to be a problem with the PHY. You can try a loopback setup with the link partners and see if initial packets are being lost on the receive side.

Regards,

Adrian Kam