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.

DP83640: PTPClockStepAdjustment() doesnt adjust the 1588 clock

Part Number: DP83640
Other Parts Discussed in Thread: TMS570LS3137,

I want phase align master clock. 

When I do the calculation according to AN-1729 application note, I get a value and call this function.

PTPClockStepAdjustment(&pObj, 0, abs(correction), FALSE);

To check if this function works I do the same thing again but correction value comes close to the first one. So I believe I cant adjust the clock.

Also after sync algorithm I do get a adjustment value but still cant adjust the clock with this function.

I checked the register via MDIO register of TMS570LS3137, so I confirmed that I can write the data correctly.

But after setting PTP_STEP_CLK bit of PTP_CTL register while adjusting the clock, PTP_STEP_CLK is not self clear itself eventhough the datasheet says that bit is SC.

Which steps should I follow to fix this issue?

Thanks in advance.

  • Hello  

    Please refer to the documents and the code from the below link that should help .

    https://www.ti.com/tool/DP83640SW-LIB

    Regards,

    Sreenivasa

  • Hello again ,

    Yes I follow that document as well. I think when I calculate the phase difference second time after I calculate and do the step adjustment, I shouldn't get the exact value (which goes 0-100 because of 10MHz clock output).

    And also while doing these steps PSF is disabled. So what would cause this?

    Any help will be great.

    Thanks in advance,

    Furkan

  • Hello Furkan, 

    Could you please elaborate the issue you are facing. Is this your custom board?  Id possible write a simple sketch.

    Can you please provide some additional details on the drivers that you are using.

    Regards,

    Sreenivasa

  • I'm using TMS570LS3137HDK. My main goal is to phase align and sync 2 of this board with their onboard DP83640 chips.

    I use EPL Library for accessing PHY's registers. I can get a 10 MHz clock output with CLK_OUT pin so library works okey. 

    Also I created some UDP PTP headers(for sync messages only) for PHY to timestamp and send it with lwIP. I can get the delay_resp message in slave board and calculate the clock adjustment value. I also can see the messages labeled as PTPV2 in wireshark in pc. But when I call the PTPClockStepAdjustment function, I assume clock doesnt change because I cant see a change in ossiloscope.

    I also noticed PTP_STEP_CLK bit doesnt clear itself in this function. Datasheet says reading this bit will return 0 but I can see 1. I attached an image to show this.

  • Hello Furkan, 

    Thank you for the inputs.

    Let me review the inputs and comeback to you early next week.

    Regards,

    Sreenivasa

  • Hi,

    When I change the clock source to PGM the problem is gone for sure. I can change the ptp clock and can confirm.

    My system goes like this.

    1-Both slave and master ptp enabled and give clock output of 10MHz

    2- Master sends sync msg with Timestamp1(T1)

    3-Slave saves Timestamp1,receiveTime(T3)

    4-Slave send delay_req and saves sentTime(T3)

    5-Master sends delay_resp with Timestamp4(T4)

    6-Do the calculation get difference(T5) and call and offset the ptp clock.

    But I dont see any change on ossiloscope screen.(I'm taking input from their CLK_OUTPUT pins)

    I'm trying to get master's timestamp with PTPGetReceiveTimestamp(). Is it correct or do I have to create an UDP parser for getting timestamp?

    Thanks in advance,

    Furkan

  • Hello Hello Furkan, 

    Thank you for the inputs.

    Have you looked at using the Phy status frames ?

    Regards,

    Sreenivasa

  • Hi sorry for the late reply due to weekend.

    I use lwIP raw api for UDP. when I receive an UDP data(say sync message) I put this data to isPhyStatusFrame function and if yes I call GetNextPhyMessage to see the incoming message. Sometimes I get PHYMSG_STATUS_TX as messageType but when it comes to checking which PTP message did I get(sync or delay_resp) I dont get a reasonable value.

    So I'm lost on how to implement those function.

    Regards,

    Furkan

     

  • I got a switch to confirm messages if they sent correctly and I realized these.

    dResp is 54byte PTP Delay_Resp struct
    MsgDelayResp is 54 byte PTP Delay_Resp struct
    MsgSync is 44 byte PTP Sync message struct
    ptpHeader is 34 byte PTP Header struct

    DR_INSERT is set and sent with this 

    udp_dRespSend(&dResp, multicast_ip, port_319 ,sizeof(MsgDelayResp));

    DR_INSERT is not set and sent with this 

    udp_dRespSend(&dResp, multicast_ip, port_319 ,sizeof(MsgDelayResp));

    Note that: I only change ptp header according to msg type

    DR_INSERT is not set and sent with this 

    udp_HeaderSend(&ptpHeader, multicast_ip, port_319,sizeof(MsgDelayResp));

    DR_INSERT is set and sent with this 

    udp_HeaderSend(ptpheader, multicast_ip, port_319,sizeof(MsgDelayResp));

    How to configure phy for correctly timestamping delay_Resp message

    I send sync and delay_Req message like this and they work 

    udp_HeaderSend(&ptpHeader, multicast_ip, port_319, sizeof(MsgSync));

    but when it comes to delay_resp it gives me this outputs like above pictures

    My deadline is very soon so it's important for me to solve this problem.

    Thanks in advance

    Furkan

  • Hello again Kallikuppa,

    The project's deadline is getting close so can you help me asap if possible?

    Regards,

    Furkan

  • Hello Furkan, 

    I have referred to the TMS570LS3137HDK team to provide the required support.

    Regards,

    Sreenivasa

  • Have you resolved your issue? To be honest, I am not familiar to 1588 protocol.

  • Hi,

    I can use hw timestamping rn but while adjusting the differences i calculate the offset about 0.5 sec and due to that I cant do syntonization process. My implementation logic is in above comment of mine. So project hangs for a while.