• State Answer Suggested
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 879 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.

DP83630 First Time Startup & Debug

Doug Price
Prodigy 30 points
Other Parts Discussed in Thread: DP83630

I have a known good port from the main system board driving a DP83630 that is hard wired into the DP83630 on my peripheral module, this is the unit I'm trying to get running but asside from the device specification I can find little documentation for first time users.

The system board, running Linuz, recognizes and operates commercial modules that plug into the the peripheral connector but it's not detecting my module. So my problem is verifying the physical link between these two DP83630's.

I can read/write the DP83630 registers and have been combing the bit settings but as a first time user I'm not familliar with many of the settings.

When I set the BMCR register LOOP_BACK bit  and the PHYCR register BIST_START, my MCU begins to recieve frames. I also noticed when I do this the BMSR LINK_STATUS bit becomes active.

The basic configuration is 100mbps, full duplex using an RMII inteface. My startup register values are shown below.

How do I debug the physical interface?

Thanks

Doug

  00, PHY_REG_BMCR      2100

  01, PHY_REG_BMSR      78D9

  02, PHY_REG_ID_R1     2000

  03, PHY_REG_ID_R2     5CE1

  04, PHY_REG_ANAR      0101

  05, PHY_REG_ANLPAR    00

  06, PHY_REG_ANER      04

  07, PHY_REG_ANNPTR    2001

  10, PHY_REG_PHYSTS    44

  11, PHY_REG_MICR      00

  12, PHY_REG_MISR      00

  13, PHY_REG_PAGESEL   00

  14, PHY_REG_FCSCR     00

  15, PHY_REG_RECR      00

  16, PHY_REG_PCSR      014B

  17, PHY_REG_RBR       21

  18, PHY_REG_LEDCR     00

  19, PHY_REG_CR        21

  1A, PHY_REG_10BTSCR   0904

  1B, PHY_REG_CDCTRL1   00

  1C, PHY_REG_CR2       02

  1D, PHY_REG_EDCR      6011

  1F, PHY_REG_PCFCR     00

 

 

 

 

  • 0
    Prodigy 30 points
    I stumbled upon the answer to my immeadiate question. The loss of signal pin back to the sending PHY was incorrect.

    The bigger issue is the lack of information on test and debugging processes related to the PHY.

    Nice part, crap for support.
  • 0 in reply to Doug Price
    TI__Mastermind 31600 points
    Doug,

    It sounds like you have had some success with your initial debug. Your approach of checking the registers and utilizing the BIST and loopback functionality of the PHY is a good one.

    My first goal during board bring up is to establish link. It sounds like you have succeeded in accomplishing this goal, correct? The two key registers for confirming link are BMCR (reg. addr. 0x00) and PHYSTS (reg. addr. 0x10). Note that many of the bits in these registers (including the link status bits) latch their initial status so it is important to read the registers twice to get the current status.

    Once link is established, I focus on packet traffic. You noted that you had some success using BIST with loopback mode. Do you also have the ability to transmit packets from your MAC?

    Patrick
  • 0 in reply to Patrick OFarrell
    Prodigy 30 points

    Patrick

    Thanks for the tip on reading registers twice - this is the type of little stuff that's hard to discover.

    With the Loss Of Signal issue discovered I've been able to recieve frames.

    My next step will be to toss the frames back to the transmitting. I'm guessing (haven't gone looking yet, and this is my grump, I can't find any low level app notes) that there's a loop back mode taking media Rx frames and sending them back onto the media Tx? That would leave my MAC and processor out of the equasion.

    Then I'll add a firmware loopback mode, sending new frames, adding Pause frame processing, and building from there.

    But I'm just groping for information - how do I effectively use BIST? There is a 9 & 15 bit mode, what's the impact? I'm constructing an ethernet/serial convertor, so it's paired with a similar module at the other end. Can I take the BIST frames generated on one PHY, send them across my serial link (maybe back again) and test the content to verify the accuracy/dependability of my link? How? What's the data rate for BIST frames or is it just one big lump of data?

    I get the impression people don't generally ask these kinds of question or figure, if packets are being recieve then all must be good.

    Any little bones you can toss would be greatly appreciate.

    Doug

     

  • 0 in reply to Doug Price
    TI__Mastermind 31600 points
    Doug,

    You are right. PMD loopback can be configured in the RMII and Bypass Register (RBR), Address 0x17, to loop received packets back to transmit.

    You can use BIST if your link is between two DP836x0 devices. The BIST engine generates a pseudorandom bit stream. The 9 or 15 mode just selects the depth of the random bits. For most applications, the default of PSR9 is fine. The BIST engine will just churn out the bit stream separated by an interframe gap until you disable it.

    To use BIST, you just establish a link between the two devices, start BIST using the PHY Control Register (PHYCR), Address 0x19, and then poll the BIST Test Status bit in that same register to confirm that everything is OK.

    Patrick