DP83867IR: Follow up for abnormal soft reset issue of PHY

Attached the reset waveform for 10kohm + 0.1uF.

Thank you for sharing the scope capture Renfu.

Please help clarify below question:

Dave Chang said:

2.Could you also please share more details about the failure symptoms about reading PHY's register through MDIO, but the function of ethernet and LED is abnormal?

Thank you,

Evan

Hi Evan,

There are two fault symptoms:

Case 1. The PHY LED is on, and the PHY appears on the MDIO bus but cannot be brought up.
Case 2. The PHY LED is on, but the PHY is not responding on the MDIO bus.

We can see the U-Boot output for Case 2 of the fault symptom as follows:

Could not get PHY for ethernet@8000000port@1: addr 1
ERR.eth, am65_cpsw_nuss_port ethernet@8000000ethernet@8000000port@2: phy_connect() failed
INFO.dma, ti-udma dma-controller@485c0000: k3_dmaring Ring probed rings:288, sci-dev-id:30
INFO.dma, ti-udma dma-controller@485c0000: dma-ring-reset-quirk: disabled
ethernet@8000000port@1 Waiting for PHY auto negotiation to complete......... TIMEOUT !
ERR.eth, am65_cpsw_nuss_port ethernet@8000000port@1: phy_startup failed
ERR.eth, am65_cpsw_nuss_port ethernet@8000000port@1: am65_cpsw_start end error
 
ERROR:   Unhandled External Abort received on 0x80000000 from EL2
ERROR:   exception reason=1 syndrome=0x92000010
Unhandled Exception from EL2
x0             = 0x0000000008000f00
x1             = 0x0000000000000001
x2             = 0x00000000ffffffff
x3             = 0x0000000000000002
x4             = 0x00000000fff3199c
x5             = 0x0000000000000002
x6             = 0x00000000000044e0
x7             = 0x00000000fdec5190
x8             = 0x0000000000000000
x9             = 0x0000000000000008
x10            = 0x0000000000000002
x11            = 0x0000000000000001
x12            = 0x00000000000044e0
x13            = 0x00000000fdeaebac
x14            = 0x00000000fdeaf690
x15            = 0x0000000000000020
x16            = 0x00000000fff26360
x17            = 0x0000000000000000
x18            = 0x00000000fdebadb0
x19            = 0x00000000fdeaeb94
x20            = 0x00000000fdec51b0
x21            = 0x0000000000000001
x22            = 0x00000000ffffffff
x23            = 0x0000000000000001
x24            = 0x00000000fdec51b0
x25            = 0x0000000000000002
x26            = 0x0000000000000000
x27            = 0x00000000ffffffff
x28            = 0x000000001fffffff
x29            = 0x00000000fdeaeaf0
x30            = 0x00000000fff327a0
scr_el3        = 0x000000000000073d
sctlr_el3      = 0x0000000030cd183f
cptr_el3       = 0x0000000000000000
tcr_el3        = 0x0000000080803520
daif           = 0x00000000000002c0
mair_el3       = 0x00000000004404ff
spsr_el3       = 0x00000000400003c9
elr_el3        = 0x00000000fff319c0
ttbr0_el3      = 0x00000000701ce800
esr_el3        = 0x0000000092000010
far_el3        = 0x0000000008000f04
spsr_el1       = 0x0000000000000000
elr_el1        = 0x0000000000000000
spsr_abt       = 0x0000000000000000
spsr_und       = 0x0000000000000000
spsr_irq       = 0x0000000000000000
spsr_fiq       = 0x0000000000000000
sctlr_el1      = 0x0000000030d00801
actlr_el1      = 0x0000000000000000
cpacr_el1      = 0x0000000000000000
csselr_el1     = 0x0000000000000000
sp_el1         = 0x0000000000000000
esr_el1        = 0x0000000000000000
ttbr0_el1      = 0x0000000000000000
ttbr1_el1      = 0x0000000000000000
mair_el1       = 0x0000000000000000
amair_el1      = 0x0000000000000000
tcr_el1        = 0x0000000000800080
tpidr_el1      = 0x0000000000000000
tpidr_el0      = 0x0000000000000000
tpidrro_el0    = 0x0000000000000000
par_el1        = 0x0000000000000000
mpidr_el1      = 0x0000000080000000
afsr0_el1      = 0x0000000000000000
afsr1_el1      = 0x0000000000000000
contextidr_el1 = 0x0000000000000000
vbar_el1       = 0x0000000000000000
cntp_ctl_el0   = 0x0000000000000000
cntp_cval_el0  = 0x0000000000000000
cntv_ctl_el0   = 0x0000000000000000
cntv_cval_el0  = 0x0000000000000000
cntkctl_el1    = 0x0000000000000000
sp_el0         = 0x00000000701cb400
isr_el1        = 0x0000000000000000
dacr32_el2     = 0x0000000000000000
ifsr32_el2     = 0x0000000000000000
cpuectlr_el1   = 0x0000000000000040
cpumerrsr_el1  = 0x0000000001040346
l2merrsr_el1   = 0x0000000013283c20
cpuactlr_el1   = 0x00001000090ca000
?
U-Boot SPL 0000.00-g830df3c9 (Dec 31 2024 - 14:47:56 +0800)
resetting ...

Thanks,

Sean

Hi Sean,

Is this LED_0 or LED_1 observed as static on?

If this is link status LED, then I suspect the PHY is powered properly, and there is some software dependency that could cause this crash. Are you able to boot into Linux and observe the same issue?

I am tagging EP team to help isolate possible software dependency.

Thank you,

Evan

Following up here, have you also attempted register access after this uboot failure? It's possible MAC sees PHY in reset during boot, showing this failure. In this case, MDIO access is still expected to work after boot.

Thank you,

Evan

Hi Evan

BTW ...
has TI duplicated the problem by extending the rising time of the Reset pin?

Hi Renfu,

We have tested with rise time ~300us, with PHY link and register access still valid.

Feedback from design team is that reset rise time should not affect 867 functionality. Please help confirm questions in my previous replies.

Thank you,
Evan

Hi Evan,

I still believe that the rising time is the key point we need to focus on.

Based on the UC-2222A design, a rising time of 800us is still valid for certain PHY chips.

I tried to extend the rising time to more than 10ms, and that’s when the failure phenomenon occurs.

Could you please try again?

The UC-2222A software reset don't power off action for PHY.

It still keep power on status , and just trigger low pluse on PHY's HW reset pin ( pin.59 RESET_N)

Sometimes, we are unable to get information from the PHY through MDIO.

Therefore, I believe that using MDIO as a path to resolve the issue might not be feasible.

Hi Evan,

Only the problematic PHY does not appear on the MDIO bus; the other PHY functions fine. I think the MAC is fine in this case.

The following message is displayed in Linux:

am65-cpsw-nuss 8000000.ethernet: phy /bus@f4000/ethernet@8000000/mdio@f00/ethernet-phy@1 not found on slave 2

Thanks,

Sean

Hi Renfu, Sean,

Thank you for sharing the result. I will continue reproducing for longer rise time to find any limit.

BR,

Evan

Hi Evan

Have you duplicated this PHY issue by increasing the rise time of reset signal ?

Also, please help provide the latest status update.

Thanks.

Hi Renfu,

Latest test is 300us rise time without issue.
I will share result for same rise time as your system by Thursday at the latest.

Thank you,
Evan

Hi Evan,

Most of the PHYs in our products operate with slow rise times and function properly, with failure conditions being very rare. I believe the failure case is difficult to reproduce.

The only adjustment we made to fix this was speeding up the rise time, which I believe was the key factor. This may be one of the critical points.

We still have product in production and would like to know the rise time recommended by TI before identifying the root cause.

Thanks,

Sean

Hi Sean,

Minimal reset rise time is recommended.

This recommendation is not for chip-level concern, but instead for possible system-level issues where SoC state machine may be affected if PHY reset does not complete within specified time. Please confirm with SoC team any dependencies on reset timing for proper initialization.

Thank you,
Evan

Hi Sean, Renfu,

I have tested with below rise time ~40ms, over 100 power cycles on DP83867EVM, and did not observe any issue with register access or link:

From this I believe your issue is a MAC-side dependency. When the SoC initializes the MDIO bus, is there any dependency on reset timing?

Could you please try manually reading registers using phytool or mdio-tool in the failing case? I'm wondering if register access failure is specific to MAC functions, or any register access attempt will fail.

Thank you,
Evan

Hi Evan

Just to confirm, the status is triggered only by the HW reset_N signal, with no power-off action , right ?

That's correct.

EVM schematic is here:
https://www.ti.com/lit/ug/snlu190/snlu190.pdf

Test condition:

• Add 20k to VDDIO on "RESET_N"
• Add 2.2uF to GND on "RESET_N"
• Press & release "S1" to pulse RESET_N to ground.
• Read register and test link

Thank you,
Evan

One follow-up test, can you probe MDIO during attempts at register access?

This way we can isolate if the failure is due to MAC-side or PHY-side dependency:

- MDIO not present during register access means MAC is not driving this line due to failed MDIO bus init (PHY is healthy)

- MDIO active during register access, but PHY does not respond with correct value (PHY failed to start properly)

Thank you,
Evan  

Hi Evan,

We found that the problem may be caused when the PHY latches its address incorrectly.

The MDIO is working fine since PHY0 (PHY Address0) is functioning properly. The following is a failure case where PHY1 (PHY Address1) does not appear on the MDIO bus.

• PHY0 is working fine

• PHY1 latch address timing issue (Both PHY 0 and PHY 1 consider their address to be 0) 

• PHY1 does not appear on the MDIO bus.

Attached MDIO.cvs file contains messages on the MDIO bus

MDIO.csv

As we speed up the reset rise time, both PHYs operate normally. The following is the latch timing for your reference:

• PHY1 latch address timing

• PHY1 appears on the MDIO bus.

While speeding up the reset rise time would solve our problem, we are a little concerned whether the PHY address latch timing will meet the specifications as expected.

Thanks,

Sean

Hi Sean,

PHY address strap pins are the MAC RX lines. I suspect that for slower reset time, the pin state on the MAC-side changes and affects the voltage sampled on latch-in. Please confirm if MAC's RX[D0,D2,D4] pin state changes within this reset timing margin. Capturing waveforms of these lines during slow/fast reset cases can help confirm this as well.

Thank you,
Evan

Hi Evan

We cannot see the issue on the EVM. Could it be because it only has one PHY and the address is set to the default value (Adrress 0) ?

I tried to capture the waveform on MOXA/UC-2222A unit. Could you help me verify if the timing matches the specification?

We use address 0 & address 1 on desgin , so I only catch the RX_D0 on wavefrom.

R=10kohm and C=1uF on RESET_N

R=10kohm and no cap. on RESET_N

Hi Renfu,

Relative to my previous reply, I suspect 867EVM does not face this issue as there is no MAC connected to the RX_D[...] lines affecting the pin voltage on latch-in.

Renfu Chung said:

We use address 0 & address 1 on desgin , so I only catch the RX_D0 on wavefrom.

It's possible other address straps (RX_D2/RX_D4) are affected by MAC on start-up, but this is less likely without PU/PD on these pins. Could you please share the full schematic for my review (can email to e-mayhew@ti.com for private share).

From the waveforms shared, both PHYs look to be strapped into Address 0:

For PHY intended for Address 1, can the MAC-side be adjusted to keep RX_D0 = 0.165 x VDDIO (Mode 2) until RESET high + 120ns?

Thank you,
Evan

Hi Evan,

I have sent you the PHY schematic via email for your reference.

The below picture shows that the 0.1uF capacitor has been removed for measuring purposes.

Based on the function and protocol check, address 1 can be detected normally.

1. Do you think there might still be a latch-in timing issue after the reset signal is released?

2. The RX_D0 signal is controlled by the PHY after latch-in, is that correct?

Hi Renfu,

I apologize, I labeled the diagram in a misleading way.

Strap latch-in looks to occur when RESET_N(V) > VIL (0.7). This shows sample point of RX[D0] = '1' in the scopeshot with faster reset, for PHY address 0x1.

For the slower reset case, please share a zoomed in capture of this region:

I would like to confirm if RX_D0 is driven low before RESET_N(0.7V) + 120ns.

Renfu Chung said:

1. Do you think there might still be a latch-in timing issue after the reset signal is released?

2. The RX_D0 signal is controlled by the PHY after latch-in, is that correct?

1) In the slower rise time case, this is possible. I need to review failing case with faster time scale to see exact sample point.

2) That is correct, RX_D0 will be driven by PHY after strap latch-in. Before this point, however, it's possible for other devices on the line to affect the sample voltage.

Reviewing the schematic, what resistor values are populated on R350 and R145 for address = 0x1?

Thank you,
Evan

Hi Evan

When R = 10k ohms and C = 2.2uF
For a slower reset rise time, latch-in action cannot occur at the RESET_N (0.7V) + 120ns timing.
When the reset voltage is around 1V, oscillations occur in RX_D0 during the latching process.



When R = 10k ohms and C = 100pF
The RX_D0 can be latched in at the RESET_N (0.7V) + 140 ns timing , address detect and PHY link function is normal.


Reviewing the schematic, what resistor values are populated on R350 and R145 for address = 0x1?
=> R350 and R145 is not stuff , set address to 00000 ( PHY Port1 )
=> R138 pull high 10k ohm and D148 pull down 2.49k ohm , set address to 00001 ( PHY Port2 )

Hi Renfu,

Renfu Chung said:

=> R350 and R145 is not stuff , set address to 00000 ( PHY Port1 )
=> R138 pull high 10k ohm and D148 pull down 2.49k ohm , set address to 00001 ( PHY Port2 )

This is correct for intended straps, thanks for confirming.

Is the MAC connected to RXD0 line during power-up? If possible, please remove the RXD0 connection from PHY to MAC to confirm if MAC is causing these oscillations during reset. These oscillations are likely causing unintended strap value to latch-in.

Thank you,
Evan

I have cut off the RX_D0 path between the SOC (MAC) and the PHY. It was found that the PHY was causing these oscillations during reset.

Channel 2 is the SOC (MAC) RX_D0, which retains the original R138 pull-high 10kΩ resistor and the D148 pull-down 2.49kΩ resistor.
Channel 3 is the PHY RX_D0. Due to the cut-off of the original path, I added a pull-high 10kΩ resistor to 3.3V.

Hi Renfu,

Thank you for sharing the test result here.
I'm not clear on the PHY-side behavior causing this oscillation. Do you see RX_CLK or other RX_D[X] lines show activity at this same sample point?

I am checking with design team further to confirm cause. 

Thank you,
Evan 

Hi Renfu,

Internal pin structure is CMOS input buffer depending on RESET voltage, which causes oscillation due to slower rise time - longer duration in undefined logic region.

Figure 4 in this app-note shows a general example of this behavior:
https://www.ti.com/lit/an/scla015b/scla015b.pdf

Register configuration cannot avoid this behavior - these are the remaining workarounds:

• Adjust external passives for faster reset time
• If SoC has internal pull-up on RX_D0 pin, have SoC temporarily drive this pin to Mode 2 voltage during reset

Thank you,
Evan

Hi Evan,

Regarding the faster reset time...

Will TI define the slew rate for the reset?

What capacitor values are recommended for us to use?

Thanks,
Renfu

Hi Renfu,

We have tested with 0.01uF // 2.2kohm on RESET without issue.

Unfortunately this is an edge case we haven't observed in the past, as designs typically have reset rise time in <50 microsecond range.

I can test further to find the exact acceptable limit for rise time if needed - please let me know if this data is required before modifying the design.

Thank you,
Evan

Hi Evan,

Due to the same rise time, there may be different behaviors on different PHY chips.

We need TI to provide the recommended rise time to avoid this issue.

Thanks,
Renfu

Hi Renfu,

I am confirming recommended rise time, will share ASAP.

Thank you,
Evan

Hi Evan

Do you have any updates on the rise time spec?

Thanks.

Not yet, discussion with design is ongoing.

Apologies for the delay here.

Hi Evan
Is there an estimated timeline for the rise time spec?

Hoping to have the spec shared within 1-2 weeks.

Design team has asked some clarifying information:

• What is the period of the toggling seen on RXD0?
• Is the toggles coming in at 500-700ns intervals?

Thank you,
Evan

Hi Renfu,

Following up here with more feedback from design, the spec limit is not with rise time on reset signal, but noise on the reset line.

In cases with noise on reset line, slower reset will allow more opportunity for the PHY to toggle in and out of RESET when crossing VIL/VIH thresholds.

To confirm this, measuring the toggling period of RX_D0 as 500 - 700ns will confirm the strap latch-in is occurring multiple times as a result of RESET being triggered repeatedly due to noise on the line.

Thank you,
Evan

Hi Evan

You can find about 12.5 MHz toggle signal on RXD0

Based on the result of cutting off the RXD0 path between the SoC (MAC) and the PHY, the toggle waveform is still present.
Does this indicate that the noise is originating from the PHY?

Hi Renfu,

The noise can couple from any surrounding sources (EMI, nearby high-frequency signals in layout, ...)

Does the layout contain any high frequency signals near RX_D0? There is some noise that can couple from the internal PHY signals, but this is typically not significant enough to cause any issues without additional sources present.

Thank you,
Evan

Hi Evan

I’ve run a few experiments, but there are still toggle signals present on RX_D0.

- Removed the diode (originally connecting the CPU to the PHY) , while keeping the 10kΩ resistor and 1µF capacitor on the PHY reset path only .

- Manually generated a low pulse by briefly shorting the reset to GND.

- Changed the PHY’s power source to an external power supply.

The RX_D0 trace is routed between RX_D1 and RX_CLK.
I tried shorting the RX_CLK signal to GND, but the toggle signal still persists.

There are no high-frequency signals near the reset pin.

Hi Renfu,

Thank you for sharing the test data.

Relating back to the original issue, I noticed some differences in MDIO waveforms in pass/fail cases:

PHY1 no response:

PHY1 response:

The duty cycle and frequency appears to change between these cases. I understand we were focused on possible strapping issue due to this RX_D0 toggling, however I'd like to rule out any timing violation on SMI as well:

In the passing/failing cases, can you please help confirm these timing requirements are being met?

Thank you,
Evan

Hi Evan,
I checked the MDIO signals on the failed unit.
The timing appears to be the same regardless of whether the reset signal rises faster or slower.

CH2: MDC
CH3: MDIO

Output

Input

Hi Renfu,

Thanks for sharing the data, I agree this is compliant with SMI spec.

As the negligible noise on the line is enough to trigger the toggling behavior, I will confirm with design the reset rise time spec to avoid this behavior.

In the meantime, please confirm if below workaround is viable for your system:

For failing rise time case, perform sweep of PHY register read/write at each address (0x0 - 0x1F). Find the responding address that the PHY has unintentionally strapped into, and modify SW to instead use this address for the bus.

Thank you,
Evan

Hi Evan

This workaround is likely not feasible, as the UC-2222A has two PHYs, which could potentially cause an address conflict.

Please help provide the rise time specification to ensure this loss issue can be avoided. Thank you.

I understand. Waiting for design to confirm spec.