• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 32 subscribers
  • Views 373 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.

AM263P4: MDIO PHY Excessive Transmissions

TollMan
Intellectual 485 points
Part Number: AM263P4
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

I am trying to use CPSW on a custom PCB. My SysConfig project is configured to use  Port 2. The PHY is bootstrapped for ADDR == 2. I implemented a BSP to facilitate binding the driver to this port. However, I see what appears to be MDIO read errors. In EnetPhy_getId(), values read from PHY_PHYIDR1, and  PHY_PHYIDR2 seen here:

… do not match the expected values in the datasheet, seen here:

Upon probing the MDIO bus with an oscilloscope, I see that the MDIO bus has what looks like reasonable signal integrity, but the bus is very ‘chatty’. Every ~80us I see what looks like a repeated-identical transaction. This persists when the processor is halted at a breakpoint. Also, without parsing the transaction, it looks reasonably like it conforms to the frame format defined in:

AM263Px Sitara Microcontrollers Technical Reference Manual (spruj55), Section:3.2.1.4.9.1 MDIO Frame Formats,

 

One transaction is captured in these two images:

As mentioned above, there will be another identical transaction in less than 80us.

Reading spruj55, section 13.2.1.4.9.2 MDIO Functional Description, seen here:

… prompted me to attempt to read the CPSW_MDIO_USER_ACCESS_REG_k GO.

 

Rationale: Hardware must be initiating the transactions I see on the oscilloscope.

 

Reading:

  AM263Px Sitara Microcontrollers Register Addendum (spruj57)

seen here:

… and here:

 

… prompted me to use the following Watch Expressions:

  *((uint32_t *) 0x52820F80)

  *((uint32_t *) 0x52820F80)

 

However, the register values I read are not consistent with the behavior. I read zero for both CPSW_MDIO_USER_ACCESS_REG_k as seen here:

I expected the GO bit to be set in at least one of the two registers.

1)

Are my watch expressions correct?

 

2)

Are my assumptions about the ‘chatty MDIO’ behavior and its relationship to CPSW_MDIO_USER_ACCESS_REG_k GO bit correct?

  • 0
    TI__Prodigy 540 points

    Hi,

    Apologies for the delay, I am on it and will get back to you soon. Can you please tell us which example is used for this.

    Thanks, and regards,
    Narayanarao Puli

  • 0 in reply to Narayanarao Puli
    Intellectual 485 points

    Hi Narayanarao,

    Thanks for the update.

    Since the original post, I have a better understanding of MDIO. I have a logic analyzer connected to analyze the traffic. 

    1)

    The Sitara seems to be ‘scanning’ each PHY address. i.e. It is doing a read transaction for register 0x01 to each possible PHY address. These seem to be the bulk of the ‘chatty’ transactions I referred to previously.

    Is this accurate?

    2)

    Once, a PHY responds to this read the PHY driver then:

    • reads the ID registers
    • binds the driver if one matches
    • configures the PHY though MDIO if the bootstraps have not done so already
    • attempts to detect a link by polling through MDIO

    Is this accurate?

    3)

    I have a question about the MDIO_CLK

    This transaction shows a valid MDIO read. It seems that the Data (transmitted by the PHY) is sampled on the falling edge of the CLK whereas the pre-TA data  (transmitted by the Sitara) is sampled on the rising edge.

    Is this how the MDIO protocol is specified?

    Regards,

    Tollman

  • +1 in reply to TollMan
    TI__Prodigy 540 points

    Hi Tollman,

    TollMan said:
    The Sitara seems to be ‘scanning’ each PHY address. i.e. It is doing a read transaction for register 0x01 to each possible PHY address. These seem to be the bulk of the ‘chatty’ transactions I referred to previously.

    This is correct. First, we will give the PHY address, it will scan for the PHYs with the respective address. Once the right PHY is detected we are ready to do the transactions.

    TollMan said:

    Once, a PHY responds to this read the PHY driver then:

    • reads the ID registers
    • binds the driver if one matches
    • configures the PHY though MDIO if the bootstraps have not done so already
    • attempts to detect a link by polling through MDIO

    Is this accurate?

    The flow is correct.  This is how actually the PHY configured.

    TollMan said:
    This transaction shows a valid MDIO read. It seems that the Data (transmitted by the PHY) is sampled on the falling edge of the CLK whereas the pre-TA data  (transmitted by the Sitara) is sampled on the rising edge.

    As per device spec(AM263P), MDIO data should be sampled at the raising edge. And Even in the PHY(DP83826) datasheet, data is sampled at the raising edge.

    Feel free to ask if you have any queries.

    Thanks and Regards,

    Narayanarao Puli