topic Re: Regarding TSN PTP Function Configuration in i.MX Processors

Regarding TSN PTP Function Configuration

hankwang — Wed, 19 Aug 2026 01:45:20 GMT

Hi,

I have a question regarding PTP implementation. We need to read IMU data paired with a gPTP timestamp.

Our hardware pin configuration is as follows:

CCM_CLKO1 (AH20) <- 1588_TRIG
CCM_CLKO3 (AK20) <- IMU Sensor Interrupt
CCM_CLKO4 (AJ21) (IMU PPS) -> CCM_CLKO1 (1588_TRIG)

Based on this, our understanding of the Pin Mux configuration is:

CCM_CLKO4 needs to be configured as ALT1 (1588_PP2)
CCM_CLKO3 needs to be configured as ALT1 (1588_TRIG2)
CCM_CLKO1 needs to be configured as ALT1 (1588_TRIG1)

When an IMU interrupt occurs, the hardware signal triggers the 1588 timestamp mechanism on the i.MX95, allowing the SoC to capture the PTP hardware timestamp at the exact moment of the event.

Upon receiving the IMU interrupt, the application reads the IMU data and retrieves the corresponding PTP timestamp, then combines both into a single data package. Please confirm if our understanding is correct.

Additionally, please help us verify the following two points:

Can the i.MX95 capture the PTP hardware timestamp at the exact time of the IMU interrupt via the aforementioned 1588_TRIG / 1588_PP hardware signals?
Does the Linux / NXP driver provide a corresponding API or /dev/ptpX interface for the application to retrieve this hardware-latched timestamp?

Thank you for your support, and I look forward to your reply

Re: Regarding TSN PTP Function Configuration

pengyong_zhang — Wed, 19 Aug 2026 09:15:10 GMT

Hi @hankwang

Q1. No problem.

Q2. By connecting the IMU's INT/DRDY input using 1588_TRIG1/TRIG2 (external trigger input), the NETC Timer will hardware-latch a nanosecond-level PTP timestamp at the exact moment of the interrupt edge (stored in the ETTS FIFO and generating an interrupt). The application can then read this timestamp through the standard EXTTS interface on /dev/ptp0.

>>>

Re: Regarding TSN PTP Function Configuration

hankwang — Thu, 20 Aug 2026 03:16:24 GMT

Hi @pengyong_zhang Thank you for the update.

We have encountered an issue regarding interrupt handling. When the SoC pin is in default GPIO mode, the IMU driver receives interrupt notifications without any problem. However, we need to know how to receive interrupt notifications when the pin is switched to ALT1 mode (1588_TRIG).

Our workflow requires waiting for an interrupt from the IMU, and then reading both the IMU data and the gPTP timestamp.

Re: Regarding TSN PTP Function Configuration

hankwang — Thu, 20 Aug 2026 07:19:17 GMT

@pengyong_zhang

Based on our research, the current practice requires routing the IMU interrupt signal simultaneously to both the SoC's 1588_trigger pin and a SoC GPIO pin. Once the IMU generates a signal, the GPIO pin notifies the application to fetch the data, while the 1588 trigger pin latches the precise timestamp of the interrupt.

The application workflow is as follows:

The IMU generates an interrupt signal.
The application receives the interrupt notification, and the SoC latches the gPTP timestamp at the same time.
The application reads the IMU data and the gPTP timestamp, then packages them into a single data bundle.

We would like to know if the IMU interrupt signal needs to be split and routed separately to both the SoC 1588_trigger pin and the SoC GPIO pin. Is this a common industry practice?

Does NXP have a similar approach or demo?

Re: Regarding TSN PTP Function Configuration

pengyong_zhang — Fri, 21 Aug 2026 06:57:52 GMT

HI @hankwang

No, there is no need to be split or routed to both the 1588_TRIG pin and a GPIO pin simultaneously.

The NETC Timer's EXTTS (External Timestamp) input on i.MX95 is itself capable of generating a CPU interrupt when an external pulse is received on the TMR_1588_TRIG pin.

B.R