• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 34 subscribers
  • Views 1260 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.

DP83630, l2 one-step sync and vlan

Stefan Sørensen
Prodigy 40 points
Other Parts Discussed in Thread: DP83630, DP83640

I am working on getting one-step sync in l2 packets working when transmitted as a tagged vlan packet. The packet timestamp is updated correctly by the DP83630, but the remote end receives the packet with an incorrect crc.

Disabling either one-step sync or vlan tagging results in correct crc values.

Is this functionality validated to work? Any pointers to fixes/workarounds/etc?

This is an example packet dump on the remote end:

0000 01 1b 19 00 00 00 00 13 d1 80 ee 56 81 00 00 03
0010 88 f7 00 02 00 2c 00 00 00 00 00 00 00 00 00 00
0020 00 00 00 00 00 00 01 02 03 04 05 06 07 08 00 01
0030 07 35 00 00 00 00 00 00 0c 94 0f a8 24 48 15 75
0040 83 19

The crc sequence should be 34 00 2c 9b, not 15 75 83 19.

6644.onestep_sync_with_bad_crc.zip

  • 0
    TI__Mastermind 31600 points

    What is the initial value of the origin timestamp before the packet is passed to the DP83630?  Could you provide the packet dump of the packet before it is passed to the DP83630? 

    Based on the configuration of your system, does the inserted timestamp appear approximately correct? 

    Patrick

  • 0 in reply to Patrick OFarrell
    Prodigy 40 points

    The initial value of the origin timestamp is zero - the inserted timestamp seems correct.

    Packet capture on both the local and remote of the same packets:

    7288.onestep_sync_with_bad_crc.zip

  • 0 in reply to Stefan Sørensen
    Prodigy 40 points

    Digging some more, it appears that l2 vlan tagged sync packets needs an additional two bytes of padding at the end of the packet. The datasheet specifies that this should be done for udp packets, but not for l2 - and it works fine with out the padding when not using vlan tagging.

  • 0 in reply to Stefan Sørensen
    TI__Mastermind 31600 points

    Stefan,

    Good work and thanks for posting the resolution.  Could you clarify the reference to adding the bytes of padding?  Is this in the datasheet or in the Software Development Guide?  If you will point me to the specific section to which you are referring, I will see if I can improve the text to make this functionality clear to future users. 

    Thanks again,

    Patrick

  • 0 in reply to Patrick OFarrell
    Prodigy 30 points

    Hi, 

    Could you explain your solution? 

    I'm facing the same issue.

    I use a K60f120m and the DP83640.   I did a softwware version with PTP slave that works fine.

    Now I'm trying the Master.  I checked the C lib as example and I have correctly the timestamp added in the Sync message, but my slave doesn't see the packet. 

    I guess it's the same problem with the cheksum or CRC. 

    Thanks

    Stephan

  • 0 in reply to stephan aronson
    Prodigy 40 points
    To get one-step sync working, I include a zero timestamp and add two extra zero bytes at at the tail of the message. The DP83640 then inserts the timestamp and set the padding bytes to value such that the checksum is still correct.

    According the the datasheet, the extra padding is only needed when using UDP as transport, but apparently is is also needed when using VLAN encapsulated raw ethernet as transport.

    Stefan