Uploaded image for project: 'EtherNet/IP Core V3'
  1. EtherNet/IP Core V3
  2. PSEIP-784

PTP: Use the sync DPM handshake to synchronize (daisy-chain) access to the CIP sync timestamp in the extended status area between APP and COM sides.

    Details

    • Type: Change
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: V3.8.4.0
    • Component/s: AdapterAP, GCI, ScannerAP
    • Labels:
      None
    • Account:
      SPC EthernetIp Core (SPCETHERNET)

      Description

      Currently, on each sync trigger interrupt from the XC we process within the firmware, we write the 64-Bit CIP Sync System Time into the DPM Extended Status Block for the host to read. This is two DWORD writes which are not atomic.

      This is done unconditionally, regardless of whether the host uses the DPM sync interrupt at all or if currently, the netX or the host is in control of the sync handshake.

      The 'issue' with it is that the COM-CPU and the APP-CPU are not interlocked when writing/reading the timestamps. Hence, the application always had to read in a transactional manner according to the following protocol (see, for instance NXS-32575):

           Read seconds fraction
           Read nanoseconds fraction.
           Read seconds again, verify unchanged, otherwise start over

      This is legacy behavior which has been in there for a long time apparently. This feature shall be not supported anymore.

       

      In this ticket we want to consider proper locking of that timestamp exchanging through the DPM sync handshake:

      • The DPM sync handshake flags shall define whether the COM or the APP side has exclusive access to the CIP Sync System Time in the DPM Extended Status Block and both sides will comply to that protocol. The eCos and rcX firmware implementations have to be adapted.
      • If the DPM sync handshake flags are not used or are used but not toggled back in time, and the sync event occurs, this is accounted as a sync error (so it is today). In this case, the stack shall no longer update the timestamp (since it has no control over the CIP Sync System Time). Anyway, the APP side must then evaluate the error count or at least be able to recognize unchanged timestamps to detect synchronization errors. This is a topic for the API Manual and application note.

        Attachments

          Issue Links

            Expenses

              Activity

                Status Description

                  People

                  • Reporter:
                    MBommert Marc Bommert
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    0 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: