This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83869HM: Can DP83869 be used as an etherCAT PHY device, which need restore all 7 bytes preamble and SFD?

Part Number: DP83869HM
Other Parts Discussed in Thread: DP83869

Hi, I designed a 1000M media-converter for an etherCAT link equipment. I have tested it at PCs as general network devices with iperf tool and the throughput can be over 850 Mbps in full-duplex mode.

When tested with the etherCAT link devices, the link can be up and configuration is correct. But I can not make data traffic with it. The major difference between etherCAT and ethernet is that the seven bytes of preamble and the SFD, that are not critical for an ethernet link, but is a MUST option and should be kept perfectly for etherCAT. So I need to make clear if the preamble is restored totally in a media-converter and how I can test the preamble length in a media-converter. 

Can you give me a exact reply?

Thanks!

  • Hello,

    I would like to double check your configuration. When forming the link with the etherCAT device, is that also 1GHz compatible? In addition, is the DP83869HM device configured to function at 1GHz? If there is a mismatch on either of these portions of your system, it may cause data to not be transmitted.

    Sincerely,
    Gerome

  • Hi, 

    I'm sure the link is 1G. I have read the related registers. These register's value are as followd:

    reg[0x00] = 0x1140

    reg[0x01] = 0x796D, link is up, auto-negotiation completed

    reg[0x11] = 0xAF3E, 1000Mbps full duplex

    reg[0xC00] = 0x0140, fiber force mode

    reg[0xC01] = 0x614D, link is up

    I think this chip can be used as an etherCAT PHY because I can send and recieve data correctly in 1G mode.

    I guess that may concern the RGMII clock delay configuration. The probability that can make a good data traffic is relative high if I set RGMII_CTRL register to 0xD3, whichi means the RGMII clock aligned with data. Then I do some tests, but I can not find a good shift-valhe for reg[0x86] when RGMII_CTRL is in shift mode.

    So I need to make clear:

    1. Is that useful to modify RGMII clock skew configuration in a 1000M media-converter?

    2. How to test and select proper receive and transmit skew values for a  media-converter If the above result is YES?

    3. Does ALIGN means a zero delay, which is equal to a shift value of b'1111 just showed as table 61? 

    4. In table 61, what are bit9 and bit8? What values should be set for these two bits?

    Thanks.

  • Hello,

    Can you please send over a system block diagram? I am having trouble envisioning the connections you are making for you media converter.

    Are you talking about the RGMII settings on a PHY that is directly connected to the MAC, or is that PHY part of the media converter portion?

    Sincerely,

    Gerome

  • Hi,

    The testing pattern is as follows:

    PDA testing device --> network device #1 --> twisted pair --> media-converter #1--> fiber --> media-converter #2 -> twisted pair --> network device #2

    In this pattern, the testing command, issued by PDA, will be passed down to network device #2 along the link. So  all links should be up at power-on except the link between network #1 and converter #1, which we named copper-link #1, is down at power-up and will be waked up when get a testing command. The network devices are very-old design implemented an etherCAT protocol which need all seven preamble bytes and SFD to be kept. It is critical in time-delay at the same time.

    The meida-converter is just the same as EVM board and did not have MAC device. 

      

    It is not a theoretical problem because the data traffic is very good when we use the media converter to connect two PCs. In the testing pattern listed above, sometimes it can establish link in a very rare occasion and at that time can get an ideal throughput. The problem is that the link is not stable when used in this testing pattern. So I think it's the issue about some register's configuration. It maybe concern with timing(delay) or preamble length, which is the major difference between ethernet and etherCAT. 

    The RGMII issue I mentioned above is about the internal architecture of the chip for a media converter, i.e if the RGMII interfaced is used inside the chip.

    So I think you can give me some advice related :

    1. How to reduce the data stream delay inside DP83869 in  media-converter mode?

    2. Is there any possible to discard one or more preamble symbols in receiving or transmitting processing, which resulted in less preamble bytes for EtherCAT?

    3. Is the RGMII clock shift used in media-converter mode, or only used when it is connected to MAC?

    Thanks.

  • Hello,

    As the DP83869HM is used in a media-converter functionality, its RGMII connections should be idle as its used to convert data from copper to fiber and vise versa. 

    I would like to propose an experiment to try to gather more information:

    1) Can you connect the etherCAT device over copper to the DP83869 in normal operation and check the registers to see what speed the link is?

    2) Can you try and put the speed of the DP83869 in 100mbps, and see if you get a link then?

    Sincerely,

    Gerome

  • Hi, I have some tries today. It seems the problem is related to speed optimization.

    I disable speed optimization and  enhanced mode, set attempt failure number to eight, i.e. I set 0x2C80 to GEN_CFG2 register(Address 0x14).  Now I can establish link with higher possibility than ever, where can established link very rarely. But there's still about a 20 percent failure.

    So what is the probable reason that can result in these failures? Which configuration I can make a try then?

    Thanks.

  • Hello,

    Could you please tell me your findings from the two experiments I proposed?

    Update 1-12-21 3:18PM PST:

    I would like to isolate where this issue is showing up, whether it would be in normal operation or when used in media conversion as there is more things to account for in that area. By instead of using the DP83869HM in media converter mode to convert between copper to fiber to the other PHY and back to copper, can you connect the two PHYs through copper and see if the link drop occurrence rate is still holding at the same value in this configuration?

    Sincerely,
    Gerome

  • Hi,

    I'm sorry that I misguided you yesterday.

    It's not  the problem of speed optimization. It the stability of reference clock. I used a high stable oscillator when I change the registers.

    The provider of etherCAT equipment said yesterday that the reference clock should be a VCTCXO with frequency stability of 2 ppm. So this is the basic problem.

    Now I need a external PLL to synchronize the local reference clock to the recovered receiving clock. But I found I can not get the  the recovered receiving clock from CLK_OUT pin, which always synchronized to local reference  clock, no matter what I write to IO_MUX_CFG register(Address = 0x170). But I can get it on pin LED_2 / GPIO_0 when I change values of  IO_MUX_CFG register and GPIO_MUX_CTRL.

    This is what I do in MCU:

    ExtRegisterAccess(PhyAddr, IO_MUX_CFG, 0x0410, 'w'); //Configure CLK_OUT Channel A receive clock divided by 5
    ExtRegisterAccess(PhyAddr, GPIO_MUX_CTRL, 0x4170, 'w'); //Output CLK_OUT at LED2

    The output of CLK_OUT pin is the same, which is always 25MHz, no matter what I write in IO_MUX_CFG register.

    But I can get the frequency from pin LED_2 / GPIO_0  if I write 0x4170 to register GPIO_MUX_CTRL. And the frequency is configured in register 0x170.

    So you can confirm the following information:

    1. Does the output of CLK_OUT pin always synchronize to local reference clock and not the internal clock that selected in register 0x170? 

    2.Does the internal clock that selected in register 0x170  output at  LED_2 / GPIO_0  instead of CLK_OUT pin?

    Thanks!

  • Hello,

    I will need to talk to the team regarding these questions. In the meanwhile, can you answer these questions?

    Can you try and double check the clock output when set to 0x0 vs 0x4? You should be seeing a clock division by 5 between the settings. What happens if you do this when the CLK_OUT signal is not set to output at LED_2/GPIO_0? Are there any changes that you see?

    Sincerely,

    Gerome

  • Hi.

    I double checked the output. I'm sure the CLK_OUT pin always outputs 25MHz, no matter what's value in register 0x170 and no matter the LED2 pin is configured as clock output or remains default.

    It is the same 25MHz at CLK_OUT pin, while the output is 125MHz at LED2 pin when the value is 0x0010 in register 0x170. When 0x0410 is written to register 0x170, all pins both output 25MHz but not synchronized. 

    The result is the same as yesterday.

    So I think CLK_OUT is synchronized to reference clock and LED2 pin is the exact output of internal clock.

    Now I want to synchronize local reference clock to recovered receiving clock using a PLL to control a VCXO, which is used as the local reference just like following diagram.

    Now the question is:

    Can the recovered receiving clock output at LED2 pin be used to lock to own local reference clock in  theory? Is there any potential problems that can not be resolved at all ?

    Thanks.

  • Hello,

    I found another thread similar to what you are trying to output with a different CLK_OUT signal. Please let me know if this helps your situation.

    Update 1-14-21 11:45AM PST:

    Hello,

    In theory, your PLL configuration should be okay. However, as this is an application level question, you would need to verify it on your end if it works. Please ensure that the clock signal requirements are still met for the PHY.

    Sincerely,

    Gerome

  • Hi,

    I can get correct output at pin CLK_OUT when I set register 0xC6 to 0x0010. And I have a test on the PLL solution too, which to lock local reference to receiving clock, can work as I wanted. The reference clock now synchronize to receiving clock.

    So I think I get all I wanted now.

    Thank you and have a nice weekend!