DP83822HF: RBIAS

Hi Hitesh,

Sorry for the confusion. Rbias should be around 1V instead of 2.7V. We will make sure to fix that in the new revision of the troubleshooting guide.

May I ask are you seeing any functional issue?

• It seems like DP83822PHY is not detect as correct stage. You can fix it through register 0x041F.

--

Regards,

Hillman Lin

HI Hilman Lin,

Thanks for the update on RBIAS.

Yes, We are seeing functional Issue.

Unable to ping

- Tried fixing through 0x041F - (phytool write eth0/2/0x041f 0x1c00) by writing 0X1C00 Value

-But when we read it again (phytool read eth0/2/0x0421) , I am getting same Value 0x7849 

- Issue Persists.

Hi Hitesh,

When you read 0x0421 after configure 0x041F, did you read the expected 3.3V on AVDD and VDDIO?

If possible, could you provide the register log from 0x0000 to 0x001F?

--

Regards,

Hillman Lin

Hi Hilman Lin,

No, I can't read expexcted 3.3V on AVDD and VDDIO, I can read AVD Detected as 1.8V & VDDIO detected as 2.5V , But on Probing them i have 3.3V on both.

Please Find the table below for the Register Log from 0x0000 to 0x001F

Above Table Contains Register Log

1) Column C - On bootup

2) Column D - On Boot up after resetting the phy chip

After Resetting the chip, We can see Link Light on Swtich

Note: We are Using this as Fiber Ethernet.

Hi Hitesh,

Here are some further steps for debug:

• After you configure 0x041F, could you re-read it and make sure it read 1C00?
• After that, could you try to write 0x001F to 4000 and see if that help with you application?
• Since you are using fiber module, could you read register 0xc01 to check for link up?

--

Regards,

Hillman Lin

Hi Hillman Lin,

Please find the answers below for the steps mentioned.

• After you configure 0x041F, could you re-read it and make sure it read 1C00?
  • Yes, When I re-read, its showing 0x1C00
• Written 0x4000 at eth0/2/0x001F - No Changes,  Same Result
  • No Changes,  Same Result
  • When I re-read 0x001F - Value is 0x0000 
• I read the register 0xC01/0X0C01 - Value for that is 0x7849 

Hello,

Hillman is OoO and will be responding tomorrow.

Sincerely,

Gerome

HI Hitesh,

If you are using fiber application. Could you make sure writing register 0x000A bit[14] to 1 to enable fiber mode.

--

Regards,

Hillman Lin

Hi Hillman Lin,

If you can see the Register log above, the Value for register 0x000A is 0x4100 - it means bit [14] is already 1.

Hi Hitesh,

May I ask what kind of fiber module are you using? if possible could you make sure the fiber module support 100Mbps instead of 1000Mbps. 

If possible could you change the fiber module and see if that help?

--

Regards,

Hillman Lin

Hi Hillman Lin,

We are using AFBR-5803ATQZ multi-mode Fiber Module.

Fiber module support 100MBPS ony.

I tried changing the fiber module but same results.

LED_1 / GPIO1 - Pin 24 - Should be in Signal Detect Mode Right? But currently its in default mode.

 phytool read eth0/2/0x0465 - gives 0x0000 

Tried Writing 0x0465 with 0x0001 value and re-read but it's the same 0x0000.

Can you please help with this? 

Hi Hitesh,

Regarding to the extended registers access, please use the following methods to read 0x465:

• https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1133146/faq-dp83tg720s-q1-how-to-read-or-write-registers-in-extended-register-space-of-ethernet-phy?tisearch=e2e-sitesearch&keymatch=extended%2520register#

If possible, could you also send the schematic between the fiber and DP83822PHY? We want to make sure there is a valid DC blocking caps and pull up on the MDI lines.

--

Thank you,

Hillman LIn

Hi Hillman Lin,

Please find the requested schematic -  509_DP83822.pdf

Hi HillMan,

Please Find the Update Value of 0x0000-0x001F

Hi Hitesh,

It seems like the PHY is linking up correctly right now based on register 0x0001. May I ask what is the issue resolve now?

Based on the schematic, I also see some kind of logic gate between the MDI lines and Fiber module. This might degrade the signal quality. May I ask what is the purpose of these logic gate?

--

Regards,

Hillman Lin

Hi Hilman Lin,

We are currently getting eth0 up and LED Blinking. Currently, We are unable to ping to the host. Communication is the problem.

We have removed the gates now.

Current issue is the communication part.

Hi Hitesh-san,

Thank you for the summary. It seems like the Fiber side is working fine now. 

If possible, could customer try the MII loopback and see if SoC is able to generate the receive packets?

• MII loopback: register 0x0000 bit[14] = 1

--

Regards,

Hillman Lin

Hi Hilman Lin,

I tried MII Loopback.

1) phytool write eth0/2/0x7100 -- Enabled MII Loopback Mode

2) tcpdump -A -vv &
3) arping -c 1 10.0.0.200

Attached is the Snapshot of the output. MII LOOP BACK Snapshot

Hi Hitesh,

Based on the snapshot you send me, It seems like you are not sending any packets. 

Could you double check on the MAC side to make sure they are sending any packets.

Probing the signal on the Data lines (MAC interface) could also give us an indication on any activity on the MAC side.

--

Regards,

Hillman Lin

Hi Hilman Lin.

Attaching the Snapshot - MII LOOP BACK Test  - You can see arping packet under Yellow box. So Packet is being sent. But Not recieved

Will try with probing the Data Lines (MAC Interface).

Hi Hilman Lin,

Currently, We can see the arp packets on the Wireshark Wireshark Snapshot , But unable to receive any reply

Arping Snapshot - ARPING-Snapshot

Hi Hitesh,

Thank you for sharing the information. It seems like the issue is on MAC interface.

If possible could you probe both TX and RX data and clock and see if any activity on those lines?

--

Regards,

Hillman Lin

Hi Hilman Lin,

We scoped/probed RX & TX lines, and When did ping, we saw activity on RX & TX Line.

I can see MII Loopback is failing.

Is there any step by step procedure to debug this?

HI Hitesh,

Thank you for the information.

Correct me if my understanding is wrong. Right now you are always able to see link up on the Fiber side.(register 0xC01 always = 784D) and you are always able to see Ping?

However, MII loopback is failing. This give us some indication the issue lies on the MAC side.

• When you said MII loopback fail, are you able to see any packets on the TX data when MII loopback is enable
• Could you explain more what did you mean by MII loopback fail? Are you not able to write the register or are you not able to see the packets back on the SoC? 
• 
• Based on this image it seems like MII loopback works fine on my side. Could you explain more on "MII loopback fail"?

--
Thank you,

Hillman Lin

Hi Hilman Lin,

On Bootup - The value of 0xC01 is 7849.

Then I reset the Phychip, the Value of 0xC01 is 784D. Then I am able to see Packets on Wireshark - for ping and arping.

When I say MII Loopback is Failng - I follow the following steps.

1) Set MII Loop back mode - phytool write eth0/2/0x0000 - 0x7100

2) Start TCP DUMP - tcpdump -A -vv &

3) ARPING to the host - arping -c 1 10.0.0.200

So, Ideally for MII Loopback, We should be getting 2 packets for the above arping on tcpdump but we are getting only one.

Attaching the snapshotMII LOOPBACK FAIL SNAPSHOT

On the following question

Are you able to see any packets on the TX data when MII loopback is enable? - I will be looking into the same now.

Hi Hitesh-san,

Understood. You are able to Ping successfully after resetting PHY. Could this be the solution?

If possible, could you write register 0x001F to 4000 or 8000 every time after bootup. Will this solve the issue?

--

Regards,

Hillman Lin

Hi Hilman Lin,

No, even after reseting, I am unable to ping. On Wireshark on Host (PC) i can see packets from my sam9x60 board. but ping doesn't have reply.

I am not getting reply on my soc. Can see packets transmitting but unable to receive any reply.

Hi Hitesh-san,

Sorry for the misunderstanding. After resetting the PHY, you are able to see link through 0xc01 and you see Ping on the Wireshark.

• May I ask which position did you read from the Wireshark? Is it on MAC side or MDI side?
• Probing the Signal Detect could also give us an indication?

This could give us further confirm that signal lies on the MAC interface. Did you have any data after MII loopback enable?

--
Regards,

Hillman Lin

Hi Hitesh-san,

I will reply to you tomorrow.

--

Regards,

Hillman Lin

Hi Hilman Lin,

I pinged from our Sam9x60 board (DP83822) to host (laptop) And packets can be seen on Wireshark (laptop).

But the ping failed - No Reply was seen on our board.

• Probing the Signal Detect could also give us an indication - Getting 4.0 V on Signal Detect.

MII Loop back fails.

HI Hitesh-san,

If you are seeing a sudden pull up on 4V on Signal Detect, that means the signal on the fiber module or optical fiber loss the signal on the receiver side.

If after enable MII loopback enable, could you probe both RX and TX data and see if you are able to see any signal?

--

Regards,

Hillman Lin

Hi Hillman Lin,

For MII Loopback enabled, We probed the RX & TX data, And we can see the activity.

Attached is the summary of MII Loopback Enable - Signal Probing.

Hi Hitesh-san,

The issues more likely on the SoC side from the MAC interface. Based on the scope capture, it seems like the MII loopback function properly. SoC cannot understand the signal send back from the PHY.

If possible, could you also check it on the SoC side?

Other items I will like to check is RX_D0 vs RX_CLK plot.

--

Regards,

Hillman Lin

Hi Hilman Lin,

The above Signal Results of MII Loopback were from SoC Side.

If possible, could you also check it on the SoC side? - What do you mean by this? What can be done here?

RX_D0 vs RX_CLK plot - Here is the snapshot of the same

Hi Hitesh-san,

May I ask which waveform are clock signal and data signal? I see one of the waveform are almost silence, is that the clock signal or data signal.

The reason why I am asking on the MAC or SoC side because the main functionality for the MII loopback are send back all the information send from the MAC or SoC.

Based on the previous RX data you probe on the scope, it seems MII loopback work for DP83822 since we are able to see the signal send and receive on the MAC interface. Right now, I think SoC or MAC cannot understand the packets send by itself. There might be two possibility:

• RX_Clk and RX_Data signal quality issue
• SoC cannot understand the information send back or ping

--

Regards,

Hillman Lin

Hi Hilman Lin,

Yellow Waveform is for Clock Signal & Blue Waveform is for RX_DO.

For us - Now MII Loopback is passing (50% of the time) - Rx_EN was routed to E0_CRSDV - It is now routed to RX_DV

Here is the snapshot of MII Loopback passing: MII LOOP BACK PASS

Also RX Packets can be seen on ifconfig command: RX Packets Seen

Still Ping is Failing.

1) Will be looking at more loopback tests

2) Signal coming from/to Fiber Module Attachment.

Hi Hitesh-san.

I will wait for the response on the loopback side.

Signal on the Fiber module should not be the problem.

--

Regards,

Hillman Lin

Hi Hilman Lin,

For us, MII Loop back is passing - As updated in above last message.

For We are Failing on PCS Input & PCS OutPut Loopback Test. And Passing on Analog Loopback, Digital Loopback Tests. Following are the snapshots.

PCS Input Loopback - Fail - PCSINPUT_FAIL

PCS Output Loopback - Fail - PCSOUTPUT_Fail

Analog Loopback - Pass - Analog Loopback Pass

Digital Loopback - Pass - Digital Loopback Pass

=====================================

Also RX_CLK & RX_DO Waveform plotting is same - RX_DO & RX_CLK Waveform - Can you see the reason why is that? What could be done to fix this?

Hi Hitesh,

It seems like the PCS loopback is not configure properly. Both Analog and Digital loopback also pass through the PCS block when it configure the loopback.

Sorry for asking multiple times. I would like to confirm on the observation:

• The PHY is able to link up
• MII loopback, Analog Loopback, and Digital Loopback pass.
• System still not able to perform a PING

--

Regards,

Hillman Lin

Hi Hilman Lin,

For PCS Loopback, I followed the following

PCS Input Loopback is enabled by setting bit[0] in the BISCR.

PCS Output Loopback is enabled by setting bit[1] in the BISCR

Answers to your queries.

• The PHY is able to link up - Yes
• MII loopback, Analog Loopback, and Digital Loopback pass. - Yes
• System still not able to perform a PING - Yes, Ping is not happening

Hi Hitesh,

Understood, thank you for the confirmation. Based on the status above, it seems like the issue does not lies on the PHY side.

• You are able to see the Link up where the connection between Fiber and DP83822PHY works fine 
• You are able to perform PCS loopback this shows MAC and PHY side communication looks good.

Our hypothesis are still lies on the fiber module. Here are some register we can detect some status on the fiber module in DP83822:

• Read register 0x0040
• probe the signal detect line on the fiber module.

If you are able to access fiber module, please do take a look on the fiber module on side as well. Make sure fiber module support the correct speed or mode.

--

Regards,

Hillman Lin

Hi Hilman Lin,

• You are able to see the Link up where the connection between Fiber and DP83822PHY works fine  - Yes, the Link is UP
• You are able to perform PCS loopback this shows MAC and PHY side communication looks good
  • For us PCS is failing, but MII LOOPBACK, DIGITAL LOOPBACK & ANALOG LOOPBACK - Is Passed

Please find the answers to your query.

• Read register 0x0040 - Value at 0x0040 is 0x3100
• Probe the signal detect line on the fiber module -  (Probed Pin 24 (DP83822)LED_1 / GPIO1, Value is  - 3.3 V

Hi Hitesh-san,

Signal detect pin never pull low when the Ping is not working? It seems like the issue does not lies on the PHY side.

The last thing I would check is enable a reverse loopback on the DP83822 PHY and see if the link partner is able to ping:

• Reverse loopback could be enable by register 0x0016 bit[4:0]

--

Regards,

Hillman Lin

Hi Hilman Lin,

We are able to get it working now.

Updated Resitance OHM at RX +/- toward fiber module.

Only thing is when bootup is completed, We need to reset the phy to get it working. Its like this since we started this thread.

Process is following.

1. System booting - Switch Link Light is ON.
2. While booting - Driver is loaded [Dmesg:macb f802c000.ethernet eth0: PHY [f802c000.ethernet-ffffffff:02] driver [TI DP83822] (irq=POLL)] - at this point Switch Link Light is OFF.
3. Once boot up completed.
4. We reset the Phy - Switch Link Light is ON.

How can we tackle this to come up at boot up.

Hi Hitesh,

Thank you for the observation.

• Are you writing any register during the bootup?
• Does reset PHY solution not work for customer? If customer writing register 0x001F to 4000 or register 0x001F to 8000. Does that help with with the application?

I don't think it is the power up issue because the PHY should not even link up if the PHY enter the unknown stage during power up.

--

Regards,

Hillman Lin