• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 149 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.

Original question:

DP83822HF: DP83822HFRHBR Integration Issue

DP83822HF: DP83822HFRHBR Integration Issue

Srijan Ail
Prodigy 20 points
Part Number: DP83822HF

Tool/software:

Hello,

I am currently working on integrating the DP83822 PHY with an STM32H735IGT3 microcontroller to establish Ethernet connectivity. I have configured the Ethernet interface, and when I connect the Ethernet cable, it is detected successfully, and the device appears on the PC.

However, while reading the PHY registers, I observe the following:

  • The PHY registers are accessible, and their values can be read correctly.
  • Despite this, the Link Up status (bit 2 in the Basic Mode Status Register [BMSR], address 0x0001) does not get set.

I have verified the hardware connections, PHY initialization sequence, and ensured the clock and power are stable for the DP83822. Below are the address value obtained when the read the following DP83822 PHY registers.

Register Name Register Address Description Value Read
DP83822_BCR 0x0000U //Basic Mode Control Register 0x3100
DP83822_BSR 0x0001U //Basic Mode Status Register 0x786D
DP83822_PHYI1R 0x0002U //PHY Identifier Register #1 0x2000
DP83822_PHYI2R 0x0003U //PHY Identifier Register #2 0xA240
DP83822_ANAR 0x0004U //Auto-Negotiation Advertisement Register 0x01E1
DP83822_ANLPAR 0x0005U //Auto-Negotiation Link Partner Ability Register 0xCDE1
DP83822_ANER 0x0006U //Auto-Negotiation Expansion Register 0x000F
DP83822_ANNPTR 0x0007U //Auto-Negotiation Next Page Register 0x2001
DP83822_ANLNPTR 0x0008U //Auto-Negotiation Link Partner Ability Next Pag 0x4B9B
DP83822_CR1 0x0009U //Control Register #1 0x0000
DP83822_CR2 0x000AU //Control Register #2 0x0100
DP83822_CR3 0x000BU //Control Register #3 0x1000
DP83822_REGCR 0x000DU //Register Control Register 0x0000
DP83822_ADDAR 0x000EU //Data Register 0x0000
DP83822_FLDS 0x000FU // Fast Link Down Status Register 0x0000
DP83822_PHYSTS 0x0010U //PHY Status Register 0x4015
DP83822_PHYSCR 0x0011U //PHY Specific Control Register 0x0108
DP83822_RCSR 0x0017U //RMII and Status Register 0x0065
DP83822_PHYCR 0x0019U // PHY Control Register 0x8C21
DP83822_PHYRCR 0x001FU // PHY Reset Control Register 0x0000

Could you please provide any guidance on what might be causing this issue? Are there any specific initialization steps, configuration registers, or debug methods recommended to troubleshoot the Link Up status in the DP83822 and establish data transmission.

Regards,

Srijan

  • 0
    TI__Expert 6465 points

    Hi Srijan,

    Happy to assist with your query. According to the register dump provided, bit 2 of 0x0001 is being set. We can read the value as 786D. D converted to binary yields 1101, which bit 2, the second most significant bit, is set correctly as 1 for an established link. 

    Is this behavior not what you expected from the application?

    best,

    Vivaan

  • 0 in reply to Vivaan Jaiswal
    Prodigy 20 points

    Hi Vivaan,

    Yes, Thank you,I have verified it. Link has been established. However, I am facing a new issue:

    • The DHCP server is not assigning an IP address to the device.
    • I am using the tftpd application to verify the DHCP server status and check for any DHCP requests from the device, but none seem to be detected.

    Is there any specific PHY configuration or  Ethernet stack setting(MAC Address) that might be needed for  DHCP packet transmission or reception?

    Regards,

    Srijan

  • 0 in reply to Srijan Ail
    TI__Expert 6465 points

    Hi Srijan, 

    There isn't any specific setting/configuration to enable DHCP packets. From your description, it seems to be a software/system level issue. I believe the PHY MDI line is functioning as expected. 

    As a sanity check, we can try running a reverse loopback test on the PHY using register 0x16 bit 4. If we send any packets on the PC side, the packets should be routed back to the PC. This test would validate the MDI path.

    Best,

    Vivaan