DP83TD510E: Error counters

Part Number: DP83TD510E

Hello team,

We are starting testing the EVM to validate the DP83TD510 .

I read the registers of the packing counter.

RX             TX
0x012E     0x012B
0x012F     0x012C
0x0130     0x012D

Strangely, the register for the send error counter 0x012D always has the same value as that of the send counter (0x012B and 0x012C).

The packets are simple pings to which an answer comes, i.e. no packets are discarded.

What could be the reason for it?

Thanks,

SunSet

  • Hi SunSet,

    I have a couple of questions:

    1. Can I have the exact values that you are reading in these registers?
    2. Can you read 0x012B, 0x012C, 0x012D to clear the registers?

    Please try to do this 4-5 after few seconds each time to kindly confirm that you can successfully clear the registers.

    Can you also provide a block diagram for your setup?

    1. Link partner on cable side, mac and what packets are being generated to where?

    Kind Regards,

    Joe

    All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (http://www.ti.com/corp/docs/legal/important-notice.shtml)

  • My Setup, consist of two DP83TD510 Evaluaitonboard conected with a special SPE Cabel from Harting. On the one side is a Raspberry Pi 4 wich is getting pinged at 1Hz from my Thinkpad. This Thinkpad is reading the Registers with a python script regularly.



    The register are cleared after the reading, of all three of them in seqence, so i acumulate in my script the results. I'v sniffed the communication of the USB-2MDIO and i'm doing just the same thing, on the Serial Port. In my Code im reading the RX and the TX counters, the problem only shows with the TX counters.


    import serial
    import time
    import math
    ser = serial.Serial(
        port='COM6', 
        baudrate=9600, 
        timeout = None,
        parity=serial.PARITY_NONE,
        stopbits=serial.STOPBITS_ONE,
        bytesize=serial.EIGHTBITS
    )
    TX = 0
    TX_err = 0
    RX = 0
    RX_err = 0
    
    def read_TI_register(ID, address): 
        request = f"{ID:02}{address:04X}=/"
        #print(f"request: {request}")
        ser.write(bytes(request,'utf-8'))
        response = ser.readline()
        #print(f"response: {response}")
        i_response = int(str(response,'utf-8'),16)
        #print(f"read  Register: 0x{address:04X} = 0x{(str(response,'utf-8'))}")
        return i_response
    
    def read_TI_register_exd(ID, address): 
        request = f"{ID:02}{address:04X}*/"
        #print(f"request: {request}")
        ser.write(bytes(request,'utf-8'))
        response = ser.readline()
        #print(f"response: {response}")
        i_response = int(str(response,'utf-8'),16)
        #print(f"read  Register: 0x{address:04X} = 0x{(str(response,'utf-8'))}")
        return i_response
    
    def write_TI_register(ID, address, value): 
        request = f"{ID:02}{address:04X}{value:04X}*/"
        ser.write(bytes(request,'utf-8'))
        response = ser.readline()
        i_response = int(str(response,'utf-8'),16)
        #print(f"wrote Register: 0x{address:04X} = 0x{(str(response,'utf-8'))}")
        return i_response
    
    def read_MSE_dB(ID):
        r = read_TI_register(ID, 0x872)
        MSE = 10 * math.log10(r/2**17)
        SNR = MSE - 1.76
        #print(f"MSE: {MSE:f} dB, SNR: {SNR:f} dB")
        return MSE
    
    #read_MSE_dB(0)
    
    def read_n_clear_tx_pkt_cnt():
        global TX
        global TX_err
        TX = TX + read_TI_register_exd(0, 0x12B) 
        TX = TX + read_TI_register_exd(0, 0x12C) * 2**16
        TX_err = TX_err+ read_TI_register_exd(0, 0x12D)
        print(f"tx_cnt = {TX} tx_error = {TX_err}")
        return TX
    
    def read_n_clear_rx_pkt_cnt():
        global RX
        global RX_err
        RX = RX + read_TI_register_exd(0, 0x12E) 
        RX = RX + read_TI_register_exd(0, 0x12F) * 2**16
        RX_err = RX_err + read_TI_register_exd(0, 0x130)
        print(f"rx_cnt = {RX} rx_error = {RX_err}")
        return TX
    
    try:
        while True:
            read_n_clear_rx_pkt_cnt()
            read_n_clear_tx_pkt_cnt()
            time.sleep(5)
    except KeyboardInterrupt:
        print('interrupted!')
    
  • Hi Lucas,

    I have a couple of experiments that I would like you to conduct to better troubleshoot your issue:

    1. Can you remove the cable and use the think pad to send packets through the DP83TD510?
      1. Make sure you have the DP83TD510 set for digital loopback
      2. See if the think pad is able to receive all of the packets back without any errors
    2. Can you do the same thing for the raspberry pi and the second DP83TD510?

    Kind Regards,

    Joe

    All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

  • Hi Joe,

    I'm struggeling to achive your task, becaus I fail to set the NIC of the Thinkpad into the Promiscuous Mode, so it recives the wrong MAC addresses anyway. Either that or the digital loopback isn't working. I set the regiter 0x016 to 0b0000_0001_0000_0100 to enable the loopback. This action takes place after I've sent allready some pings to establisch data in the arp-cach. After his step obiviously there is no more responses of the Pi. But the request should come back into the thinkpad, wich it doesn't. I'm suspecting the NIC "filtering" the wrong MAC-Address away, on the otherhand wireshark could remove the duplicates as they are send an recived rather quickly.


    Kind Regards,

    Lukas

  • Hi Lucas,

    What is the interface connecting the ThinkPad to the DP83TD510 EVM and what are the connected pins from the EVM?

    Using DP83TD510 EVM, can you try a packet generation using the EVM standalone? Do not connect the other DP83TD510 EVM or the ThinkPad.

    Next, put DP83TD510 in digital loopback, then put the DP83822 in digital loopback.

    Use the DP83822 to generate packets and then check for errors in register 0x0015 in the DP83822.

    By doing this, we will confirm the MAC side data path between DP83822 and DP83TD510 is experiencing no issues.

    Please let me know if you need any clarification on this test setup.

    Kind Regards,

    Joe

    All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

  • Hi Joe,

    I was reading up on the digital loopback of the DP83TD510 when I noticed on page 29 that I need to set a mystery bit 0x0883[0] to one.

    After setting both the digital loopback and the mystery bit to one the, I got back the request back after sending it.
    So the packets get through the digital loopback unchanged.

    The 0x0883 register isn't described in the datasheet of the DP83TD510, so I was wondering of you could provide me the full registermap to avoid such confusions in the future.

    In this scenario the packet counters look like expected so the error counters stay a zero and the normal counters increase with every packet.

    Kind Regards

    Lukas

  • Hi Lukas,

    Thank you for bringing this to our attention. We will include this information in the next datasheet revision. I will now close this post but if you need further support, please reply to this post or create a new thread.

    Kind Regards,

    Joe

    All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

  • Hi Joe,

    I'm sory but the issue of the wrong counters is only resolved in the digital loopback, not during normal operation.

    This indicates a problem in a diverent part of the Phy. I am not sure about the behavior of the error counter, could it only increasd by an CRC Error. Im going to investigate with different loopback modes, maybe I'll find something.

    Kind Regard

    Lukas

    Edit1:

    I was reading back the whole thread if there was any thing I could have missed, and yes I got the recive and send mixed up the EROR is on the RX Counters so on 0x12E 0x12F and 0x130. I'm so sorry I've mixed up these in my initial request.

    On the other hand, I'm not sure if this has any impact on the findings of our investigation.

    Edit2:

    I've enabeld the analog Loopback and found a very strange behavior the first and one other packet after enableing the analog loopback gets back to my Thinkpad but the rest isn't coming back, and the RX Error Counters are increasing after that again. This is the first time a "faulty" packet is actualy discarded.

    rx_cnt = 2 rx_error = 2
    tx_cnt = 3 tx_error = 0
    rx_cnt = 3 rx_error = 3
    tx_cnt = 4 tx_error = 0
    rx_cnt = 4 rx_error = 4
    tx_cnt = 5 tx_error = 0
    rx_cnt = 5 rx_error = 5
    tx_cnt = 6 tx_error = 0
    rx_cnt = 6 rx_error = 6
    tx_cnt = 7 tx_error = 0
    rx_cnt = 8 rx_error = 8
    tx_cnt = 9 tx_error = 0
    rx_cnt = 9 rx_error = 9
    tx_cnt = 10 tx_error = 0
    rx_cnt = 10 rx_error = 10
    tx_cnt = 11 tx_error = 0
    rx_cnt = 11 rx_error = 11
    tx_cnt = 12 tx_error = 0
    rx_cnt = 12 rx_error = 12
    tx_cnt = 13 tx_error = 0
    analog Loopback enabled
    rx_cnt = 12 rx_error = 12
    tx_cnt = 14 tx_error = 0
    rx_cnt = 13 rx_error = 13
    tx_cnt = 15 tx_error = 0
    rx_cnt = 14 rx_error = 13
    tx_cnt = 16 tx_error = 0
    rx_cnt = 15 rx_error = 14
    tx_cnt = 17 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 18 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 19 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 20 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 21 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 22 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 23 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 24 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 25 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 26 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 27 tx_error = 0
    rx_cnt = 17 rx_error = 14
    tx_cnt = 28 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 29 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    interrupted!

  • Hi Joe,

    I'm sory but the issue of the wrong counters is only resolved in the digital loopback, not during normal operation.

    This indicates a problem in a diverent part of the Phy. I am not sure about the behavior of the error counter, could it only increasd by an CRC Error. Im going to investigate with different loopback modes, maybe I'll find something.

    Kind Regard

    Lukas

    Edit1:

    I was reading back the whole thread if there was any thing I could have missed, and yes I got the recive and send mixed up the EROR is on the RX Counters so on 0x12E 0x12F and 0x130. I'm so sorry I've mixed up these in my initial request.

    On the other hand, I'm not sure if this has any impact on the findings of our investigation.

    Edit2:

    I've enabeld the analog Loopback and found a very strange behavior the first and one other packet after enableing the analog loopback gets back to my Thinkpad but the rest isn't coming back, and the RX Error Counters are increasing after that again. This is the first time a "faulty" packet is actualy discarded.

    rx_cnt = 2 rx_error = 2
    tx_cnt = 3 tx_error = 0
    rx_cnt = 3 rx_error = 3
    tx_cnt = 4 tx_error = 0
    rx_cnt = 4 rx_error = 4
    tx_cnt = 5 tx_error = 0
    rx_cnt = 5 rx_error = 5
    tx_cnt = 6 tx_error = 0
    rx_cnt = 6 rx_error = 6
    tx_cnt = 7 tx_error = 0
    rx_cnt = 8 rx_error = 8
    tx_cnt = 9 tx_error = 0
    rx_cnt = 9 rx_error = 9
    tx_cnt = 10 tx_error = 0
    rx_cnt = 10 rx_error = 10
    tx_cnt = 11 tx_error = 0
    rx_cnt = 11 rx_error = 11
    tx_cnt = 12 tx_error = 0
    rx_cnt = 12 rx_error = 12
    tx_cnt = 13 tx_error = 0
    analog Loopback enabled
    rx_cnt = 12 rx_error = 12
    tx_cnt = 14 tx_error = 0
    rx_cnt = 13 rx_error = 13
    tx_cnt = 15 tx_error = 0
    rx_cnt = 14 rx_error = 13
    tx_cnt = 16 tx_error = 0
    rx_cnt = 15 rx_error = 14
    tx_cnt = 17 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 18 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 19 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 20 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 21 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 22 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 23 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 24 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 25 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 26 tx_error = 0
    rx_cnt = 16 rx_error = 14
    tx_cnt = 27 tx_error = 0
    rx_cnt = 17 rx_error = 14
    tx_cnt = 28 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 29 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    rx_cnt = 18 rx_error = 15
    tx_cnt = 30 tx_error = 0
    interrupted!

    Edit3:

    I wanted to try something different and used the other 10BASe-T1L Phy currently avalibel, to check if the prolem is also acuring in this scenario wich it is not. So there we have it's a problem with the sending site, if the sending side is another DP83TD510. A colleague tiped me of that maybe the CRC is coreting the Error and therefor is incrementig the counter, this would explain the (from an black box perspektive) flawless communikation.

    Edit4:

    Measuring the other DP83TD510 revealed the confusion about the RX/TX counters. Depending on witch side you look at its ether a RX or a TX Error.

  • Hi Lukas,

    Sorry for my confusion about solving your issue.

    I will continue to look into this and get back to you by the end of business tomorrow.

    Kind Regards,

    Joe

    All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

  • Hi Lukas,

    It sounds like there is a question of whether or not the DP83TD510 is sending good data. By performing these below experiments, we will be able to see if this is the case. 

    1. Generate PRBS data from the DP83TD510
      1. Set the PHY for digital loopback
        1. This will send the PRBS data through the MAC
        2. Count the RX_ER counter in the DP83TD510
    2. Generate PRBS data from the DP83TD510
      1. Use the other T1L compatible PHY to receive data
        1. Then check RX errors on the other PHY

    Please let me know if you need further clarification. 

    Kind Regards,

    Joe

    All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

  • Hi Joe,

    I was able to start the PRBS generator with the digital loopback. After this the RX and TX couter were increasing, also the TX_ERR and the RX_ERR were increasing at the same rate.

    rx_cnt = 11938 rx_error = 11938
    tx_cnt = 12064 tx_error = 12064

    If i diable the digital loopback and coneccted the other 10BASE-T1L Board as sugested, the RX Error  Counter of the other Phy is increasing. The Errors are so big that the other Phy is discarding the packets, non of them get throug to my Thinkpad. 

    rx_cnt = 0 rx_error = 0
    tx_cnt = 27383 tx_error = 27383

    MSE -31.0 dB PWR off Rx 0, Err 27383 

    I'm testing if the other DP83TD510_EMV is showing a similar behavior. Obviously there is a smal differents in the packet count between the rx2 and the tx1, due to the different times of the readout of the counters.

    rx1_cnt = 0 rx1_error = 0
    rx2_cnt = 7863 rx2_error = 7863
    tx1_cnt = 7874 tx1_error = 7874
    tx2_cnt = 0 tx2_error = 0

    I'm starting to wonder if there is a differents between my two DP83TD510_EMV  Boards, either Hardware or Software.

    Kind Regards

    Lukas Maier

  • Hi Lukas,

    Thank you for performing those tests. Can you provide the values for the following registers?

    • 0x0000
    • 0x0002
    • 0x0003
    • 0x0010
    • 0x0011
    • 0x0467
    • 0x0468

    Kind Regards,

    Joe

    All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

  • Hi Joe,

    could you verify that my setup of the PRBS is corect

    //PRBS Setup
    0x119 => 0b0000_0101_0101_0111
    0x11F => 0b0000_0000_0000_0001

    I've read out the registers after five scenarios.

    //With PRBS and digital loopback enabled on 1
    rx2_cnt = 3161 rx2_error = 3161
    tx2_cnt = 3194 tx2_error = 3194
    tx1_cnt = 2 tx1_error = 0
    rx1_cnt = 10 rx1_error = 10
    
    registers of 1
    read  Register: 0x0000 = 0x1100
    read  Register: 0x0002 = 0x2000
    read  Register: 0x0003 = 0x0181
    read  Register: 0x0010 = 0x0000
    read  Register: 0x0011 = 0x002A
    read  Register: 0x0467 = 0x0086
    read  Register: 0x0468 = 0x0000
    
    registers of 2
    read  Register: 0x0000 = 0x1100
    read  Register: 0x0002 = 0x2000
    read  Register: 0x0003 = 0x0181
    read  Register: 0x0010 = 0x0001
    read  Register: 0x0011 = 0x002A
    read  Register: 0x0467 = 0x0086
    read  Register: 0x0468 = 0x0000

    rx2_cnt = 3161 rx2_error = 3161
    tx2_cnt = 3194 tx2_error = 3194
    tx1_cnt = 2 tx1_error = 0
    rx1_cnt = 10 rx1_error = 10
    
    registers of 1
    read  Register: 0x0000 = 0x1100
    read  Register: 0x0002 = 0x2000
    read  Register: 0x0003 = 0x0181
    read  Register: 0x0010 = 0x0000
    read  Register: 0x0011 = 0x002A
    read  Register: 0x0467 = 0x0086
    read  Register: 0x0468 = 0x0000
    
    registers of 2
    read  Register: 0x0000 = 0x1100
    read  Register: 0x0002 = 0x2000
    read  Register: 0x0003 = 0x0181
    read  Register: 0x0010 = 0x0001
    read  Register: 0x0011 = 0x002A
    read  Register: 0x0467 = 0x0086
    read  Register: 0x0468 = 0x0000

    //With PRBS and digital loopback enabled on 2
    rx2_cnt = 5780 rx2_error = 5780
    tx2_cnt = 5864 tx2_error = 5864
    tx1_cnt = 1 tx1_error = 0
    rx1_cnt = 1 rx1_error = 0
    
    registers of 1
    read  Register: 0x0000 = 0x1100
    read  Register: 0x0002 = 0x2000
    read  Register: 0x0003 = 0x0181
    read  Register: 0x0010 = 0x0001
    read  Register: 0x0011 = 0x002A
    read  Register: 0x0467 = 0x0086
    read  Register: 0x0468 = 0x0000
    registers of 2
    read  Register: 0x0000 = 0x1100
    read  Register: 0x0002 = 0x2000
    read  Register: 0x0003 = 0x0181
    read  Register: 0x0010 = 0x0001
    read  Register: 0x0011 = 0x002A
    read  Register: 0x0467 = 0x0086
    read  Register: 0x0468 = 0x0000

    //with PRBS enabled and disabled digital loopback on 1
    rx2_cnt = 1580 rx2_error = 1578
    tx2_cnt = 0 tx2_error = 0
    tx1_cnt = 1596 tx1_error = 1594
    rx1_cnt = 0 rx1_error = 0
    
    registers of 1
    read  Register: 0x0000 = 0x1100
    read  Register: 0x0002 = 0x2000
    read  Register: 0x0003 = 0x0181
    read  Register: 0x0010 = 0x0001
    read  Register: 0x0011 = 0x002A
    read  Register: 0x0467 = 0x0086
    read  Register: 0x0468 = 0x0000
    
    registers of 2
    read  Register: 0x0000 = 0x1100
    read  Register: 0x0002 = 0x2000
    read  Register: 0x0003 = 0x0181
    read  Register: 0x0010 = 0x0001
    read  Register: 0x0011 = 0x002A
    read  Register: 0x0467 = 0x0086
    read  Register: 0x0468 = 0x0000

    //with PRBS enabled and disabled digital loopback on 2
    rx2_cnt = 2 rx2_error = 0
    tx2_cnt = 2406 tx2_error = 2406
    tx1_cnt = 2 tx1_error = 0
    rx1_cnt = 2415 rx1_error = 2415
    
    registers of 1
    read  Register: 0x0000 = 0x1100
    read  Register: 0x0002 = 0x2000
    read  Register: 0x0003 = 0x0181
    read  Register: 0x0010 = 0x0001
    read  Register: 0x0011 = 0x002A
    read  Register: 0x0467 = 0x0086
    read  Register: 0x0468 = 0x0000
    
    registers of 2
    read  Register: 0x0000 = 0x1100
    read  Register: 0x0002 = 0x2000
    read  Register: 0x0003 = 0x0181
    read  Register: 0x0010 = 0x0001
    read  Register: 0x0011 = 0x002A
    read  Register: 0x0467 = 0x0086
    read  Register: 0x0468 = 0x0000

    //without running any test after a power down of the Phys
    rx2_cnt = 0 rx2_error = 0
    tx2_cnt = 0 tx2_error = 0
    tx1_cnt = 0 tx1_error = 0
    rx1_cnt = 0 rx1_error = 0
    interrupted!
    registers of 1
    read  Register: 0x0000 = 0x1100
    read  Register: 0x0002 = 0x2000
    read  Register: 0x0003 = 0x0181
    read  Register: 0x0010 = 0x0001
    read  Register: 0x0011 = 0x002A
    read  Register: 0x0467 = 0x0086
    read  Register: 0x0468 = 0x0000
    
    registers of 2
    read  Register: 0x0000 = 0x1100
    read  Register: 0x0002 = 0x2000
    read  Register: 0x0003 = 0x0181
    read  Register: 0x0010 = 0x0001
    read  Register: 0x0011 = 0x002A
    read  Register: 0x0467 = 0x0086
    read  Register: 0x0468 = 0x0000

    Hopefully this provides enought inside into the problem

  • Hi Lukas,

    Sorry for the delayed response. I will look at the information you provided (thank you) and I hope to get back to you by the end of business Friday.

    Kind Regards,

    Joe

    All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

  • Hi Lukas,

    Can you provide your clock frequency and PPM?

    Additionally, can you provide your schematic?

    Kind Regards,

    Joe

    All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

  • Hi Joe,

    I wasn't sure what you want from me I checked that both of the Y4 are oscillating at the target 25MHz, acording to BOM of TI and the  Datasheet of the quarz ABM8AIG-25.000MHZ-12-2Z-T3, has a Freq. Tolerance of ± 20 ppm and a Freq. Stability of  ± 50 ppm. The scematic hasn't been changed. One Bord 1 I installted 3 Pinheaders to the MDIO and MDC.

    Edit: I wanted to test a external clock source for this I mounted the SMA Connector,  after heating the groundplane of both of the Boards the faiure was consistend on both of the so the output reads

    6s
    rx2_cnt = 7 rx2_error = 7
    tx2_cnt = 7 tx2_error = 7
    tx1_cnt = 7 tx1_error = 7
    rx1_cnt = 7 rx1_error = 7
    7s
    rx2_cnt = 8 rx2_error = 8
    tx2_cnt = 8 tx2_error = 8
    tx1_cnt = 8 tx1_error = 8
    rx1_cnt = 8 rx1_error = 8
    8s
    rx2_cnt = 10 rx2_error = 10
    tx2_cnt = 10 tx2_error = 10
    tx1_cnt = 10 tx1_error = 10
    rx1_cnt = 10 rx1_error = 10
    interrupted!
    registers of 1
    read  Register: 0x0000 = 0x1100
    read  Register: 0x0002 = 0x2000
    read  Register: 0x0003 = 0x0181
    read  Register: 0x0010 = 0x0001
    read  Register: 0x0011 = 0x002A
    read  Register: 0x0467 = 0x0086
    read  Register: 0x0468 = 0x0000
    
    registers of 2
    read  Register: 0x0000 = 0x1100
    read  Register: 0x0002 = 0x2000
    read  Register: 0x0003 = 0x0181
    read  Register: 0x0010 = 0x0001
    read  Register: 0x0011 = 0x002A
    read  Register: 0x0467 = 0x0086
    read  Register: 0x0468 = 0x0000

  • Hi Lukas,

    One last experiment that I would like you to try is as follows:

    Please put the DP83TD510 in reverse loopback and use the other DP83TD510 for PRBS generation. Use the PRBS generating DP83TD510 to count the number of sent and received packets.

    Please share the results once you have them.

    Kind Regards,

    Joe

    All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)

  • Hi Lukas,

    Were you able to perform the most recent experiment that I mentioned in my last response to the thread?

    Please share the results once you have them.

    Kind Regards,

    Joe

    All information in this correspondence and in any related correspondence is provided “as is” and “with all faults”, and is subject to TI’s Important Notice (www.ti.com/.../important-notice.shtml)