• State
  • Locked Locked
  • Replies 13 replies
  • Subscribers 33 subscribers
  • Views 484 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.

DP83848YB: TD problem

user4125449
Intellectual 330 points
Part Number: DP83848YB

Tool/software:

We have a custom board based on the STM32H7 and a DP83848 as PHY. 

We can configure the PHY without problems, all status and configuration register are as expected, the PHY reacts on changes of link speed etc. 

PHY loopback mode is working too, we can receive the data we sent. 

The Link is established when connected to an Ethernet partner (PC) and we can receive data from Ethernet partner.

When sending data (without loopback mode) to the ethernet partner we see the RJ45 LED toggling and we can see (a soft) toggling of the RJ45 LED of the partner. But no data is received, no logs in Wireshark and when connecting a uC as partner and evaluating low level register of the Ethernet driver we receive nothing.

We did also a hardware loopback, same results, no signal received. As cross check we used a STMF6 eval board to verify the test setup, with the eval board all is working as expected.

We did a bunch of measurements but don't see anything suspicious in the TD path. Even after the 74990101210 the signals seems to be at least physically correct.

Any ideas about that? Why do we have Link status when TD is not working correctly.? Any hint or tip would be very appreciated.

Ethernet_PHY_and_RJ45.pdf

  • 0
    TI__Expert 6395 points

    Hi, 

    user4125449 said:
    STMF6 eval board to verify the test setup

    Was the STMF6 used to replace the STM32H7 or the Ethernet Partner PC? 

    Can you also share some more details about the loopback tests performed. What kind of loopbacks were used and in which device configuration? 

    Regards,

    Vivaan

  • 0 in reply to Vivaan Jaiswal
    Intellectual 330 points

    Hi Vivaan,

    thanks for your support, please have a look on this video:

    https://drive.google.com/file/d/1GpOw4ss17hR5SJEbwA5PAsicqrQ3OCOV/view?usp=sharing

    With the loopback cable setup of the video I don't receive any messages. The same loopback cable is working for my STM32F6 setup.

    When activating the loopback bit on my custom board (STM32H7, DP83848) I can receive messages.

    But the problem is the TD path, when connecting my board to e.g. network I am receiving data but my board can't send data back in the network. Nothing to see in wireshark and when going a level deeper and when debugging with the STM32F6 as partner I see no data received at all.

    So Linkstate, Auteneg, Receiving data, ... is working but the transmission fails when the PHY is not in loopback mode.

  • 0 in reply to user4125449
    TI__Expert 6395 points

    Hi, 

    I am still having some trouble in understanding your test setups. 

    user4125449 said:
    STMF6 eval board to verify the test setup, with the eval board all is working as expected.
    user4125449 said:
    STM32F6 as partner I see no data received at all

    Is the STM32F6 replacing the Link Partner or the STM32H7 on the custom board? Or is this setup with a different PHY? When testing this new setup with the STM32F6, are you able to transmit packets to the Link Partner and receive them?

    I am just trying to understand if there is any setup, with either STM32H7 or STM32F6, that has working transmission when not in loopback.

    user4125449 said:
    activating the loopback bit

    I also wanted to add that auto-negotiation must be disabled before enabling the loopback bit to ensure that the PHY stays in the desired state. This might be a potential cause that would be good to rule out. 

    Regards,

    Vivaan

  • 0 in reply to Vivaan Jaiswal
    Intellectual 330 points

    Hi Vivaan,

    Let's set aside the F6 test setup for now and focus on my custom board (see schematic). The issue we're facing is that the PHY internal loopback mode works — data sent is successfully received by the STM32H7. However, when we connect an external loopback cable or any other Ethernet device, it stops working. The problem seems to be with the Tx path, as no data sent from my device is being received by any other connected device.

    regards

  • 0 in reply to user4125449
    TI__Expert 6395 points

    Hi, 

    The problem does seem to be the MDI transmission path. I wanted to make sure that the packet encoding is as expected. I think performing a compliance test would be a good debug step. the following is for a 100Mbps connection.

    Probing the pairs of differential outputs from the PHY should give us a waveform similar to the following 

    Note: Please disable Auto-Negotiation and force a 100Mbps connection before performing the test.

    Ideally, we want to see that the waveforms meet the specifications listed below. 

    Regards,

    Vivaan

  • 0 in reply to Vivaan Jaiswal
    Intellectual 330 points

    Hi Vivaan,

    it took some time but we did some measurements, here are measurements from the non working design:

    .RJ45 - MotionController.pdf

    For a comparison we made the same measurements with another eval board:

    RJ45 - Blue EVAL-Board.pdf

    It looks as if the main difference is when RJ45 is open. The "faulty" design has signal level only in the negative direction, the not faulty design in neg. and pos. direction (see first measurement in each pdf)

    Regards

    Matthias

  • 0 in reply to user4125449
    TI__Expert 6395 points

    Hi Matthias, 

    Glad to hear from you again! 

    Looking at the waveforms you provided, it seems like the waveform for the non working design was offset by 2V. I'm not sure if it is the waveform that is offset by 2 volts or the scope. This offset is also the reason why the signal level seems to go only in "one" direction, as labelled in the pdf provided. The signal is in-fact both positive and negative without this offset. 

    Additionally, would you be able to provide the schematic for the MDI path for the working design for comparison and the signals received by the PHY? If the signal is being pulled high, and it is not a scope offset, it could be beneficial debug to compare the two.

    I also noticed that the schematic design shared earlier has a few caps missing or with different values than the one recommended. 

    There should be 4 capacitors used, 2 for the PHY side and 2 for the center tap of the magnetics used. In the schematic provided, I only see 2, one of which has the incorrect value of 10uF.

    Regards,

    Vivaan

  • 0 in reply to Vivaan Jaiswal
    Intellectual 330 points

    That's the schematic of the board with working Ethernet:

  • 0 in reply to user4125449
    TI__Expert 6395 points

    Hi Matthias, 

    I thought that the other board was also using a TI PHY. Sorry about the confusion. I can go ahead and use reference designs for the comparison instead. 

    Looking forward to hearing from you about the DC offset and the receive channel waveforms

    Regards,

    Vivaan

  • 0
    Intellectual 330 points

    I've made some debugging mistake, there is data received in Wireshark, but it's corrupted:

    e.g., when sending 

    0xFF, 0xFF, 0xFF, 0xFF, 0xFF , 0xFF , 0x00 , 0x01 , 0x02 , 0x03 , 0x04 , 0x05 , 0x90 , 0x00

    we receive on the Pc (wireshark dump):

    0000 ff ff ff ff ff ff 07 0a 0f 14 15 1e d0 02 00 00
    0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0030 00 00 00 00 00 00 00 00 00 00 00 00


    But since the data is received in Wireshark, we know that the physical layer CRC must be correct, so it can't be a signal level problem or anything like that (IMHO).

    But I also know that the data I am sending to the PHY is correct because when I enable loopback mode the data returned is correct.

    Rx data:  ffffffffffff123456900

    => This means that after the PYH the data is changed but the CRC is still valid (doesn't make much sense either :-( ).

  • 0 in reply to user4125449
    TI__Expert 6395 points

    Hi, 

    Glad to hear that the PHY is at least able to transmit data now.

    Have you tried using the external wire loopback after fixing the transmit issue?

    This will help us narrow down where the packets are being corrupted. 

    Regards,

    Vivaan

  • 0 in reply to Vivaan Jaiswal
    Intellectual 330 points

    Hi Vivaan,

    unfortunately that's not really a progress, the only thing that has changed is that I have a better look at the Wireshark logs, but we have not changed anything else.  I can view data now in Wireshark (that helps debugging) but we did not change anything else.

    (Note: We tested a new RJ45 component on one board but same behavior)

    Loopback mode with a loopback cable is not working, PHY internal loopback test is working. 

    So it looks as if the the data is sent to the PHY correctly but when received in wireshark the data is corrupted. And not every frame is received. 

    e.g. here the source address:

    Source: 03:80:e7:03:00:00 (03:80:e7:03:00:00)

    should be

    00:80:e7:00:00:00

    but I do not see any pattern here.

  • 0 in reply to user4125449
    TI__Expert 6395 points

    Hi, 

    It looks like the data is being sent to the PHY correctly, but when being transmitted it is being corrupted somehow. 

    Given that the PHY internal loopback test is successful, I think we should run compliance tests to make sure that the output of the PHY is meeting the IEEE standard requirements. The document below should have more detailed information on how to conduct these tests. 

    https://www.ti.com/lit/an/snla266a/snla266a.pdf? 

    These tests can help us verify that all the parameters such as rise time, jitter, overshoot, etc and may point us towards the cause of the issue. 

    Regards,

    Vivaan