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

AM6422: r5f1-0 GPTP CPSW LWIP

Wendy
Intellectual 840 points

Part Number: AM6422

Hello,

    We are currently testing on the SDK11.0 version using the gptp_lwip_cpsw_am64x-evm_r5fss0-0_freertos_ti-arm-clang example. Due to requirement changes, we need to use two real-time R5F cores, so we migrated the example from R5F0-0 to R5F1-0. After modifying the related configurations, ethernet works fine. However, during testing we encountered some issues and would like to consult you.

    When using R5F0-0 with three cascaded terminals (e.g., A connected to B, B connected to C), where A is the master clock and B/C are slaves, the printed time difference values for B and C are within the expected range, as shown in the figure below. But when using R5F1-0, B remains relatively stable and its gmsync value is basically 2, while C always stays at 1, and the computed time difference jumps significantly, accompanied by some warning messages.

    The entire Ethernet cabling remains unchanged, and all other hardware conditions are also the same. In actual use, are the two Ethernet ports of the corresponding CPSW self-adaptive when connecting? Does the port to which the cable is connected determine whether to act as master or slave based on the clock priority of the messages received on that port? If the network cable is dynamically adjusted during operation, can it also be automatically recognized?

image.png

image.png
 
  • 0
    TI__Genius 9060 points

    Hi,

    I hope you have consumed the changes which were communicated with you in a previous E2E for cascading multiple boards. We have not observed the unstable to stable behaviour in our test setup. I will try to reproduce this to analyse the issue further.

    Wendy said:
    are the two Ethernet ports of the corresponding CPSW self-adaptive when connecting?

    Yes, they are adaptive. It will run the BMCA and initialise the time corrections again to achieve sync.

    Wendy said:
    Does the port to which the cable is connected determine whether to act as master or slave based on the clock priority of the messages received on that port?

    No, the port number doesn't decide the master/slave role. Both the ports are derived from the same parent clock and will not change within the board. Master role will be assumed based on the one closest to actual frequency. You can find more details about BMCA from IEEE specifications.

    Please let us know if you have further queries.

    Thanks and regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Intellectual 840 points

    Hello，

        We have resolved the previous issue regarding multiple cascades. However, the current problem is that when multiple stages are cascaded, only the first stage can perform time synchronization normally; the other stages remain stuck in the synchronization process, and the synchronization flag never changes to 2. We also found that this phenomenon occurred because originally the system was running on the R5F0-0 core, and then we switched it to the R5F1-0 core. When we switched back to the R5F0-0 core, the problem disappeared. I am wondering if there is anything we should pay attention to when using these two cores.

  • 0 in reply to Teja Rowthu
    Intellectual 840 points

        I can send you the configuration we are using. Could you help analyze whether there is any issue with our configuration? The rest of the code is completely ported from the R5F0-0 core without any modifications.

    6180.example.rar
  • 0 in reply to Wendy
    TI__Genius 9060 points

    Hi,

    The application core related to CPSW or CPTS, and their drivers will not change based on the core which we are operating. What I would like to understand is, are all boards running the gPTP application in R5FSS-1-0?

    We can try to reproduce this issue in our test bench, but this requires some time, since it is not an out of box example, and the team is currently in a time crunch. I can plan this activity during the start of next week, and get you our observations in a week's time from now. 

    Please let us know if this doesn't fit within your timeline.

    Thanks and regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Intellectual 840 points

    Hello，

        Yes, all our devices are running on R5F1-0. I'm glad to hear from you. Please keep me updated on any progress. Thank you very much！

  • 0 in reply to Wendy
    TI__Genius 9060 points

    Hi,

    Thank you. Please expect a response in one week.

    Regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Intellectual 840 points

    Hello，

        In my previous post, I mentioned generating integer-second pulses. Using the patch you provided, I was able to generate integer-second pulses with Genf. However, during testing, some issues have arisen. We are using four devices: A -> B -> C -> D, where A is the master clock, and they are cascaded sequentially. In the early stage of operation, the integer-second pulse edges of B, C, and D were all within 1 µs, as verified using a logic analyzer. But after running for more than 12 hours, we observed a 20 µs difference between B and C, and also a 20 µs difference between D and C, while the difference between D and B remained within 1 µs. This phenomenon is quite strange. If it were a cumulative error, the difference between D and B should also be large. Could you please help analyze the possible cause?

        We printed out the calculated time synchronization differences, including the minimum and maximum time differences, the number of times exceeding 1 µs, and the total number of calculations. Below are the print records from the BCD devices.

    B：

    C：

    D：

    C and B:                                                                                    D and C:

            

    D and B

  • 0 in reply to Teja Rowthu
    Intellectual 840 points

    Hello,

        I'd like to confirm with you: do you use the GPTP_QUICKSYNC macro during testing? When this macro is used, GPTP_MASTER can only be defined as 0 or 1, meaning it's either a master clock or a slave clock. When acting as a slave clock, must the designated Ethernet port only be connected to the upstream master clock, and the other Ethernet port only to a downstream slave clock?

  • 0 in reply to Teja Rowthu
    Intellectual 840 points

    Hello，

        I discovered an issue with the Genf output. Earlier I reported that after time synchronization is stable, configuring the Genf pulse output should allow different terminals to output at the same moment. The initial test showed the same behavior, but after running for more than 12 hours, deviations appear in the pulse intervals between different terminals — which is what I described above. This happens when the Genf output is configured only once after synchronization is stable.

        I ran another test: first, after synchronization is stable, the Genf PPS (pulse-per-second) is output, and then the Genf output is reconfigured every 10 minutes. After running for over 12 hours, I found that the pulse intervals between different terminals were basically stable and stayed within 2–3 µs. This phenomenon basically confirms that Genf does not adjust its output based on the synchronization timing. Is my understanding correct? If so, I hope you can provide a corresponding solution. Thank you very much.

  • 0 in reply to Teja Rowthu
    Intellectual 840 points

    Hello，

        Is anything news about the question？