IEEE1588 time-stamping issue

[christophe31]

Hi,

I'm trying to use IEEE1588 time-stamping capability on a Vybrid Tower kit TWR-VF65GS10.

I'm using the 50MHz external clock to clock the ENET module, thus I use an increment value (ENET_ATINC) of 20 (0x14). That way I can directly read values expressed in nano-second.

It seems to work correctly, but when I use the timestamp counter (ENET_ATVR) to measure some code performance I get a strange behaviour :

I make 2 succesive readings of ENET_ATVR (which first needs to set the CAPTURE flag of ENET_ATCR register), then I compare the 2 values.

On a very small piece of code, most of the time, the difference is an almost constant value (560 or 580 ns), but sometimes (?!) values are not consistant at all. I can observe various behaviors :

- Increment is not consistent :

  t1 = 0x7AD650B4

  t2 = 0x7AD6548C

  diff. = 984

==> the difference is greater that 580, but primarily it is not a multiple of 20 ?!

- The difference is negative :

  t1 = 0x0862D280

  t2 = 0x0862D0C4

  diff. = -444

  Here, the expected t2 value is 0x0862D4C4 (seems to be a defect on bit 10), but this is not always so trivial e.g. :

  t1 = 0x60EB193C

  t2 = 0x60EB135C

I also note another strange behavior : I launch my SW normally, then I break and disable time-stamping (I set ENET_ATCR=0) with my debugger (Lauterbach Trace32).

Then I set the CAPTURE flag many times to acquire some ATVR values. What I get is 2 different values separated by the increment value. Values are not coming in a regular flow, e.g. :

0x2EAECC10

0x2EAECC10

0x2EAECC10

0x2EAECC10

0x2EAECC24

0x2EAECC10

0x2EAECC24

0x2EAECC24

...

It seems that data come from a dual buffer. Could it be the origin of the problem ?

Here is my IEEE1588 registers configuration :

      ATCR    00000001

      ATOFF   00000000

      ATPER   80000000

      ATCOR   00000000

      ATINC   00001414

I experiment this on both ENET0 and ENET1

Did someone face such an issue ?

Thanks for any help

Regards

Christophe

[juangutierrez]

Hi

By googling I found and errata for Kinetis processor

e2579: ENET: No support for IEEE 1588 timestamp timer overflow interrupt

Errata type: Errata

Description: The TS_TIMER interrupt signal is not connected to the NVIC and will not generate an interrupt

event. This interrupt is set when the 1588 counter overflows.

Workaround: Use one of the Timer Compare Capture Registers, TCCRs, to manually force a counter

overflow event in order to trigger a counter overflow interrupt.

Maybe something similar is happening here:

For MQX code, the WA is already implemented

You can check the code in mqx/source/io/enet/macnet/macnet_1588.c at function MACNET_ptp_start (Around line 20 below)

uint_32 MACNET_ptp_start(MACNET_PTP_PRIVATE *priv, boolean master_mode)
{
        MACNET_PTP_PRIVATE *fpp = priv;


#if defined(BSP_TWR_K60N512) || defined(BSP_TWR_K60D100M)
    /* Select the 1588 timer source clock - EXTAL clock */
    OSC_CR |= OSC_CR_ERCLKEN_MASK;
    SIM_SOPT2 = ((SIM_SOPT2) & ~SIM_SOPT2_TIMESRC_MASK) | SIM_SOPT2_TIMESRC(0x2);
#endif


        /* Enable module for starting Tmr Clock */
    fpp->MACNET_PTR->ATCR = ENET_ATCR_RESTART_MASK;
    fpp->MACNET_PTR->ATINC = MACNET_1588_CLOCK_INC;
    fpp->MACNET_PTR->ATPER = MACNET_1588_ATPER_VALUE;


#if (MK60_REV_1_0 || MK60_REV_1_1 || MK60_REV_1_2)
    /* Workaround for e2579: ENET: No support for IEEE 1588, TS_TIMER, timestamp timer overflow interrupt */
    fpp->MACNET_PTR->CHANNEL[MACNET_PTP_TIMER].TCCR = MACNET_1588_ATPER_VALUE - MACNET_1588_CLOCK_INC;
    fpp->MACNET_PTR->CHANNEL[MACNET_PTP_TIMER].TCSR = (((0x5)<<ENET_TCSR_TMODE_SHIFT)&ENET_TCSR_TMODE_MASK) |
                                                      ENET_TCSR_TIE_MASK;
    fpp->MACNET_PTR->CHANNEL[MACNET_PTP_TIMER].TCCR = MACNET_1588_ATPER_VALUE - MACNET_1588_CLOCK_INC;
#endif


    /* Period PIN & EVT bits must be set for rollover detect */
    fpp->MACNET_PTR->ATCR = ENET_ATCR_PEREN_MASK| ENET_ATCR_PINPER_MASK;


    /* Set the slave mode in case the MACNET is not handling the 1588timer */
    if(!master_mode)
            fpp->MACNET_PTR->ATCR |= ENET_ATCR_SLAVE_MASK;


    /* Start counter */
    fpp->MACNET_PTR->ATCR |= ENET_ATCR_EN_MASK;
    return 0;
}

[christophe31]

Hi Juan,

Thanks for your help.

I'm not concerned by this errata, but thanks to you, I looked at MQX and I found another undocumented way to access ATVR. They set the capture flag twice :

  macnet_ptr->ATCR |= ENET_ATCR_CAPTURE_MASK;

  macnet_ptr->ATCR |= ENET_ATCR_CAPTURE_MASK;

  curr_time->NSEC = macnet_ptr->ATVR;

I guess this is another way to wait for ATVR counter to be ready...

I tested it, it takes ~100ns more than my workaround, but maybe it is an "approved" solution ?

Regards,

Christophe

[jiri-b36968]

Hi Christophe,

You are right. If you need 2 Ethernet interfaces you need to use RMII due to share pins. When RMII is used we use external 50MHz clock from TWR-SER2 tower module. We have also observed some issues on IEEE1588 when RMII is used. Not sure if it help when clock is generated on Vybrid - unfortunately clockout for RMII is not suported on Vybrid tower module. We can check it once rev.H with MII interface and clockout is available.

/Jiri

[naoumgitnik]

Dear Christophe,

We are aware of that this feature has an issue with the way it is implemented on the Tower kit.

for those interested in it, we recommend to use the MII interface instead of the existing RMII - the Tower PHY module does support both of them, as far as i know.

Please, expect more details within several days.

Regards, Naoum Gitnik.