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.

TDA4VM: Conflicts between code and comments while debugging PTP stack

Part Number: TDA4VM

Hi

PDK version :pdk_jacinto_07_01_00_45

Code version:pdk_jacinto_07_01_00_45\packages\ti\transport\timeSync\v2

I noticed some conflicts:

The eventID of frame pending to get Tx timestamp is Pdelay_Requset,while the input para of TimeSyncPtp_getTxTs is TIMESYNC_DELAY_REQ_FRAME.

The eventID of frame pending to get Tx timestamp is Pdelay_Response,while the input para of TimeSyncPtp_getTxTs is TIMESYNC_DELAY_RESP_FRAME.

Another conflict is in TimeSyncPtp_getTxTs() in timeSync_ptp.c

The condition is to check frame type of TIMESYNC_DELAY_RESP_FRAME while get the timestamp of TIMESYNC_PDELAY_RESP_FRAME.

Why?

Also I have some other questions:

1. Why can not use the combination that  ptpConfig->protocol = TIMESYNC_PROT_IEEE_802_3 & ptpConfig->type  =TIMESYNC_PTP_DELAY_E2E?

2. There are 4 types of frame needed to get timestamp while the code is just get three of them.it does not get time stamp of  Delay_req.

3. Errors happened when getting the time stamp using the mode of E2E over udp.Here is the configuration of Master side:

The error log is:

Is there any other parameters needed to be configured?

  • Hi,

    Sorry for the delay.

    Answers to your questions below

    >The eventID of frame pending to get Tx timestamp is Pdelay_Requset,while the input para of TimeSyncPtp_getTxTs is TIMESYNC_DELAY_REQ_FRAME.

    TI : Both Pdelay_Request and Delay Request frames are not handled simultaneously in the timeSync implementation, so internally the timestamp location is re-used. Thus we use the same ID interchangeably sometimes.

    >The eventID of frame pending to get Tx timestamp is Pdelay_Response,while the input para of TimeSyncPtp_getTxTs is TIMESYNC_DELAY_RESP_FRAME.

    TI: Same logic as above but for delay response. Pdelay_Response and Delay Resp are not handled at the same time. So the internal location and ID's are used inter-changeably

    >The condition is to check frame type of TIMESYNC_DELAY_RESP_FRAME while get the timestamp of TIMESYNC_PDELAY_RESP_FRAME.

    TI: Same answer as above 2

    >1. Why can not use the combination that  ptpConfig->protocol = TIMESYNC_PROT_IEEE_802_3 & ptpConfig->type  =TIMESYNC_PTP_DELAY_E2E?

    TI : This is not a full fledged PTP stack, it's only meant as a proof of concept to showcase our example applications hence some features are not supported.

    >There are 4 types of frame needed to get timestamp while the code is just get three of them.it does not get time stamp of  Delay_req.

    TI : Delay Request is not supported along with Pdelay Req and Pdelay Response frames

    > 3. Errors happened when getting the time stamp using the mode of E2E over udp.Here is the configuration of Master side:

    TI : Can you describe your setup. We can try and replicate.

    Regards

    Vineet

  • Thanks for your reply.

    1. I do not think it is a good way to deal with timestamp re-used. If user wants to get the timestamp of  Delay Request frames, he need to post the event Pdelay_Requset. It is confusing for users.

    Is this a good solution for reusing timestamp and comprehension?

    2. Here is more info about the question 3 (3. Errors happened when getting the time stamp using the mode of E2E over udp.Here is the configuration of Master side) above: 

    I tried to perform Time Sync between 2 board over PTP protocol. Main chip of both boards is TDA4 with PDK 7.1.

    Time sync code is :pdk_jacinto_07_01_00_45\packages\ti\transport\timeSync\v2

    One side is configured as Master while another is configured as Slave.

    The parameter is configured as follows using macro as compile option.

    Besides, the static ip address of Master side is 192.168.1.25 while another side is 192.168.1.45.Subnet mask is 255.255.255.0 for both sides.

    Aboves are the information i think important for the configuration. Is thers anything essential for Time Sync?

    Looking forward to your reply,Thanks~

  • Hi,

    >1. I do not think it is a good way to deal with timestamp re-used. If user wants to get the timestamp of  Delay Request frames, he need to post the event Pdelay_Requset. It is confusing for users.

    TI : I agree, as I mentioned previously, for us, E2E + UDP and P2P + L2 were orthogonal use-cases and we never ran into this issue. We will try and incorporate your feedback however.

    >2. Here is more info about the question 3 (3. Errors happened when getting the time stamp using the mode of E2E over udp.Here is the configuration of Master side) above:

    TI : Can you tell exactly what stage are you in ?  This will help me in debugging the problem

    Assuming that you are using E2E + IP4

    1. Are you getting all PTP messages in the TimeSync implementation et Sync, Follow-Up, Delay Req, Delay Resp packets etc ?

    2. Which messages are getting timestamped and which are not ?

    3. Are you able to get the E2E delay ?

    4. Is it going to synchronization routine ?

    Regards

    Vineet

  • Thanks for your reply.

    >1. Are you getting all PTP messages in the TimeSync implementation et Sync, Follow-Up, Delay Req, Delay Resp packets etc ?

     The Slave side can not receive any type of PTP frame.

    >2. Which messages are getting timestamped and which are not ?

    The Err log above is in Master side, none of messages get timestamped.

    >3. Are you able to get the E2E delay ?

    NO

    >4. Is it going to synchronization routine ?

    NO

    The error happens before starting sync.

    ############################################################

    Furthermore,I tried P2P over 802.3.

    I find something confusing.

    1)

    What if TimeSyncPtp->tsRunTimeVar.clockDrift is greater than TIMESYNC_PTP_STABLE_FILTER_THRESHOLD again after it is less than the threshold ?

    In my debugging,the clockDrift can not maintain stable after it is less than the threshhold,in which condition the value of clockDrift is greater than the threshhold while the flag(driftStable) is also set 1.

    As a result ,the offset value(hTimeSyncPtp->tsRunTimeVar.ltaOffset) can never get less than the  threshhold and stable.

    Do you know any possible reasons?

    2)  The type of pathDelay is uint32_t while the type of meanPathDelay is int64_t.I wonder if it is a right way.

    Any suggestion?

    Thanks.

  • Hi,

    Sorry, re-opening this thread after some time.

    Is this issue still open ?

    Regards

    Vineet