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.

AM6422: r5f1-0 GPTP CPSW LWIP

Part Number: AM6422

Hello,

    Regarding the content we mentioned earlier, we haven't seen any response indicating that the issue has been resolved, so I have resubmitted it. Do you have any further conclusions on the problem we are currently experiencing? 

    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1646461/am6422-r5f1-0-gptp-cpsw-lwip?ReplyFilter=Answers&ReplySortBy=Answers&ReplySortOrder=Descending

  • Hi,

    GPTP_QUICKSYNC is used only in quicksync examples. This is not used in gptp_cpsw_app. GPTP_MASTER is a boolean, but only talks about master mode. If GPTP_MASTER is set, it will configure as master on that network. If GPTP_SLAVE is configured, it will act as slave. This configuration is only used in GPTP quicksync examples. So, if you are using the gptp_cpsw_app example, you wouldn't be using these configurations anyways.

    In our setup, we were not able to observe such in the gPTP in our testing. Our test setup is staying within 200ns drift. Can you please check the output from the TS_SYNC_OUT pin so that we can confirm if the gptp sync is functional or not? If the sync itself is drifting, then it represents a larger issue. The gptp corrections apply along with CPTS adjustments. So, it is unlikely that the application in sync, but the genf is drifting, considering you applied the patch recommended in earlier threads. 

    Please let us know your observation so that we can confirm the behavior.

    Thanks and regards,
    Teja.

  • Hello,

        We are using the R5F1-0 core. Have you verified this functionality with this core before? In addition, the crystal oscillator parameter we use has a holdover accuracy of 10ppm, which follows the same principle as the development board. Due to our hardware design, the TS_SYNC_OUT pin is not accessible, so we cannot confirm via that method. Is there any other way to verify the process you described?

  • Hello,

        We would like to obtain the PDF file of the development board hardware schematic from you. Next, we plan to compare the schematic provided by you with our actual design to see if there are any differences in hardware design.

  • Hello,

    You can find the design documents HERE.

    Are none of the TS_SYNC_OUT pins exposed? We would like to understand the root cause of the problem. And understanding if the CPTS is in sync is important for this understanding. If the sync out pins are not available, we would have to rely on the gmdiff prints to observe the SW defined diff

    Please let us know your findings. Please make sure your design is fully inline with AM64x PROC-C variant, since timing related issues were introduced in later revisions.

    Thanks and regards,
    Teja.

  • Hello,

        The schematic we referred to for our design is PROC101C(004)_SCH.pdf, as shown in the attached screenshot. We now have a point of concern: our actual design is for Gigabit Ethernet, but we are using 100 Mbps. In this case, will it affect the time synchronization accuracy? Do you have any test data for 100 Mbps on your side? From the printed logs, the calculated time difference exceeds 10 µs after running for more than 12 hours. We have added a calculation for this maximum value in the code that computes the time difference.

  • Hi,

    We haven't tested long runs with 100mbps setup in our runs. We can check this and update you on the results. Please expect some delay since I am going to be away from office for next 2 days. We will be able to provide the observations on Wednesday 

    Thanks and regards,

    Teja.

  • Hello,

        I am waiting your reply,Is anyting news?

  • Hello,

        I want to know something about the question,Is anything news?