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 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 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.