DP83867IR: ARP request is not coming in the PC

Aravindh A

Part Number: DP83867IR

Tool/software:

Hi,

I am DP86837IR in our project and I am using Lattice Certus Pro-NX FPGA for the development. We developed our custom which supports RGMII 1G. I validated till analog loopback testing in the PHY IC I can able see to proper data in RGMII RX which I sent in RGMII TX. After autoneg enable I connected to PC and I testing our use case. But in wire shark I can't able see any ARP request from my board (which is the initial request board will to PC for connection).

Below are the registers I configured PHY IC for 1G and testing with PC:

1. write 0x1140 data to 0x0000 address (BMCR)

2. write 0x1300 data to 0x0009 address (1000BaseT)

I am writing data into the addresses 0x0032 & 0x0086 using extended registers,

3. write 0x001F data to 0x000D address (REGCR)

4. write 0x0032 data to 0x000E address(ADDAR)

5. write 0x401F data to 0x000D address

6. write 0x00D3 data to 0x000E address which means I am write data 0x00D3 data to 0x0032 address indirect(RGMII ctrl reg).

7. write 0x001F data to 0x000D address

8. write 0x0086 data to 0x000E address

9. write 0x401F data to 0x000D address

10. write 0x0046 data to 0x000E address which means I am write data 0x0046 data to 0x0070 address( RGMII delay ctrl reg).

9 months ago

0 Vivaan Jaiswal 9 months ago

TI__Expert 6425 points

Hi,

Thank you for all the register writes you have provided. First, I wanted to clarify a few things about your setup to make sure we are on the same page.

You mentioned auto-negotiation is on. I wanted to make sure that auto negotiation has completed and a link has been established at 1G speed. This can be verified by reading register 0x01.
What kind of function are you trying to perform for which an ARP request is being sent? Are you trying to ping the PC from the custom board?
Are you writing these same registers for the Analog Loopback testing as well?
Given that the link is infact established, we could try setting up a reverse loopback on the PHY and send packets from the PC to verify the integrity of the MDI path. This can be set using register 0x16[5]
Is there any reason why you are choosing to manually set Master/Slave mode? Have you tried the setup without manual slave configuration?

Best,

Vivaan

0 Aravindh A 9 months ago in reply to Vivaan Jaiswal

Prodigy 20 points

Hi Vivaan,

Thanks for your response

I observed the following while working on my application:

I read register 0x01, and the value is 0x796D.
In my application, after the board powers on, it raises an ARP request to the PC. However, I cannot see the ARP request from the board in Wireshark at PC.
Using a JTAG debugger on the RGMII TX, I verified that the ARP request is being sent properly
Analog Loopback:
I disable auto-negotiation by writing 0x0140 to register 0x0000 and configure the loopback by writing 0x0008 to register 0x0016.
Reverse Loopback:
Could you confirm the required register configurations? I am considering the following:
- Write 0x0140 to register 0x0000.
- Write 0x0009 to register 0x1300.
- Write 0x0016 to register 0x0020. Please let me know if these configurations are correct or if any changes are needed.

I have selected the PHY IC as a slave, as the PC in my application is set to always act as the master.
I also tried a board-to-board setup, but the issue remains unresolved.
Interestingly, I can successfully receive and process junk data sent from the PC to my board. However, I face issues when sending data from the board to the PC.

0 Aravindh A 9 months ago in reply to Aravindh A

Prodigy 20 points

Hi Vivaan,

I tested Reverse loopback testing, I can able see proper data whatever I'm sending its coming out.

0 Vivaan Jaiswal 9 months ago in reply to Aravindh A

TI__Expert 6425 points

Hi Arvindh,

Thank you for the detailed information.

According to your testing, we have validated both the MDI and MII paths through Reverse Loopback and Analog Loopback tests respectively. Based on this, I am confident that the MDI and MII paths themselves are working as expected.

Aravindh A said:
Interestingly, I can successfully receive and process junk data sent from the PC to my board. However, I face issues when sending data from the board to the PC.

Through the reverse loopback tests, we were able to verify that data from the board to the PC was also being read. I believe this might have to do with the structure of the ARP packet.

I think we can test further by probing the MDI line during the ARP request. I also wanted to ensure that the request is being sent after auto-negotiation is complete and a link has been established. ARP packets are also usually smaller than ethernet packets. It could be that wireshark is not able to read these packets because of this.

Perhaps we could test for ping as well? We can configure the IP of the PHY and try to ping that from the PC.

Best,

Vivaan

0 Aravindh A 9 months ago in reply to Vivaan Jaiswal

Prodigy 20 points

Hi Vivaan,

I have configured the PHY IC for reverse loopback by writing 0x0020 to the 0x0016 register. With this configuration, I can observe data, such as ARP ping requests from the PC, successfully looping back and appearing in Wireshark. Based on this, I believe the issue lies in the interface between the MAC and PHY.

I have reviewed the RGMII timing budget and the troubleshooting guide from TI, and I have the following observations and questions:

Alignment and Center Modes:
- If my MAC is configured in align mode, the PHY IC should be in shift mode.
- To configure the PHY IC for shift mode, I wrote 0x00D3 to register 0x0032 and 0x0017 (0.25ns in TXC and 2ns in RXC) to register 0x0086.
- Could you confirm if this configuration is correct for alignment mode on the MAC?
- FPGA side TX is centered with RGMII TX clock(shift mode) & RX is align.
MAC Address Issue:
- While debugging the Lattice FPGA, I observed a discrepancy in the MAC address during transmission and reception:
  - Sent MAC Address: 0x0C22384E5A
  - Received MAC Address: 0x0C222A6E4E
- I tried adjusting the TX delay using the RGMII DCTL register with delays ranging from 0x0 to 0xF, but the issue persists.

Could you please provide your insights or suggest further steps to resolve this?

0 Vivaan Jaiswal 9 months ago in reply to Aravindh A

TI__Expert 6425 points

Hi Aravindh,

Since the device was able to receive and transmit packets in analog loopback, which you verified by checking the data being sent against the data being received, it seems like the RGMII lines should be behaving as expected.

Here is an FAQ detailing the shift/align modes for RGMII.

If the MAC is in align mode, the PHY must be in shift mode so that it knows to shift the clock before sampling the data.

Aravindh A said:
0.25ns in TXC and 2ns in RXC

According to the registers being written, the TXC is being shifted by 0.5ns, not 0.25. Otherwise, looks correct.

You mention that the TX is configured as shift mode on the MAC side, but the PHY is also being programmed for shift mode. One of the two should be in align mode.

Where is the MAC address being received? Are you referring to the case with analog loopback? This behaviour with different transmitted and received bits could be a sampling error due to the RGMII timing specs.

Best,

Vivaan

+1 Aravindh A 8 months ago in reply to Vivaan Jaiswal

Prodigy 20 points

Hi Vivaan,

After adjusting, TXC and RXC delay in the PHY IC, I can able to see ARP request in my PC and I can able to do ethernet transactions. Thank you for support

0 Vivaan Jaiswal 8 months ago in reply to Aravindh A

TI__Expert 6425 points

Hi Aravindh,

Glad to know this behaviour was resolved. I will be closing the thread now but you can always post another one if in need of more support.

Best,

Vivaan

Interface

Interface forum

DP83867IR: ARP request is not coming in the PC