Potential PTP timestamp inconsistency in ENET_ReclaimTxDescriptor()

[mastupristi]

Hi,

while analyzing the implementation of ENET_ReclaimTxDescriptor() in the latest MCUXpresso SDK (24.12.00), I noticed a potential issue regarding the PTP transmit timestamp logic.

In particular, the following lines (https://github.com/nxp-mcuxpresso/mcuxsdk-core/blob/release/24.12.00/drivers/enet/fsl_enet.c#L2156

txDirty->isTsAvail = false;
if ((curBuffDescrip->controlExtend1 & ENET_BUFFDESCRIPTOR_TX_TIMESTAMP_MASK) != 0U)
{
    enet_ptp_time_t *ts = &txDirty->timeStamp;
    txDirty->isTsAvail = true;
    ts->second         = handle->msTimerSecond;
    ts->nanosecond     = curBuffDescrip->timestamp;
}

appear to assume that handle->msTimerSecond still reflects the correct seconds part of the timestamp corresponding to when the frame was actually transmitted. However, since ENET_ReclaimTxDescriptor() may be called some time after the transmission occurred (especially under heavy load or with delayed interrupts), there's a risk that msTimerSecond may have incremented in the meantime — thus leading to inaccurate or inconsistent timestamp information.

This could be problematic in scenarios that require precise PTP timestamping, such as AVB or 802.1AS.

Wouldn't it be safer to either:

• Capture msTimerSecond at the time the frame is sent (e.g., in ENET_SendFrame()), and store it alongside the descriptor?

• Or (if available on the platform), read both seconds and nanoseconds from hardware at once when the TX_TIMESTAMP bit is set?

Looking forward to your thoughts on this.

Best regards,

Max

[Alondra]

Which part number are you using?
Best regards

[mastupristi]

Hi @Alondra 

Thank you for your reply. I’ll provide the exact part number as requested — we are currently using the following NXP MCUs: RT1175, RT1051, and RT1021.

That said, I’d like to point out that the issue I’m describing appears to be architectural and not limited to a specific device.

The fsl_enet.c driver relies on handle->msTimerSecond to reconstruct the PTP transmit timestamp inside ENET_ReclaimTxDescriptor(). However, since this function may be called significantly after the actual transmission occurred, the msTimerSecond value might have changed in the meantime — potentially leading to incorrect timestamps. This logic seems to be present regardless of the specific part number, as it's handled in the shared driver code.

Ideally, I would like to leverage the hardware as much as possible to avoid relying on software-maintained time values. Some of the devices we use — such as the RT1175 — appear to offer crossbar routing and internal hardware capture for PTP events, including automatic incrementing of the seconds counter and atomic timestamp capture on transmission events.

Does NXP provide any guidance or examples on how to configure the ENET/1588 hardware for full hardware-based timestamp management (e.g., automatic rollover and event-based capture), to minimize the reliance on software timers and ISRs?

Best regards,

Max

[Gavin_Jia]

Hi @mastupristi ,

Thanks for your interest in NXP MIMXRT series!

We actually provide a standalone implementation of ptpd, both AN and ANSW. you can check out this application note here: https://docs.nxp.com/bundle/AN12149/page/topics/introduction.html

The software has not been updated to the official website yet, you can get a taste version here: https://github.com/nxp-appcodehub/an-ethernet-lwip-ptpd-imxrt

The implementation in the driver is the underlying function, for the management of seconds in ptpd, it is in the application layer, the implementation, your concern is correct, in this software, we do not use the seconds in the driver directly, but use other methods.

Please check this function implementation: 

 

Best regards,
Gavin

[mastupristi]

Hi @Gavin_Jia 

Thank you for your response and for sharing the links.

Let’s not beat around the bush — or worse, try to climb mirrors.

The issue I raised is real, reproducible, and affects every SDK version up to and including MCUXpresso SDK 25.03.000, which still ships with fsl_enet.c v2.9.2. This driver is shared across the entire RT1xxx family (RT1175, RT1051, RT1021, etc.), and contains logic in ENET_ReclaimTxDescriptor() that assigns msTimerSecond as the "seconds" part of the TX timestamp after the frame has already been sent — sometimes significantly after.

It doesn’t take much imagination to see what can go wrong: under normal conditions — or worse, under load or ISR latency — msTimerSecond may no longer correspond to the actual second when the hardware captured the nanoseconds field. This leads to fundamentally broken timestamps. There’s no way around it: if the driver exposes an API that returns both seconds and nanoseconds, then it must guarantee those values are coherent.

Expecting every application to detect and fix this at the user level is neither scalable nor robust — nor fair. The burden of ensuring consistency between timestamp components should lie in the driver, especially when:

• The ENET peripheral does support atomic timestamping, and has registers for 1588_TSTMP_SEC and 1588_TSTMP_NSEC, latchable together on TX.

• There is a crossbar mechanism in some SoCs (like RT117x) that allows incrementing seconds automatically on nanosecond overflow — i.e., the hardware can do this reliably without software intervention.

• The application note you reference (AN12149) — which I know very well, and have discussed here:
  https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Request-to-Update-AN12149-for-Modern-SDKs-and-Mi...
  — does not even cover RT117x, and uses a driver version from SDK 2.15 (ENET 2.7.1), which suffers from the same exact issue.

You say that in your ptpd-based example the seconds are handled differently in the application. That’s fine — but let’s be honest: if you’ve already solved the issue in the application, then why not apply that knowledge to fix the driver itself? That would benefit everyone — not just ptpd users — and make timestamping reliable out of the box.

Right now, the driver is returning partially valid timestamp data that looks fine but isn't — which is arguably worse than returning nothing at all. That is a recipe for long hours of debugging and inaccurate behavior in TSN, AVB, or PTP use cases.

Is there any plan to acknowledge this issue officially, and provide a proper fix in a future SDK?

Best regards,

Max

[Gavin_Jia]

Hi @mastupristi ,

Thank you for the further clarification!

In my previous reply, I simply indicated that the seconds in this driver are not used in the SW of PTPD. Today I received a response to this question from internal experts:

• The ENET peripheraldoes support atomic timestamping, and has registers for1588_TSTMP_SECand1588_TSTMP_NSEC, latchable together on TX.

The ENET and ENET_1G ip do not contain a register to store the TSTMP_SECOND unit, ENET_QOS has this register, and the fsl_enet_qos.c use this value from the register.

• There is acrossbar mechanismin some SoCs (like RT117x) that allows incrementing seconds automatically on nanosecond overflow — i.e., the hardware can do this reliably without software intervention.

Yes, crossbar is a good option to implement hardware second unit management, but that is a multi-peripheral usage, SDK just provide simple driver demo, they can not implement this on SDK driver level.

Whether a change will eventually be made in the fsl_enet.c driver is still subject to further internal investigation and research. 

Thank you for your contribution and efforts!

Best regards,
Gavin

[mastupristi]

Hi @Gavin_Jia 

do you have any news after these 3 weeks?

The ENET and ENET_1G ip do not contain a register to store the TSTMP_SECOND unit, ENET_QOS has this register, and the fsl_enet_qos.c use this value from the register.

If ENET and ENET_1G do not have such a register, or any other hardware tool to guarantee the consistency of seconds with nanoseconds, and if it is not possible to provide in the ENET(_1G) driver a “multi-peripheral” way to give this guarantee, then simply that API should be changed to provide only nanoseconds. This is my opinion. In fact, I now know that I cannot trust the seconds and so when I call it I will know that only nanoseconds are “true”

Yes, crossbar is a good option to implement hardware second unit management, but that is a multi-peripheral usage, SDK just provide simple driver demo, they can not implement this on SDK driver level.

Although there are other device drivers that use multiple peripherals inside them, I can understand your position. But as I have already said, if this is to be the driver it must provide all APIs whose result is consistent, and right now ENET_ReclaimTxDescriptor() does not give this guarantee, so it should be at least modified to no longer provide as a result the number of seconds that could be scrolled by the number of nanoseconds.

An example could be provided in demo_apps (instead of drivers) to demonstrate how to use multiple peripherals to synchronize seconds and nanoseconds.

Or the synchronization technique using multiple peripherals in an application note could be described.

Unfortunately, I don't think XBAR can be used because I don't see any connection to or from ENET(_1G)

So it will require you guys at NXP to find another way to guarantee the “true” consistency between seconds and nanoseconds even on ENET(_1G)

regards

Max