RTOS/AM4378: Ethernet phy link reset at startup with HSR/PRP firmware in PRP mode

Hi,

Could be this statistic somehow related to issue?

We found out that if the device is on office network it reset PHY more often.

If a device is connected directly on PC it doesn't reset PHY. From Wireshark, we found just a few TCP retransmission.
The upper picture shows the statistic where the device is connected directly on PC.

Kind regards, Mare

Hi,

is HSR/PRP firmware release 01.00.02 out of TI support / is too old for support?

Kind Regards, Mare

Hi Mare, it is not too old. My apology for the delay. Our expert is currently out of office in a business trip. I will try to get some answers from our developers and come back to you.

thank you,
Paula

Mare

>>Does the PRU firmware for HSR/PRP have the ability to signal the phy over MDIO to reset the link?

No. The PRU firmware doesn't signal the PHY over MDIO to reset the link.

Do you have any other ICSS ethernet application on the custom board? E.g. did you port icss emac loopback example from PDK and verify it works without issue?

Regards,

Garrett

Hi Garrett,

Yes we ported the icss emac and as I recall there were no issues but we will re-test it now to make sure.

I will also check the PHYs status registers for some clues.

Not sure if related to the issue but we did not connect the COL and CRS signals as the HSR/PRP firmware works only in full-duplex mode. As I understand both signals are ignored by the MAC when in full-duplex mode.

Marko,

Are you able to narrow down the issue with icss emac loopback test?
Both COL and CRS signals are not used for HSR/PRP.
You may start from checking the reset pulse of PHY to ensure it meets the requirement outlined in DP83822 datasheet 7.7 Timing Requirements, Reset Timing(1).

Regards,
Garrett

Hi Garett,

We are currently looking into the PHYs status registers. We read the registers when we get the Link down interrupt. We see that the False Carrier Sense Latch is always set after the link down event. It seems we have a issue on the MDI side of the PHY. The strange thing is that as said this happens only in the first minute or so, after that the Ethernet seems to run fine.

We checked the PHYs analog power supply and it looks OK. No voltage fluctuations when the link is lost.

Good suggestion. I will check the reset timing of the PHY.

We want to collect some additional statistic from the PHY. Does the HSR/PRP firmware read the status register, specifically FCSCR? So that we know that zero count means actually zero and is not because the register was read by the HSR/PRP firmware.

Reset timing is OK.

Mare,

I was out of office and missed some e2e notification, is the issue still pending?

There was a fix on emac driver related to MDIO/PHY, e2e.ti.com/.../2596681

Can you try to apply that fix to see if the problem behaves differently?

Regards,
Garrett

Hi Garrett,

Yes the issue is still present.

We are currently fixing some non related issues with higher priority.

We will try the fix and let you know.

Thank you.

Hi Gerrett,

this fix example code is related to emac_drv, but in the case of PRP/HSR icss_emac_drv is used.

Are fixes relevant for icss emac?

Thank you

Mare,

Not really. Apparently I mixed the thread with another one which tried to have both ICSS_EMAC and CPSW EMAC ports working.

Are you able to confirm the standalone nimu_icss emac test passes? I.e. without HSR/PRP in the picture.

Regards,
Garrett

Hi Garrett, 

We have some other issues on the project. I will try standalone nimu_icss emac probably on end of next week.

Thank you!

Best Regards, 

Mare