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.

DP83822I: Timing issue on RMII in combination with the ESP32

Part Number: DP83822I

Tool/software:

Hi,

In a current design I use the DP83822I physical in combination with the ESP32-MINI-1-N4. The PHY communicateds with the ESP32 over RMII.
However, on my proto types the RMII seems to have timing issues with the 50MHz clock and the TX and/or RX lines. 
When I ping the IP adress the device occasionally pings correctly and occasionally gets a packet loss.
For each proto the occurence of packet losses differs.
One may never returns packet losses and the other always returns packet losses. 
When I measure the timing on a scope the timing seems correct. See attached figures.
For receiving the setup time is 13ns and the hold is 7ns, and for transmission the setup is 10ns and the hold is 10ns aswell.
These values comply with the values provided in the data sheet.
However the ESP32 technical reference manual introduses a input and output delay. These delays might be the cause of the issue, since they differ per module, which can make the timing critical.
Is there a way in software to add extra delay via registers on the 50MHz RMII clock or is it required to add a serial clock buffer to the 50MHz?

  • Hello,

    There isn't a bunch of maneuverability on RMII setup/hold. The only register would be Reg 0x17[8]. However, this would only adjust the TX bus of the RMII.

    If this doesn't work, it would require a board spin to correct for the delays imposed by the ESP32.

    Sincerely,

    Gerome

  • Hello Gerome,

    Thanks for your reply.
    What is exactly shifted by register 0x17[8]?
    Does this shift the clock internally in the PHY only, or does it shift the output clock aswell.
    And is it possible when the PHY is in RMII master mode, or only when in RMII slave mode?
    TI PHY operrates in RMII master mode in our design. 
    So I am unsure if a clock shift is possible within the PHY, since it is generated by the chip it self.
    When we set the bit to 1, we do not measure a shift in the clock on GPIO3 [pin 1].

    Best regards,
    Kane

  • Hello Kane,

    This bit is only for RMII slave where it would internally delay the 50MHz coming in, so it appears this workaround is not viable. There are no other available workaround for this from a PHY side. I would recommend checking the MAC if there is a way to alter the delays. Else, a board spin will be required to correct for the setup/hold time.

    Sincerely,

    Gerome

  • Hello Gerome,

    After some further investigation, I have found that the problem arises from the receiving end of the PHY.
    When the packets are invalid, the RX_ER line is triggering, indicating incorrect data from the MAC. 
    When the RX_ER is triggered no data is send on the RX_D0 line.

    Data on TX_D0 is still send from the MAC to the PHY.

    In this design two test pads for GND and 50MHz are provided.
    And when I hold my finger on both pads the RX_ER is not triggerd and data is send on the RX_D0 line. 
    This event pushes more towards timing issues, since I add capacitance with my finger.

    Only the reason for RX_ER to trigger is not so clear. Does this line get triggered by unreadable data (possibly caused by timing) from the MAC to the PHY (TX_D) or from unreadable data from the PHY to the MAC (RX_D).
    Or what other causes could the reason be for RX_ER to trigger?

    Best Regards,
    Kane

  • Hi Gerome,

    We are also looking in to using the RMII slave mode, and have the ESP32 send a 50MHz clock. 
    In most reference designs we see usage of a clock inverter (180 degrees).
    Could we also use the clock shift for this and by how much is the clock shifted with this register?

  • Hi Kane,

    RX_ER would only trigger if the PHY senses a bad packet on the MDI. This could indicate issues on the MDI instead of the MII. Could you please provide a few reads of register 0x15 when DUT is powered on but packet errors have already occurred?

    Regarding slave mode operation, the use of an inverter is unseen from my experience, but in theory, it could help offset any setup/hold issues if done correctly. Do know that more calculations may need to be done on the TX lines as it would be pretty straight forward doing setup/hold time on the RX lines. The TX lines may need to get readjusted as they will be sent on the incoming XI clock, so this in theory would be phase delayed by 180 degrees too relative to normal operation.

    Sincerely,

    Gerome

  • Hi Gerome,

    Currently having the Esp32 as RMII clock master and the DP83822I as RMII clock slave, with the clock delay seems to work.
    We still need to do the propper calculation on timing.
    Therefor I would like to know how many ns the clock delay adds to the clock signal, from your earlier message.
    Is it the same as for RGMII where 3.5ns is added to the clock?

  • Hello,

    This RMII slave internal shift is actually 4ns internally in the PHY.

    Sincerely,

    Gerome

  • Hello Gerome,

    Using an external oscillator for both the Esp32 and PHY seem to work. This option is recommended over using the ESP32 as clock master by espressif.
    Also with timing calculations. the timing seems to match.
    However I was still wondering with the clock shift of the DP83822I. 
    Is the clock shifted forward or backwards in time?

    Best regards,
    Kane

  • Hi Kane,

    The clock would be internally delayed in the DP83822I. To answer your question, it would equivalently be shifted backwards in time.

    Sincerely,

    Gerome