DP83TD510E: PHY slave ping issue

Hi Fabio,

Looking at the info above, we only have issues when the PHY is slave on copper side and doesn't have issues when PHY is master on copper side. RMII Master/Slave doesn't have any bearing in this case. Is my assumption correct?

The link partner is still DP83TD510E PHY, correct?

--
Regards,
Gokul.

Hi Gokul,

I confirm you that we have issues only when the PHY is slave on copper side; my datails on PHY-MAC interface are only to complete informations.

We are using a commercial media converter as link partner but we have exactly the same issue using DP83TD510E-EVM as media converter.

Regards,

Fabio

Hi Fabio,

Team and I are out for Diwali. I'll reply to you by end of Thursday.

--
Regards,
Gokul.

Hi Fabio,

Sorry for the delay in response.

I have one question related to your system. From my understanding, your system is [MAC-DP83TD510E] connected to another set of [MAC-DP83TD510E].

When you say that you are observing a ping problem when 510E is configured as slave and not in master, I don't understand why one works and other doesn't work. When one of the 510E is resolved to be master, the other one is slave. This means that when you are trying to ping from one MAC to other MAC, you should not be able to do it.

Besides this, I suggest rechecking again if the device is properly configured as master or preferred master.

To configure device as Master and other one as slave, please do the following

On Master, please configure

1. 0x000D = 0x0007
2. 0x000E = 0x0202
3. 0x000D = 0x4007
4. 0x000E = 0x1001
5. 0x000D = 0x0001
6. 0x000E = 0x0834
7. 0x000D = 0x4001
8. 0x000E = 0x4002

On Slave, please configure

1. 0x000D = 0x0007
2. 0x000E = 0x0202
3. 0x000D = 0x4007
4. 0x000E = 0x0001
5. 0x000D = 0x0001
6. 0x000E = 0x0834
7. 0x000D = 0x4001
8. 0x000E = 0x0002

--
Regards,
Gokul.

Hi Gokul,

thank you for your reply.

Gokul Koraganji said:

I have one question related to your system. From my understanding, your system is [MAC-DP83TD510E] connected to another set of [MAC-DP83TD510E].

No, our device is MAC-DP83TD510E connected to a commercial media converter to comunicate on ethernet with a PC and we have issue only if our device is slave on copper side.

The question is: why we encounter ping issue, reported from MAC as dribble error, only when PHY is slave on copper side?

Thank you for registers configuration.

Regards

Fabio

Hi Fabio,

I am not aware of what 'Dribble error' means in this context. Can you please let me know what MAC meant by Dribble error?

Can you please share the clocking scheme for DP83TD510 and MAC? Are you using the same clock source for both MAC and PHY?
This is not a requirement, but I want to understand the application to have guesses on why the issue is arising.

--
Regards,
Gokul.

Hi Gokul,

from MAC reference manual: "DRIBBLE BIT ERROR: when this bit is set, it indicates that the received packet has a non-integer multiple of bytes (odd nibbles)."

In our application PHY and MAC share a 50MHz / 50ppm clock from a LVCMOS oscillator; PHY is configured as RMII slave and MAC as RMII master.

We've tried also a different configuration: 25MHz / 50ppm clock from a LVCMOS oscillator to the PHY, RX_CLK from PHY to MAC; in this test PHY is configured as RMII master and MAC as RMII slave. We had the same issue as in our previous configuration.

Regards,

Fabio

Hi Fabio,

I now understand the clock scheme. When MAC is used as RMII Master, the transmission from MAC needs to follow certain timing w.r.t to 50MHz clock which is fed to the ethernet PHY.

Can you please check if the timing of RMII transmission from MAC and data sampling is met based on 100M RMII Timing sub section in Section 8.6 of datasheet?

--
Regards,
Gokul.

Hi Gokul,

yes, RMII timing is ok and meet datasheet specifications (otherwise we should have same issue when we work as master on copper side, but it works fine).

Regards,

Fabio

Hi Fabio,

Can you please check if the link partner clock is within +/-100ppm?

I am trying to collect list of registers which can be read to find out what is causing the issue.

--
Regards,
Gokul.

Hi Gokul,

yes, we can confirm that the link partner clock is within +/-100ppm. FYI I can see exactly the same issue using DP83TD510E-EVM as link partner.

Regards,

Fabio

Hi Fabio,

Sorry for the delay in response. I want to go a step back and understand more on the setup.

1. You have your custom board with MAC and DP83TD510E. When you are trying to ping, you are connecting ,your custom board with one more custom board of the same flavor. Is that correct?
2. In the above case, when you ping from one of boards, you are able to ping the other board when the DUT board is Master. Is this correct?
3. When you tried to ping using 510E-EVM, how and what were you pinging? Are you connecting the Standard Ethernet port of EVM to a PC and pinging?

--
Regards,
Gokul.

Hi Gokul,

thank you for your reply.

Attached you can find a logic schematic with our setup; hope this can clarify.

Regards,

Fabio

Logic_Sch.pdf

Hi Fabio,

i am on leave today. I'll try to respond by end of tomorrow.

--
Regards,
Gokul.

Hi Fabio,

Thanks for sharing this. It is clear now.

Can we please trying ping between custom board and custom board? 

--
Regards,
Gokul.

Hi Gokul,

sorry but our custom board is just a simple sensor and we aren't able to try the setup you suggested.

Regards,

Fabio

Hi Fabio,

Can you please do the following experiments:

Experiment-1:
Setup: PC -> Commercial Standard-SPE connector -> 510E custom board

Please read the registers 0x1 (read twice), 0xA80, 0x17, 0x467, 0x468 after issuing a ping.

It is recommended to get the register values when 510E is both master or slave.

Experiment-2:
Setup: PC->510EVM-MC -> 510E custom board

Please read the registers 0x1 (read twice), 0xA80, 0x17, 0x467, 0x468 after issuing a ping on both the 510E devices.

It is recommended to get the register values when 510E is both master or slave.

Experiment-3:
Setup: PC -> Commercial Standard-SPE connector -> 510EVM-MC

Please read the registers 0x1 (read twice), 0xA80, 0x17, 0x467, 0x468 on 510E after issuing a ping.

It is recommended to get the register values when 510E is both master or slave.

--
Regards,
Gokul.

Hi Gokul,

you can find below the answers to the experiments required.

Gokul Koraganji said:

Experiment-1:
Setup: PC -> Commercial Standard-SPE connector -> 510E custom board

Please read the registers 0x1 (read twice), 0xA80, 0x17, 0x467, 0x468 after issuing a ping.

It is recommended to get the register values when 510E is both master or slave.

510E custom board master: 0x1=>0x016D, 0x1=>0x016D, 0xA80=>0x0000, 0x17=>0x40A1, 0x467=>0x0134, 0x468=>0x0000

510E custom board slave: 0x1=>0x016D, 0x1=>0x016D, 0xA80=>0x182C, 0x17=>0x40A1, 0x467=>0x0134, 0x468=>0x0000

Gokul Koraganji said:

Experiment-2:
Setup: PC->510EVM-MC -> 510E custom board

Please read the registers 0x1 (read twice), 0xA80, 0x17, 0x467, 0x468 after issuing a ping on both the 510E devices.

It is recommended to get the register values when 510E is both master or slave.

510E custom board master: 0x1=>0x016D, 0x1=>0x016D, 0xA80=>0x0000, 0x17=>0x40A1, 0x467=>0x0134, 0x468=>0x0000

510E custom board slave: 0x1=>0x016D, 0x1=>0x016D, 0xA80=>0xFC81, 0x17=>0x40A1, 0x467=>0x0134, 0x468=>0x0000

Gokul Koraganji said:

Experiment-3:
Setup: PC -> Commercial Standard-SPE connector -> 510EVM-MC

Please read the registers 0x1 (read twice), 0xA80, 0x17, 0x467, 0x468 on 510E after issuing a ping.

It is recommended to get the register values when 510E is both master or slave.

Sorry but I can't figure out how to do this: 510EVC-MC is not an ethernet device and it cannot respond to ping requests.

FaMa said:

It would help if a new datasheet revision will include all registers detail.

You asked us to read register that are not documented in datasheet... could you please share that registers description?

Thanks!

Regards

Fabio

Hi Fabio,

510EVM-MC is also a media converter. You can connect the standard ethernet port on the EVM to a PC and ping PC-PC. You can take a look at the user guide here https://www.ti.com/tool/DP83TD510E-EVM

If you can't get the standard ethernet side of the EVM up and running, you can ignore it and collect the registers without ping.

For experiment-3, you need not issue a ping. You can just link-up the 510EVM with Commercial Standard-SPE connector and read the registers.

Only register 0xA80 is not part of the datasheet. This is an internal register and usually kept out of datasheet. This register can give us info about the ppm offset between link partner and DUT.

--
Regards,
Gokul.

Hi Gokul,

below you can find experiment-3 results (without ping, only link):

510E-EVM master: 0x1=>0x016D, 0x1=>0x016D, 0xA80=>0x0000, 0x17=>0x4021, 0x467=>0x0006, 0x468=>0x0000

510E-EVM slave: 0x1=>0x016D, 0x1=>0x016D, 0xA80=>0x1C35, 0x17=>0x4021, 0x467=>0x0006, 0x468=>0x0000

Gokul Koraganji said:

Only register 0xA80 is not part of the datasheet

Register 0x1 is not part of the datasheet, register 0x468 is reported as reserved...

Regards,

Fabio

Hi Fabio,

Through the above registers, I tried to capture the clock frequency offset and RMII buffer overflow status and looks like there are no leads there.

A few questions before I propose next experiments

1. You are pinging the PC from the uC-MAC, correct? Can you ping the uC-MAC from the PC? Do you see errors there too?
2. For above experiment-2, were you able to use 510EVM-MC as media converter and use it as a bridge between PC and custom 510 board?

I am thinking that using PC->510EVM-MC-> 510 Custom Board for all the next set of experiments since you already see issues with this configuration.

Experiment-4: Pinging from both sides using 510EVM-MC as bridge

1. Can you please ping both from both sides and let me know if any of the following 4 ping cases have a problem.
   • Ping from PC & Custom 510 board Master
   • Ping from PC & Custom 510 board Slave
   • Ping from PC & Custom 510 board Master
   • Ping from PC & Custom 510 board Slave

Experiment-5: Increasing RMII buffer size on 510 Custom Board

1. Program 0x0011 = 0x006A, 0x0017 = 0x40A0
2. Try ping in the four cases above

Please let me know if you need more details.

--
Regards,
Gokul.

Hi Gokul,

Gokul Koraganji said:

You are pinging the PC from the uC-MAC, correct? Can you ping the uC-MAC from the PC? Do you see errors there too?

No, we are always pinging uC-MAC from PC (we haven't implemented ping function in our uC).

Gokul Koraganji said:

For above experiment-2, were you able to use 510EVM-MC as media converter and use it as a bridge between PC and custom 510 board?

Yes

Gokul Koraganji said:

Experiment-4: Pinging from both sides using 510EVM-MC as bridge

1. Can you please ping both from both sides and let me know if any of the following 4 ping cases have a problem.
   • Ping from PC & Custom 510 board Master
   • Ping from PC & Custom 510 board Slave

We can only ping from PC to Custom board; when custom board is master OK, when custom board is slave we see issue as described above.

Gokul Koraganji said:

Experiment-5: Increasing RMII buffer size on 510 Custom Board

1. Program 0x0011 = 0x006A, 0x0017 = 0x40A0
2. Try ping in the four cases above

We changed registers as per your suggestion, same result as Experiment-4 (custom board master=OK, custom board slave=KO)

Thanks

Regards,

Fabio

Hi Fabio,

Thanks for the update. I suggest we now look into whether the packets are received properly by the 510E of the custom board. We can do this by reading packet counter.

I suggest doing the following. (Use Single packet ping for this experiment and not continuous ping packets)
Board setup: PC-> 510EVM-MC -> 510E Custom Board

1. Send a single ping packet from PC.
2. Read registers 0x12A, 0x12B, 0x12C, 0x12D, 0x12E, 0x12F, 0x130 exactly in the same order (please check the datasheet and what these registers are) on both 510EVM-MC and 510E custom board.
   These registers are self clearing. Incase the read values of all the registers are 0 (only if all of them are 0), then please send one more ping packet and read them.

It is better to capture these in both Master and Slave cases of 510E Custom baord.

Please let me know if you need more details.

--
Regards,
Gokul.

Hi Gokul,

we had the test you suggested with following results:

1) PING OK

510EVM (SLAVE) 

0x12A=0x000, 0x12B=0x001, 0x12C=0x000, 0x12D=0x000, 0x12E=0x001, 0x12F=0x000, 0x130=0x000

510E custom (MASTER)

0x12A=0x000, 0x12B=0x001, 0x12C=0x000, 0x12D=0x000, 0x12E=0x001, 0x12F=0x000, 0x130=0x000

2) PING OK

510EVM (MASTER)

0x12A=0x000, 0x12B=0x001, 0x12C=0x000, 0x12D=0x000, 0x12E=0x001, 0x12F=0x000, 0x130=0x000

510E custom (SLAVE)

0x12A=0x000, 0x12B=0x001, 0x12C=0x000, 0x12D=0x000, 0x12E=0x001, 0x12F=0x000, 0x130=0x000

3) PING KO

510EVM (MASTER)

0x12A=0x000, 0x12B=0x001, 0x12C=0x000, 0x12D=0x000, 0x12E=0x000, 0x12F=0x000, 0x130=0x000

510E custom (SLAVE)

0x12A=0x000, 0x12B=0x000, 0x12C=0x000, 0x12D=0x000, 0x12E=0x001, 0x12F=0x000, 0x130=0x000

Thank you!

Regards

Fabio

Hi Fabio,

The pin packets are received until the 510E custom board successfully with no errors. Looks to be a problem in the MAC interface.

Can you please let me know if you are using CRS_DV or RX_DV functionality? Is it possible for you to move to RX_DV functionality and check if the problem still persists?

--
Regards,
Gokul.

Hi Fabio,

Can you please let me know about CRS_DV and RX_DV functionality?

--
Regards,
Gokul.