Details
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
- mentioned in
-
Page Loading...