DP83825I: Ping failed

Note 7
LED0 Behavior
Lights up when connected
Blinks after a while
(Remains blinking regardless of ping)

LED2 Behavior
Always off

Note 8
When connecting the PC and PCB directly
Link fails.
LED0&LED2 Behavior
After booting and releasing reset, LED0 and LED2 light up, but turn off after about 700ms.The waveform is shown below

Blue;IOVDD

Green:LED0

Purple:/PHY_RESET

Hi, 

I see that MDIO and INT pins are not pulled up. Is there a particular reason for this?

It is weird that the pcb to PC link fails. This makes me suspect that auto-negotiation is disabled. In this case, auto-mdix is disabled so the pcb and the laptop may not be able to make connection if it does not resolve straight/crossover cable. 

Could you check if auto-negotiation is disabled in the case of the PC and pcb link?

Is the switch managed or unmanaged?
Also, are the ip addresses set static or dynamically, or by the switch?

Best,
J

The hub and PC are unmanaged.
The IP address is static. I set it myself.

Regarding auto-negotiation, even when the PC and PCB are directly connected, BMCR[12] is set to 1 immediately after startup, so I think it's enabled. My question is, auto-negotiation has strap settings and register settings. When EN=1 and DEN=0, are these related to an AND circuit? Or an OR circuit?

Also, does BMCR[12] reflect the bootstrap value?

The manual stated that pull-ups on the MDIO and INT pins should be installed if necessary, so I did not install them initially. I install them in the following order and confirm their behavior.

MDIO pull-up
↓
INT pull-up

First, enable Auto-neg for bootstrap.

I changed the strap circuit to enable Auto-Neg and tried again. For details, please refer to sheet 2026_2_3.

The current situation is as follows:
10base ... I can link, but I can't ping
100base ... I can't link

Hi, 

Thanks for the detailed information. 

kz_sk said:

My question is, auto-negotiation has strap settings and register settings. When EN=1 and DEN=0, are these related to an AND circuit? Or an OR circuit?

It is an OR circuit. So, strap can initially disable auto-negotiation but it can be turned back on via register 0h. 

In case A, I see that register 4h is set to advertise only 10M half duplex. I am unsure if Windows 11 default advertises 10M half duplex. But, could you try writing 0x01E1 on register 4h? This will advertise all 10/100M speeds. I wonder if the PC to PCB will link up with this. 

I suspect in case E the link is not coming up because auto-mdix is also disabled with auto-negotiation. 
Could you see if the link comes up if you enable bit 15 of register 19h. If that does not work, try toggling bit 14 of register 19h. Bit 14 forces MDI/MDIX resolution. 



Otherwise, it is good to see that other cases are linking up. 

I looked at the register configuration and I see that register 16h bit 12 is high. This bit is for packet generation from the PHY side so this may be interfering with the ping.


I also see that register 17h bit 7 is low. This bit sets RMII follower mode so I am unsure if the PHY is operating on RMII follower mode. Could you also enable this bit high?



I have other ideas but let's see if these changes will get through the ping. 

Please let me know. 

Best,
J

Hi
Thank you for your reply.

17h bit 7 ==> Retested: All 1s.
16h bit 12==> Retested: All 0s.
19h bit 15==> Retested: All 0s.
4h ==> Retested: No writes, ALL "01E1"s.

Some changes have occurred under the same conditions, but this may be due to incorrect register entries on my part.
To prevent this from happening again, I'm using a for loop to retrieve all commands at once.
Line 114 lists the register values ​​for each test (obtained after linking, before pinging). Cells of concern are highlighted in red. Problem-free areas are highlighted in green. Register values ​​in white cells have not yet been checked.
Please confirm.

======ps=======

By the way, I haven't implemented the pull-up resistors on the mdio and INT pins yet, as you pointed out previously. Communication with mdio is working fine, and the INT waveform shows that it was high from the start, so there were no problems. Would it be better to implement the resistors?

Hi

I pressed the solve button by mistake.
It's still not resolved.
Should I start a new thread?

In case C and D

I think it's the script here, but the first line only has a read command and does not write anything. The second line only writes to 0Dh and 0Eh to allow register access, and does not write to any other registers. I have confirmed that the BMCR register with AN-enable does not change after the script is processed.

As shown in column U of the Excel file, AN is enabled and disabled only by writing to the BMCR register. No PHY settings have been changed other than the BMCR register in any case.

The ping command on line 118 of column D of Excel only overwrites the uboot environment variable and uses the ping command, not MDIO communication.

  excel:D-114

  excel : U-71

”it is very weird that 825 cannot establish …"

What does "825" refer to?

"Robust Auto-MDIX"... Understood. I'll give it a try.

Hi,

825 refers to DP83825.

And I apologize for the confusing wording. i meant to say ping program is acting weird, not the script you are using to read the register for case C and D. I am not understanding why ping would say auto-negotiation has failed when there is a link. I am wondering what data ping reads to know that auto-negotiation has completed. Based on the log, it does not seem like it is tracking the link status.

I am monitoring the thread so there is no need to make a new one.

best,

J

Understood.
Indeed, it seems that the ping side is not reflecting the PHY settings.

Hi, 

I connected DP83825EVM to my windows 11 PC and there is a 100M full duplex link with Windows 11 default setting. So, it looks like case G is getting a link on my end. However, if I understand your setup correctly, CON3 is with multiple PCs, not just one, right?

Another factor why the ping is not working is the magnetics. I tried looking for the magnetics specification but I could not find. Do you happen to have electrical specifications of the magjack on the board? It would be good to check if the magjack is within our datasheet recommendation. 

Best,
J

Hi

The following is the specs

datasheet : 936358314_sd.pdf

test condition:934620001-N.pdf

Hi, 

Thank you for the information. 
I see that insertion loss for the magnetics you use is out of our recommendation by 0.3dB at 80-100MHz. 
In addition, CMR and NEXT are also not within our recommendation.
Please refer to our recommendation below:


Best,
J

Hi J

I install a Linux kernel on PCB1.

Please tell me the DP83825I driver that is compatible with the following version.

Kernel version: linux-4.4.32

Also, although the transformer specs are slightly off from the required specifications, they comply with IEEE 802.3 and IEC 60603-7-1, so I don't think that's the direct reason why ping fails with 10base.

One thing that concerns me is that
the overflow and underflow bits are set on RX at 17h.
Could this be because the operation was performed on uboot, and the MAC is not performing the FIFO read process?

Hi, 

The magnetics can be an issue as we have previously seen customers' boards fully working after they change the transformers to the ones that fit within our recommended specifications. 

kz_sk said:

Kernel version: linux-4.4.32

We just checked internally and this kernel version is not supported so this can be an issue. 

kz_sk said:

One thing that concerns me is that
the overflow and underflow bits are set on RX at 17h.
Could this be because the operation was performed on uboot, and the MAC is not performing the FIFO read process?

In this case, this can be issue of RMII_CLK's ppm being too high. If you cannot replace the crystal with lower ppm to see if that fixes the overflow/underflow issue, could you try increasing the size of the elasticity buffer? Increasing the size of the elasticity buffer can increase the ppm tolerance. You can write 0h to register 17h bits [1:0]. 


Best,
J

Hi J

Thank you for reply

"You can write 0h to register 17h bits [1:0]."
I set 17h[1:0] to 0, but an overflow bit occurred immediately afterwards.
The clock waveform is currently being postponed because it's difficult to see correctly. It is oscillating for now.

Ping communication using 10base will be postponed for now.

I will investigate the issue of link failure when using AutoNegotiation (AN) and fixed 100base.
I measured the link pulse in 10base half, 100base full, and AN. Please check the Excel file I sent via private message.

The following concerns me:
- The pulse width fluctuates.
- The link pulse attenuates after the transformer, but I'm not sure if this is within the general specifications for 10base/100base.

If you know any general specifications for link pulse rise time, pulse width, etc., could you please let me know?

kz_sk

=====continue=======

The following concerns me:

- When set to 100base, a signal resembling a communication waveform is output even though there is no link.

- The link pulse in the document below has a peak of 1.6V, but the P2 link pulse of the "DP83825I" sheet when AN=ON has a peak of about 1.3V.
The rise time does not seem to change. If this peak voltage is the reason why linking is not possible, is there a way to increase the link pulse voltage by operating a register?

www.ti.com/.../snla266b.pdf

Notes
・The "LAN8740" sheet displays the link pulses of a board that communicates without issue over 10base/100base/AN.
・The measurement point "P1" is connected via a 50mm jumper wire and measured with a differential probe. The waveform at "P2" was measured with and without the jumper wire, but no significant changes were observed.

・I changed the VoD from 100% to 150%, but the link pulse amplitude did not change. What appears to be a communication waveform at 100base has become larger in amplitude.

・I added the connection between FG (connector shield) and DGND to the "connect" sheet.

Hi, 

kz_sk said:

"You can write 0h to register 17h bits [1:0]."
I set 17h[1:0] to 0, but an overflow bit occurred immediately afterwards.
The clock waveform is currently being postponed because it's difficult to see correctly. It is oscillating for now.

I still suggest to see if ping works even though the overflow bit goes high. Another customer reported the same issue, but they claim their error is gone, so the overflow bit may be going high for some other reason. I am investigating why this could happen. 

I reviewed the waveforms. I tried similar setup in the lab with our EVM and I see 1.7V FLP without changing pulse width. I think the pulse width changes because of your measurement setup. This is measured from P2 equivalent of your measurement setup. Below is our screenshot of the waveform: 

We used our Ethernet compliance setup (Keysight UXR0334A with compliance breakout board + E2678A differential probe head + N

Below is the image of our setup:



In addition, because your board is linking up in some cases, I doubt this is the FLP issue. If the FLP were to be the issue or out of IEEE specification, none of your setups that have autonegotiation enabled will not link up. I

Is it still only case E that does not link up, or is case A also not linking up? For case E, could you enable bit 5 of register 9h? This has been known to assist 100M link ups when there 100M is forced as auto-mdix may be disabled as this is part of the auto-negotiation process. Otherwise, I suggest to focus on the ping issue since case E is the only case that you are not seeing the link. For case A, please write 0x01E1 to register 4h for the correct auto-negotiation advertisement. 





Also, if auto-negotiation is turned off, the PHYs are meant to send out fixed communication signal by default. 
In addition, I noticed that you are 0x1F = 0x0400 for SW reset. This is not correct. Please write 0x1F = 0x4000. 


Best,
J

"I still suggest seeing if ping works even..."
I'll try it with the kernel as soon as the driver is ready.

"I reviewed the waveforms. I tried a similar setup in the lab..."
Please tell me your oscilloscope settings. Mine are as follows:
Edge trigger, rising edge, full bandwidth, DC coupling, no holdoff.
Also, my SS-320 is for high voltage and is larger than the J probe.

"In addition, it still only shows case E that does not link up, or case A also."
It does not link in case E, case A, or case G. This is listed in the "link" column below in the Excel spreadsheet I provided you earlier.
I'll try robust AMDIX today.

I'll try writing case A, but the default is 0x01E1, as shown below.

Hi, 

Thank you for the information. It looks like I may have accidentally overwrote the data on the previous excel sheet. 

My scope setup was also edge-triggered full bandwidth with DC coupling and no holdoff. 

On my data, case A register 4h value was not 0x01E1. 

In addition, I have been looking into IEEE specification for FLP and is as follows:


Because in both of our measurements the signal is above 585mV, I do not expect this to be an issue as it follows IEEE specifications. 

Please keep me updated on the robust auto-mdix and I will continue to investigate how we can assist on case A and G. 

Best,
J

Hi,

I apologize if I missed it, but what is the cable length for CON1 and CON3?
Also, would it be possible for you to measure the FLP signal at the end of the straight/cross cable? 
I checked that our RX squelch level is 200mV, so I am wondering if the FLP signal from the LP side is not triggering the squelch or our FLP signal is not being detected by the LP's receiver. 

Could you try implementing the script below?


I noticed that the link OK cases also links up in 10M only and 100M is not linking up. If robust auto-mdix is not working for case E, I wonder if the signal integrity on the cable is not good enough to make 100M connection. This script may tune the internal DSP to make our device more sensitive for connection. 

Best,
J

The cable lengths listed in the "connection" section of the previous Excel spreadsheet "2026_2_3" are as follows:
Cross cable... 1m
Straight cable... There are two types: 1.5m and 2m.

Hi J

thank you for reply

Please check the Excel file I sent via private message.
The results of today's work are listed from line 146 onwards in sheet "DP83825I".
- Cable Length Config Test... Link failed at 100m (default), 130m, and 150m. The link pulse waveform changed slightly.
- Robust AMDIX Test... Tested with the PC connected to an AN and without an AN, but link failed on either occasion.
- PHY receiving side waveform... The waveform of the FLP pulse from the PC was captured on the RX pair on the PHY side of the PCB. Sufficient amplitude was observed, so communication appears to be problem-free.
- PHY transmit waveform... The link pulse (FLP) output on the PHY transmit side was retested on a larger scale. The link pulse interval, which should be fixed at 125us, was fluctuating. This fluctuation in pulse interval is the reason why it fails to link. I think this is also the reason why you can't ping at 10base.
I think the reason is because the clock waveform input to the PHY is constantly fluctuating. What do you think about the cause of this occurrence?

Hi, 

If this is the case, I highly suggest to check your input XI clock as that looks like to be the culprit. 
Do you have another PCB or another DP83825? I also suggest to do a PHY swap and ideally ABA swap to see if the issue follows the PHY or the board. 
I reviewed your data again and it seems like 10M links up, but only 100M is not linking up in both auto-negotiation or fixed. In 10M case, ping is not working. I think this is most likely because the pulse widths are constantly fluctuating due to unstable XI clock. This would explain all your issues you are facing since the data will not be clocked correctly if the clock width is fluctuating. 

I suggest to check the XI clock to the PHY. 
I also suggest to see if you have additional PCB or DP83825, consider swapping them. 
I also suggest swapping the oscillator out. 

Best,
J

Hi J
I added a file to your private message.
I increased the damping resistance of the 50MHz oscillator, and the link pulse width fluctuations disappeared. I also successfully linked to 10base.
However, I still can't link to AN.
I think this is probably because, when I look at the link pulse, there are times when the 17-bit pulse spaced 125us apart isn't enough.
I don't know why the pulse keeps cutting out.

The video below shows the FLP link pulse from a board with the oscillator damping resistor changed to 160Ω.
The bit interval of 125us remains unchanged,
but you can see that at around 9 and 23 seconds into the video, FLPs with fewer than 17 bits are being output.

39.gigafile.nu/0223-b428dc0f221c8f83ded4be88026b2255b

Also, I don't understand what the "input phase noise at..." in the "input clock tolerance" section of the datasheet indicates. Can this be verified with an oscilloscope?

Hi, 

US office is closed today so I will respond with a detailed response tomorrow. However, I suggest to ensure the ppm of the XI clock is within 50 ppm. You do not need to look into the input phase noise unless you would like to. 

In addition, the link you shared seems to be broken. 

If you could acquire another PHY or another board, I highly suggest to do a swap to see if the issue is coming from a faulty PHY or the board. 

Lastly, can you ping when you link up in 10base? If AN does not work, can you link up when 100M link is forced with robust auto-mdix ON?

Please let me know and I will answer with more detail once the US office is open tomorrow. 

Best,

J

Hi,

Thank you for the information. It seems like damping resistance on the oscillator can be causing this.
Have you tried having no damping resistance for the oscillator? We typically do not recommend a damping resistance on the oscillator so that may be what is causing the PHY to not work.

However, based on your information, it seems like this is not a faulty PHY or board issue so I do not think a swap is needed. 

Were you able to get a link up on 100M when you disable 100M with robust auto-mdix? 

Best,
J