• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 3386 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Problems reading DP83822 register 0x0001 Basic Mode Status Register

Antonio Mondragon71
Prodigy 100 points
Other Parts Discussed in Thread: USB-2-MDIO

When trying to read register 0x0001 Basic Mode Status Register through MDIO the result is 0x7849 which denotes that the link and auto-negotiation bits are off. The LEDs show that the link and auto-negotiation have been completed. If in the software the values read are override by the expected value 0x786D then the expected result is observed which is a working http server, and thus the ethernet phy working correctly.

By using the launchpad and the USB-2-MDIO software and a MSP-430 launchpad, I am able to read the correct values. The difference is that the launchpad reads at a speed of 200 Hz while the board we are using reads at 2 MHz. The problem was thought to be due to wiring the MAC to the PHY externally. To our surprise, the same issue appeared on the design on the PCB.

By using a different external board with the same processor but on a different running MDIO at 2 MHz, the correct values are read.

Is this an intermittent failure due to some timing issues? Does not make sense to have the external signal indicate link and auto-negotiation and not reflected on the register corresponding bits.

  • 0
    TI__Mastermind 18425 points
    Hi Antonio,

    It is curious that the PHY is reading a wrong value. It might not be anything realted to timing of MDIO. As per my understanding, you have a processor+PHY system which shows incorrect BMSR value. But when the same PHY is disconnected from the processor and connected to a MSP430 launchpad, you see the correct BMSR value.
    On the processor+PHY system, can you try reading BMSR multiple times after the LINK LED has turned on?
    Are other registers being read correctly? Can you read registers 0x02, 0x03 and 0x10?
    Can you try resetting the PHY using register 0x1f. Write 0x8000 to reset the PHY along with its registers.

    -Regards,
    Aniruddha
  • 0 in reply to Aniruddha Khadye
    Prodigy 100 points

    Aniruddha,

    As a matter of fact al reads are being performed after the lights are steady, this is an example of reading the BMSR continuously to poll for the link bit with no success. The following image shows the continuous access to register 0x0001. When in software the value is override by setting the Link and Auto-Negotiation bits then the http server works as expected.

    I will try your suggestion of resetting PHY with register 0x1F and post the results.

    Currently the software resets the PHY by writing 0x8000 to register 0x0000 BMCR.

  • 0 in reply to Antonio Mondragon71
    Prodigy 100 points

    Anirudda,

    Sorry for the late reply back on your suggestions.

    The status of the problem has not changed since last post. Here are the results of writing 0x8000 to 0x1F and then reading )x02, 0x03 and 0x10.

    We still read the value 0x7849 which indicates no link and no auto-negotiation complete. Values need to be override for web server to work.

    Please advice, the LEDs show link and activity and the ethernet is uo and running after overriding those values.

  • 0 in reply to Antonio Mondragon71
    TI__Mastermind 23675 points
    Hi Antonio,

    There is no issue with the DP83822.
    The reason why you are having issue is because register 0x01 always requires two reads.
    This bit in the register is a LL (latch-low). Thus two reads are required to get the correct real-time status.

    Typically double reads are inate to the firmware. Please ensure your firmware does a double read.

    Kind regards,
    Ross
  • 0 in reply to Ross Pimentel
    Prodigy 100 points

    Ross,

    Thank you for the quick answer!

    I will try it tomorrow.

    Would you please point me to the documentation that refers to this issue of double reading a register? Since all other registers seem to be read correctly.

    The documentation refers to LH and LL, but no reference to the need to double read a register.

    In order to work I modified the HAL provided by the manufacturer since the chip is compliant with the following as stated in the datasheet:

    The Serial Management Interface provides access to the DP83822 internal register space for status information and configuration. The SMI is compatible with IEEE 802.3 clause 22 and clause 45. The implemented register set consists of the registers required by the IEEE 802.3 plus several others to provide additional visibility and controllability of the DP83822.

    The HAL being used was working correctly with a previous generation TI ETH PHY, that is why this has been an unexpected behavior.

    Best Regards

    Antonio

  • 0 in reply to Antonio Mondragon71
    TI__Mastermind 23675 points
    Hi Antonio,

    Interesting... There might be some different behavior from PHY to PHY, but the register is a LL and it is not a SC (Self Clear). This would mean that the link would basically need to established before the register is loaded (unlikely). Regardless though, double read on BMSR is common practice and you will see it in most PHY drivers withing the Linux Kernel. Please let me know if you keep running into issues!

    Kind regards,
    Ross
  • 0 in reply to Ross Pimentel
    Prodigy 100 points

    Ross,

    The HAL code continuously polls for BMSR and that reads this register over and over to look for the required bits.

    I added the code to explicitly read BMSR twice before comparing the link and auto-negotiation to continue the starting up of the link.

    The interesting part is that the PHY LEDs show connection established and everything else works.

    Reading BMSR twice does not make a difference.

    The clock speed is 2 MHz.

    Any other suggestion?

  • 0 in reply to Antonio Mondragon71
    TI__Mastermind 23675 points

    Hi Antonio,

    It sounds like you are reading before link and auto-negotiation is complete.

    Have you tried waiting longer?

    Kind regards,

    Ross

  • 0 in reply to Ross Pimentel
    Prodigy 100 points

    The values are read correctly after 2.23 Seconds by the HAL continuously polling BMSR.

    Seems that the link and auto-negotiation take that long.

    Thank you for your response!

  • 0 in reply to Antonio Mondragon71
    TI__Mastermind 23675 points

    Hi Antonio,

    Glad this is resolved.

    Link pulses (what are used for auto-negotiation) do not appear for about 1.5seconds after power-up or reset. It also takes around 1-3 seconds to link so this aligns perfectly with the expected case.

    Sorry I did not think about this earlier. It explains why you see no issue when the MDC is lengthened.

    Kind regards,

    Ross