FRDM-K64F IEEE1588 strange timestamp resolution

[ombra32]

Hi,

I'm using a FRDM-K64F board with MCUXpresso 11.0 and SDK 2.6.0.

I've slightly modified the main routine of enet ptp1588 example from SDK, in order to send 128 ptp frames and retrieve the corresponding transmit timestamps, to do some statistics.

I've noticed that all timestamps retrieved are multiple of 80ns.

It's a very strange behavior, because in the mentioned example the 1588 timer uses the 50Mhz board clock provided by PHY, and I would expect a 1588 timer resolution of 20ns.

If I manually read the 1588 timer, using the function ENET_Ptp1588GetTimer(...), the variation observed is correctly 20ns.

Where is the mistake? Some ideas?

Regards,

Marco

[Sabina_Bruce]

Hello Marco,

Thank you for the additional information. I have now understood the process you have described. 

The comparison that you are making is not valid. There are a couple of things that you should consider of how you are measuring the timer. 

When you do the "manual" reading of the timer, you are using the Ptp 1588 timer is out of context. The interrupts are not disabled prior to entering this for-loop, due to this during the execution of the  loop and printf you are prone to interrupts getting triggered. Because of this, you cannot guarantee that the time being read will always be the same. You can see by the results you have that there is a cyclical time difference when you divide by 80ns. You get 60, 40, 20, 0 repeatedly this indicates that there are background tasks/interrupts occuring.  

To sum up, the ENET_Ptp1588GetTimer  gets the current time read.

ENET_GetTxFrameTime & ENET_GetRxFrameTime are used by the stack to properly store the values of the time stamp when there is a frame transmitted and received. 

Best Regards,

Sabina

[ombra32]

Yes, this is true and I agree with you.

Readings with "ENET_Ptp1588GetTimer" are asynchronous and random in time. For this reason that timestamps are multiple of 20ns. It's ok, because 1588 timer increment is 20ns.

But the strange behavior I'm talking is about the "ENET_GetTxFrameTime / ENET_GetRxFrameTime".

Why in this case ALL timestamps are multiple of 80ns instead of 20ns as in the above case?

It's impossible that I accidentally send and receive ALL packets with such a constant period multiple of 80ns.

It seems that when 1588 frames are sent or received, corresponding timestamps are latched with a slower clock or with a signal resynchronized to a different clock domain.

In this case, synchronization performance between nodes in a 1588 network are not so good as expected.

Regards,

Marco

[Sabina_Bruce]

Hi Marco,

Focusing on what you mention here:

But the strange behavior I'm talking is about the "ENET_GetTxFrameTime / ENET_GetRxFrameTime".

Why in this case ALL timestamps are multiple of 80ns instead of 20ns as in the above case?

It's impossible that I accidentally send and receive ALL packets with such a constant period multiple of 80ns.

The remainder when dividing by 80ns is constant as you have described. But it is not a multiple of of 80ns. In order to be a multiple this means that the remainder should not be any value other than zero. In your excel when you use the MOD function this returns the remainder value. If you see the actual number that results from the division you will see its a decimal, therefore its not a multiple.

Let me know if this makes sense.

Best Regards,

Sabina

[ombra32]

Hi,

any news?

Regards,

Marco

[ombra32]

Hi Sabina,

do you have some news?

Regards,

Marco

[ombra32]

I'm sorry, but this time I disagree.

It's true that timestamps taken "as they are" are not numerically multiple of 80ns because, as you mentioned, remainder is not 0.

But In order to have a period multiple of 80ns is sufficient to divide timestamps by 80ns and obtain all remainders equal.

The remainder different from 0 means that there is a small offset added to all timestamps.

This offset simply is the initial starting point dictated by the first packet sent/received.

If you subtract the same offset from all timestamps, then all remainders became 0.

So, as I stated earlier, ALL send/receive packets have a constant period multiple of 80ns.

But why we obtain such a behavior? Why all timestamps are latched at multiple of 80ns?

Regards,

Marco

[Sabina_Bruce]

Hello Marco,

Can you provide the details of the changes you made to the example. This will help me reproduce what you have and see the behavior you are experiencing.

If possible you can attach your project here.

Best Regards,

Sabina

[ombra32]

Many thanks for fast reply.

I've only modified main function in "enet_txrx_ptp1588_transfer.c" in order to print more tx and rx timestamps.

I've tested it with 2 FRDM-K64F boards, the first as master node and the second as slave node (you can select master/slave using debug console).

You can find file and entire project attached.

I've provided also a spreadsheet with my results.

Regards,

Marco

[Sabina_Bruce]

Hi Marco,

I apologize for the delayed response. I've been working on the code you sent me, but I'm not entirely sure if this is what you are looking for. 

Or if I am misunderstanding what you are asking. 

So I've run the K64 several times and comparing values from the tx and rx timestamps that are printed on the console.

So from the numbers you provided what I did was subtract the ns from the rx and tx. When I compare from one to another I see the increments of 80.However when I do the same calculations with that of 20 ptp frames I get the same results. 

Can you please confirm if this is how you are checking the incrementes of 80.

[ombra32]

Hi Sabina,

I'm sure you can obtain the same results from both the data printed on you console and data I provided to you.

What I'm trying to point out is that if you directly read the 1588 timer with the "ENET_Ptp1588GetTimer(...)" driver function you obtain timestamps multiple of 20ns (if you divide each timestamp by 80ns you obtain different remainder values, if you divide them by 20ns you obtain a remainder constant value).

On the other hand, if you send or receive 1588 frames and retrieve the corresponding timestamps, the obtained data is always multiple of 80ns (this time if you divide each timestamp by 80ns you obtain a remainder constant value).

At this stage, you can directly analyze stand alone timestamp values, without consider the rx-tx difference.

I would expect a 1588 timer resolution of 20ns for both operations, as the clock provided is the same.

I've modified the example trying to be more clear. You can find it attached.

Many thanks,

Marco