i.MX‑RT1170: Question regarding correctness of ENET_Ptp1588GetTimer()

[michael_fischer]

Hello,

I am working with the i.MX‑RT1170 ENET1588 hardware timestamping unit. While validating the accuracy of PTP timestamp reconstruction, I noticed a potential issue in the SDK function: ENET_Ptp1588GetTimer()

The function builds a timestamp consisting of:

• handle->msTimerSecond (software second counter updated in the 1‑Hz PTP timer interrupt)
• ATVR (hardware nanoseconds, captured via ATCR)
• EIR & kENET_TsTimerInterrupt (wrap flag)

After testing various timing edge cases, I have found a problematic scenario where the function may return an incorrect value.

However, I don't have a test program for this; I've only played it through theoretically.

Problem description
The issue occurs when a wrap happens close to the nanosecond capture, but the 1‑Hz ISR (which increments msTimerSecond) cannot run because interrupts are disabled, or because we are already inside an ENET interrupt handler.

Sequence:

1. The PTP hardware timestamp counter is close to the wrap event (e.g. around 3.999999990 seconds).
2. Global interrupts become disabled (or we are inside an ENET ISR).
3. A capture is performed via ATCR → the captured nanoseconds may still belong to the old second, e.g.
   t_nsec = 999999998.
4. After the capture, but before interrupts are re‑enabled, the hardware second actually wraps to the next second. The hardware sets EIR & kENET_TsTimerInterrupt.
5. However, the 1‑Hz ISR that increments msTimerSecond cannot run, so
   msTimerSecond still holds the old second value.
6. ENET_Ptp1588GetTimer() interprets a set wrap flag ( if (0U != (base->EIR & (uint32_t)kENET_TsTimerInterrupt)) ) as “current time is in the new second” and returns: ptpTime->second++

This results in a timestamp such as: 4.999999998   (incorrect)
even though the correct time represented by the captured nanoseconds is: 3.999999998   (correct)

In other words:
The function cannot distinguish whether the wrap flag was set before or after the nanosecond capture, and therefore may add one second incorrectly.

Question
Is the current implementation of ENET_Ptp1588GetTimer() intended to work correctly under these timing conditions?

Specifically:

• Does NXP consider it correct to use the wrap flag alone (without knowing whether it occurred before or after the nanosecond capture)?
• Should the function read the wrap flag both before and after the ATCR capture in order to determine whether the wrap actually happened before the sampled nanoseconds?
• Or is there an updated or recommended implementation for robust timestamp reconstruction on the i.MX‑RT1170?

Any clarification or guidance you can provide would be greatly appreciated.

Best regards,
Michael

[Kan_Li]

Hi @michael_fischer ,

Are you referring to the latest SDK version? The current code also checks the value of ptpTime->nanosecond on the step 6 - ENET_Ptp1588GetTimer() interprets a set wrap flag ( if (0U != (base->EIR & (uint32_t)kENET_TsTimerInterrupt)) ) as “current time is in the new second” and returns: ptpTime->second++

Please kindly clarify.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[michael_fischer]

Hello Kan,

reference was made to the SDK 25_12_00, here the function looks like:

void ENET_Ptp1588GetTimer(ENET_Type *base, enet_handle_t *handle, enet_ptp_time_t *ptpTime)
{
    assert(handle != NULL);
    assert(ptpTime != NULL);
    uint32_t primask;

    /* Disables the interrupt. */
    primask = DisableGlobalIRQ();

    ENET_Ptp1588GetTimerNoIrqDisable(base, handle, ptpTime);

    /* Get PTP timer wrap event. */
    if ((0U != (base->EIR & (uint32_t)kENET_TsTimerInterrupt)) && (ptpTime->nanosecond < (ENET_NANOSECOND_ONE_SECOND / 2)))
    {
        ptpTime->second++;
    }

    /* Enables the interrupt. */
    EnableGlobalIRQ(primask);
}

Yes, there is a check for the interrupt flag, and I think it's in the wrong place. That's why I'm asking. Here's my example with a check before and after:

static inline void GetTime (ptp_t *ptp, enet_ptp_time_t *ptpTime)
{
   ENET_Type *base = ptp->base;
   uint32_t   primask;
   uint32_t   t_nsec;
   
   /*
    * Note:
    *   - ptpSeconds is incremented ONLY in the 1-Hz ISR.
    *   - IRQs are disabled here, so ptpSeconds remains stable.
    *   - The EIR flag kENET_TsTimerInterrupt is sticky (HW sets it, ISR clears it).
    *     Therefore, we read it BEFORE and AFTER the capture to correctly detect
    *     whether the wrap occurred before or after the capture.
    */

   primask = DisableGlobalIRQ();

   /* Event before capture */
   const uint32_t e0 = base->EIR & (uint32_t)kENET_TsTimerInterrupt;

   /* Start to capture the nano seconds */
   base->ATCR |= ENET_ATCR_CAPTURE_MASK;
   while ( (base->ATCR & ENET_ATCR_CAPTURE_MASK) != 0U )
   {
      /* Wait until CAPTURE bit auto-clears */
   }
   t_nsec = base->ATVR;

   /* Event after capture */
   const uint32_t e1 = base->EIR & (uint32_t)kENET_TsTimerInterrupt;
   
   ptpTime->second = ptp->seconds;

   EnableGlobalIRQ(primask);
   
   /*
    * Note:
    *
    * The second-wrap flag (kENET_TsTimerInterrupt) is sticky and is cleared
    * only by the ISR. If this flag is set, there are two possible cases:
    *
    * 1) Real second rollover:
    *    - The nanoseconds value (nsec) right after the capture is very small
    *      (close to 0 ... a few microseconds).
    *    - In this case, the captured timestamp belongs to the NEW second -> sec = s + 1.
    *
    * 2) Old / stale flag:
    *    - The flag originates from an earlier rollover (the ISR has not yet cleared it).
    *    - The nanoseconds value is then large (far away from 0).
    *    - In this case, the captured timestamp still belongs to the OLD second -> sec = s.
    *
    * Therefore: If the wrap flag is set, increment the second only if nsec < THRESHOLD.
    */   
   if ((e0 == 0U) && (e1 == 0U))
   {
      /* No wrap, do nothing */
   }
   else if ((e0 == 0U) && (e1 != 0U))
   {
      /* Wrap after capture, t_nsec still belongs to the old second */
   }
   else
   {
      /* e0 != 0: wrap was already set check THRESHOLD */
      if (t_nsec < ENET_PTP_WRAP_NS_THRESHOLD)
      {
         ptpTime->second++;
      }   
   }

   ptpTime->nanosecond = t_nsec;
   
} /* GetTime */

I conducted tests in the "TsTimerInterrupt" to determine the value of t_nsec after the interrupt. The maximum value I found was 540ns. Therefore, I generously set THRESHOLD to 5000, which is 5µs.

I've also noticed now that you don't actually need the flag afterwards, but that you should save the flag beforehand, and only then perform the check after querying "ATVR".

Referring to the original NXP function, I would therefore note the flag before ENET_Ptp1588GetTimerNoIrqDisable, and then later increase the time based on the flag if necessary.

Best regards,
Michael

[Kan_Li]

Hi  @michael_fischer ,

Thanks for the clarification! Yes, your understanding is correct, and we recommend handling such adjustment on a higher layer, such as we implement it in an-ethernet-lwip-ptpd-imxrt , you may fetch this demo from the application code hub, and refer to enet_get_txframe_time() for details.  You may refer to https://docs.nxp.com/bundle/AN12149/page/topics/introduction.html for more details regarding this demo.

Hope that helps,

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------