• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 411 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DP83826I: PHY receives valid data but sends non-valid data

Howard E. Kaiser
Prodigy 45 points
Part Number: DP83826I


Hi there,

we have the PHY DP83826I on our board, receiving valid packages in Linux is possible, but ARP replies or broadcasts never reach other hosts on the same switch, never get's assigned an IP by the DHCP server, pings don't work. And there is TX data on the MII, valid signals on all 4 lines and different bit streams aswell including preamble.

Linux says there are packages sent aswell:

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:07:05:12:a7:12 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
10941 85 0 0 0 0
TX: bytes packets errors dropped carrier collsns
7415 45 0 0 0 0

Any ideas what's wrong? Here are the base registers:

0x0: 0x3000
0x1: 0x786d
0x2: 0x2000
0x3: 0xa110
0x4: 0x0de1
0x5: 0xcde1
0x6: 0x000f
0x7: 0x2001
0x8: 0000
0x9: 0000
0xa: 0x0102
0xb: 0000
0xd: 0x4007
0xe: 0000
0xf: 0000
0x10: 0x0015
0x11: 0x0109
0x12: 0x6400
0x13: 0x2800
0x14: 0000
0x15: 0000
0x16: 0x0100
0x17: 0x0049
0x18: 0x0400
0x19: 0xbc05
0x1a: 0000
0x1b: 0x007d
0x1c: 0x05ee
0x1e: 0x0102
0x1f: 0000

  • 0
    TI__Mastermind 19621 points

    Hi Howard,

    Could you provide me with the schematic, the intended mode, and fill out the checklist linked below please?

    4314.DP83826_Schematic_Design_Review_Checklist.xlsx

    Thank you for providing the Register Dump, this is very helpful for debugs.

    From the Register dump we can see that Link is up, from both Reg 0x0001 and 0x0010

    Could you read Register 0x15 multiple times? If it remains 0000 then there are no errors on cable connection side, which could mean the issue is on the MAC side.

    If it's Mac side issue, check if MAC interface is programmed correctly, Check Strap Registers (0x467) to see if PHY straps are programmed as intended.

    Regards,

    Alvaro

  • 0 in reply to Alvaro (Al-vuh-roe) Reyes
    Prodigy 45 points
    Thanks for the help, Alvaro.

    The intended mode is MII.

    0x15 remains 0000. Here are the extended regs:

    25: 0x41
    27: 0x0
    2a: 0x7998
    117: 0x8147
    131: 0x228a
    170: 0xc12
    171: 0xc850
    173: 0xd04
    175: 0x1004
    176: 0x5
    177: 0x1e00
    178: 0x2
    180: 0x0
    181: 0x0
    182: 0x0
    183: 0x0
    184: 0x0
    185: 0x0
    186: 0x0
    187: 0x0
    188: 0x0
    189: 0x0
    18a: 0x0
    302: 0x0
    303: 0x8
    304: 0xd
    305: 0xe
    306: 0xe
    308: 0x980
    30b: 0x3c00
    30c: 0x410
    30e: 0x8400
    404: 0x80
    40d: 0x8
    456: 0x8
    460: 0x565
    461: 0x10
    467: 0x286
    468: 0x85
    469: 0x0
    4a0: 0x1000
    4a1: 0x0
    4a2: 0x0
    4a3: 0x0
    4a4: 0x0
    4a5: 0x0
    4a6: 0x0
    4a7: 0x0

    We checked the strap pins, they are set as expected. But we found something else. In Datasheet Rev. E the LED1 pin is defined as LED1 per default (for basic mode which we use). But in register 304h we read 0x000D (TX_ER), according to the datasheet this should be 0x0008.

    Your excel sheet differs in comparison to the datasheet. Furthermore the INT pin is defined as output (INT) in register 11h, where we read 0x010B after reset. But according to the datasheet this should be 0x0108 (PWRDWN), "Interrupt: The default function of this pin is power down.". Also we have PHY revision number 0 in register 3h, Datasheet expects revision number 1.

    Could you please clarify this.
  • +1 in reply to Howard E. Kaiser
    Prodigy 45 points

    It turns out that we mistakenly thought we had a revision 1 chip, but actually it's a rev 0 chip. So maybe we can solve this now, I will report.