• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 33 subscribers
  • Views 514 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.

DP83867IR: Issues with default values of registers

Patricia Arribas Guerrero
Prodigy 10 points

Part Number: DP83867IR
Other Parts Discussed in Thread: USB-2-MDIO

Hello,

My team and I have implemented a DP83867IR in our design, and we have two duplicate boards. The idea is to output data through Ethernet using RGMII interface.  For the first board, everything has worked out well, and the data reaches the computer. However, the problem has come with the second board.

The timing of the transferences was clearly off, and using the USB-2-MDIO board, we have discovered that the register's 0x0032 (RGMIICTL) value is 00D3, when it should be 00D0 (as the datasheet indicates this is the default). We are sure we have not accessed this register, and every time we power the board, it has this 'default' value. We have checked the powering sequence, and everything seems to be just fine.

Is there any reason for this behaviour? Is there any way to set it to 00D0 without having to access the register using MDIO pins?

Thanks!

Patricia.

  • 0
    TI__Expert 3595 points

    Hi Patricia,

    Sorry to hear this issue came up. I looked into the RGMII clock differences, and was wondering if you could use USB-2-MDIO to tell me what register 0x6F is on both boards? It should hold the status of the RGMII skew straps. I looked at the datasheet as well and saw that the bits you noted are not listed as "strap set" bits. I will connect with design to verify if there is a relation between the straps and those bits that was omitted from the datasheet!

    Thanks,

    Lysny

  • 0 in reply to Lysny Woodahl
    Prodigy 10 points

    Hi Lysny,

    I also checked that register when trying to figure out the problem and it is set to value 0100 on both boards. Actually, I don't understand why the bit 8 is set to '1' when the datasheet says that it is reserved, its default value is '0' and read only. Does this make sense?

    In the other hand, we are using the PAP package, so, if I understood it correctly, there is no way of configuring the skews with straps (this can only be done with the RGZ package), and the only way is to access those registers.This is the reason why one board did work and the other didn't, as we were not taking into account the delay that was being introduced when the register 0x32 was 00D3 because we thought nothing had been changed.

    Thanks for your reply.

    Patricia.

  • 0
    TI__Expert 3595 points

    Hi Patricia,

    Okay, thanks for the clarification and information. I'll look into this a little more and get back to you tomorrow, if that's okay? We'll try to figure out what possible straps or sources could be causing the 0xD3.

    And, without revealing more than I'm allowed to, I can say that the reserved bit being 1 should not cause any issues with the system. If you used all the default strap settings, I would assume that bit would read the default instead of 1. I will also double check on this too, though!

    Thanks,

    Lysny

  • 0 in reply to Lysny Woodahl
    Prodigy 10 points

    Hi Lynsy,

    Is there any new information about the source of the 0xD3?

    About the bit being '1', we are only using the straps to disable the output clock and to enable the Autonegotiation. I assume this would not affect any other bit.

    Thanks,

    Patricia.

  • 0 in reply to Patricia Arribas Guerrero
    TI__Expert 3595 points

    Hi Patricia,

    I am still waiting on a response from our team in India. I just pinged them again this morning, but because of the time difference I definitely won't hear back until at least this evening.

    And, thank you for the strap information. I will pass that on to them as well!

    Thanks,
    Lysny

  • 0 in reply to Lysny Woodahl
    Prodigy 10 points

    Hi!

    Ok, there is no rush! I was just checking in as I didn't answer right away the other day.

    Thank you so much,

    Patricia.

  • +1 in reply to Patricia Arribas Guerrero
    TI__Expert 3595 points

    Hi Patricia,

    So I heard back from design, and they are saying there seems to be a mismatch between design data and the datasheet. I unfortunately don't have access to an 867 PAP EVM at the moment, so I can't test this, but it appears that those straps are actually present in the PAP chip as they are in the NGZ version. Is it possible to add a resistor strap to the design that would give us 0xD0 instead of 0xD3?

    This doesn't necessarily explain why one chip is not having this issue and the other isn't, but if the strap solves this, I will bring it up to those in charge of versions and quality!

    Thanks,
    Lysny

  • 0 in reply to Lysny Woodahl
    Prodigy 10 points

    Hi Lysny,

    So fortunately it was possible to add a resistor strap in our design, and... it worked!! We were able to get that desired 0xD0!! So the conclussion is that the PAP chip has those straps available, although the datasheet does not incude this information, or at least that is what I understood. Anyway, finally both boards are working.   

    Thank you so much for everything!

    Patricia.

  • 0 in reply to Patricia Arribas Guerrero
    Prodigy 10 points

    Hi again,

    I wanted to add some information about the straps I added to the design.

    For the TX: Looking at Table 8 'RGZ RGMII Trasmit Clock Skew Details'  my target was to achieve a delay of 0ns, so I chose mode 5. To achieve this mode, I had to put a resistor strap in LED_1 to choose mode 2 (RGMII Clock Skew TX[2]='1'). The result was the following:

    Register 0032: 0x00D1 (as RX has not been modified)

    Register 0086: 0x00F7. This means that the delay is 4ns(?) This means that table 8 may be wrong, as it states that it will be 0ns but that does not seem posible in table 53 'RGMII Delay Control Register (0086)'

    However, this has no impact in my design, as 0032 indicates that RGMII TX clock is aligned to data. But my question is, how is it possible by just adding the straps in LED_1? This straps should be configuring the amount of delay between data and clock, but in my case is configuring if the delay exists or not... I think this behavoiur is strange.

    Anyway, as I said before it is working. Thanks again!

    Patricia.

  • 0 in reply to Patricia Arribas Guerrero
    TI__Expert 3595 points

    Hi Patricia,

    Glad to hear you got your design working! 

    Hmm, that does sound strange. I'm not sure of all the details that make the NGZ and PAP models different, so I can't necessarily say why this is happening, but I will relay your findings to the design team and make sure that this information is looked into and updated in the next datasheet update!

    Thank you again for letting me know! It helps us prevent others from running into the same bugs! :)

    Lysny