IEEE 1588 Timer

[wolfgang_gaerbe]

[Because the imx6 1588 support looks similar - such issues may apply to imx6.]

We are using the IEEE 1588 timer to sync multiple i.MX28.

In Section 26.3.13.2.2 (Adjustable Timer Implementation) of the reference manual,

the operation with 125MHz from CLK_ENET_TIME is proposed as example.

This timer and the way it operates is somewhat perfect if the period duration of the clock can be expressed by even nanoseconds:

8ns - 125MHz

9ns - 111MHz

10ns - 100MHz

.......

Using 125Mhz as in the "example" gives the best resolution.

The problem is that I don´t know how to generate a CLK_ENET_TIME of 125Mhz.

With HW_CLKCTRL_ENET_TIME_SEL, I can choose my clocksource:

USING 480MHz PLL:

If I divide 480MHz / 4, I get 120MHz, which gives 8.33ns

/5 gives 10.42ns

/6 gives 12.5ns

.....

only /12  gives an even number of 25ns.

USING ref_xtal (24MHz):

/3 gives 8MHz/ 125ns

USING enet_rmii_clk_in:

Looking at the clock domains, enet_rmii_clk_in can be derived from CLK_ENET_OUT. To achieve that I have to enable HW_CLKCTRL_ENET_CLK_OUT_EN.

So there should be CLK_ENET_OUT on enet_rmii_clk_in.

CLK_ENET_OUT can be derived from "PLL2 50MHz" which should provide 50MHz.

So even by division I don´t see a way to get 125MHz for that timer.

The only idea was that someone mis-spelled the "PLL2 50MHz" as "PLL 250MHz" - and thought that it gives nice 125MHz if divided by two.

If I use this option I can have 50MHz with 20ns.

To sum it up I can use 50Mhz - 20ns (derived from 50MHz RMII clock), 40MHz - 25ns (derived from 480MHz PLL divided by 12) and 8MHz - 125ns (derived from ref_xtal / 3).

Additional Issues / Errata found with the 1588 Timer

1) Capture / Readout timer

If the 1588 timer is operated with lower clockspeeds - (for example 40MHz) - there is a mandatory pause needed between setting the capture bit - and readout of the timer.

The internal transfer from timer to readout register obviously takes a minimum of 6 peripheral clock cycles - in the case of 40MHz operation this would be 150ns - more than 68 core clock cycles if running with 454MHz core clock. A value of 75cycles seems to work sufficient.

Using 1588 Timer with 120MHz clock, there would be the need to wait for 23cycles. This might work with less optimization and some code between capture and readout.

2) Interrupts lost

Using the timer looping within 1e9 ns mode - and having a capture  IRQ (event input) simultaneously in the area of the wrap - the capture irq gets lost.

Workaround: assume that you have no capture irq simultaneously to the wrap - or use 32-bit wrap (not tested).

rgds.

Message was edited by: wolfgang gaerber

[mbp]

Can someone at Freescale please respond to Wolfgang's suspicion that what he has encountered in the Mx28 would be in the Mx6 silicon as well?

Thanks,

Mike