DP83TC813S-Q1: RGMII device not functional for every device

Hello,

Can customer please check registers 0x600, 0x608, 0x45D? Please note these are extended registers and thus customer will need to use extended register method to access. Please see section 8.4.19 for more information.

Sincerely,

Gerome

Hi Sebastien,

Thank you for the information. For now, lets see if the SoC can clean up the transients of its signals. I understand the original thread stated that customer had issues with MAC side of PHY? Yet, I see in .pdf that there is MDI link issue? Can you clarify what exactly seems to be the issue?

Sincerely,

Gerome

Hi Gerome,

sorry for confusion, it's always been a communication issue with the SoC. although at the time of the initial post we had no idea how deep was the source of the problem either on the 813 side or SoC side. I liked your idea of checking the internal status of the 813 : have the registers mentioned above any relevance to check soc com status ?

Gerome, also can you please remove the pdf from the post once you made your local copy for confidentiality purpose, I dont want it to stay on the forum. thanks.

Hello,

Our software team told us the configuration of the SMI bus (MDC and MDIO) is fully done by the TI firmware of AM62 SoC, and clearly the SMI bus is not well configured.

Can you please check what is done by the TI firmware (by default), and is there any parameters for us to configure.

(For example, how to configure the clock speed ? is there some polarity setting (like SPI bus) ? some delay setting we can adjust ? ...)

Regarding the register you suggest to read, we will try to do it today, but we are no confident it will work. anyway, we will try on both working and not working PCB.

Thanks.

Best Regards,

Sebastien.

Hello, 

We have tried to read the suggested register, and it success on a "working" board, and not on a "non working" board.

However, we have some trouble to interpret bootstrap reading from register 0x45D: 

RX_ER and RX_DV bootsrap are on 2 bits in the register, but only one is significant. which one ?

When reading this register we got 0x8A as a returned value

Thanks

Best Regards,

Sebastien

Hi O'Mellin,

I have made local copy. 

Hi Sebastien,

Have you made sure you are accessing this register correctly? As this is an extended register, you need to access these types of registers a special way. Please see section 8.4.20 of datasheet for more information. Any register from 0x20-0xFFF will need to be accessed this way.

Regarding firmware, you will need to ask the AM62 team on how this was implemented by default. All the PHY cares about is that SMI timing is accounted for.

For my methodology of register checking, it is as follows; I am trying to establish a baseline for customer. The original statement is that RGMII interface is not working. Therefore, I would check the RGMII registers to see what is going on. Is it enabled? Is it configured correctly (align/shift)? What do the bootstraps say about the original configuration?

Sincerely,

Gerome

Gerome,

I have 2 questions as this issue still pending ( I send you a additional doc in parallel ) working on interface between AM6 and eth phy.

- what will the reading of the 3 registers you suggest will provide in terms of information ?

- as per below it seems the timing of the am6 port vs the 813 isnt compatible from the hold time. is this spec of the eth phy new vs older vesrions ? i'm asking because it seems older TDA4 specs seems to be the same, and I'm pretty sure we're getting communication with older gen eth phy ?

Soc spec : ://www.ti.com/lit/sprsp58 

Hello Gerome,

Regarding register access, indeed I cannot confirm it was done the right way.

However, the point about the datasheet is still valid : We are looking at a 1 it information placed on 2 bits of the register and it is not clear at all which bit (of the register) we should consider

Second point, on the "non working" board, the PHY does not ansswer SoC request on SMI bus, so, no way to read any register.

Best Regards,

Sebastien

Hi all,

I wanted to recenter the discussion since it has been a bit since the last communication.

Issue: Customer is having issues with DP83TC813 RGMII. In these same boards, SMI communication is also not working, thereby making any register approach difficult to implement. Customer also states that link partner is seeing link regardless of "working" and "not working" scenarios.

Questions:

- Can you confirm above issue?

- What is the occurrence rate of failing vs not failing? Is this failure contained on the same boards, or can any board become susceptible to this behavior?

- Can you do peripheral check of device to see if it is up on RGMII side? Can customer try to probe RX_CLK for 25MHz signal? This can help determine if PHY is alive. Can customer also check INH, Wake, and power pins for expected states? 

- Is clkout observed on TP?

Responses:

It seems the photo provided shows input requirements for both AM6 and PHY. These are not related to each other. PHY's MDC timing spec is derived from IEEE802.3. 

Registers will provide the following information:

0x600 (RGMII Enable)

0x608 (If SGMII is on. This would potentially override RGMII if both bits are on)

0x45D (Strapping)

I would also like to introduce register 0x601 (RGMII status. Only for reads) and 0x602 (RGMII align vs shift on RX and TX path. Could be worth modifying to see how this affects results once register access is fixed). 

Sincerely,

Gerome

Hi sebastien gros, could you please come back to use on Gerome's questions? Thank you.

Hello Francois, Gerome

Issue is that we see a request through MDC/MDIO without answer. On the 32bit line message we only see 16bit for the request (read or write) without answer. So we can't read the requested register

We see that the between boards which are ok and the nok : 

The request adress is correct  ( is the same, 0XC) 

RX_CLK is identical (both at 25Mhz)

CLKOUT is similar but not identical ( 25MHz vs 24.938Mhz (on NOK part))

INH and Wake are both fine . 

We tried to replace a PHY with a new part; Test was not conclusive either. 

Regards,

George 

Hi George,

I need more information to be able to proceed forward.

What is the failure signature occurrence rate of this behavior? Out of X boards, Y show this behavior? Also, is this issue only showing up on these boards or is any board susceptible?

If on bad boards, PHY address changes, will MDC/MDIO work?

Sincerely,

Gerome

Hello Gerome, 

We have 125 nok out of 200 boards. These are the only boards produced on the project yet; 

What do you mean by changing the PHY address ? We tried with several other register (and so adresss) result is the same.

Hi George,

I believe this conversation will be transitioned to offline. 

However, I am trying to understand/potentially isolate between the two reported issues. On the NOK boards, have you tried sending packets? If so, are you seeing packet loss?

Sincerely,

Gerome