The gPTP stack does not output any information.

[FrankLiu2019]

I am using the S32K344 chip to debug the gPTP protocol stack. The S32K344 is acting as the Grand Master. My phy chip is DP83822. The manual for it states that it supports Start of frame detection for IEEE 1588 timestamp.

I used Wireshark to capture packets, but couldn't get any information.My clock and pin configuration are correct. I created a new demo "Gmac_Ip_InternalLoopback_T172_S32K344" and got that,I used the Eth_43 interface to test the loopback. The program indicated that the test was successful, but Wireshark couldn't capture any data.How can I capture the message information of gPTP? or any information with Eth_43 API?

This is the code for gmac_ip.

This is the code for Eth_43.

[PavelL]

Hello @FrankLiu2019 ,

It's not clear from your description, if you run gPTP stack in S32K344.

What version of S32K3 RTD do you use?

What version of S32K3 gPTP stack do you use?

Best regards,

Pavel

[FrankLiu2019]

HI Pavel

I sent the same message to both MCAL and LLD, but when capturing the waveforms with an oscilloscope, I found that the tx_clk of MCAL was 25M, while the waveforms on tx_d2 and other data lines were significantly faster than those of LLD by a factor of two. Why is this happening?

[PavelL]

Hello @FrankLiu2019 ,

Thank you for sharing all the details.

Your MII clock settings appear correct. However, to my knowledge, there is currently no active NXP EVB or RDB kit that uses MII mode, so I don't have hands-on experience with MII configurations.

May I ask — is there a specific reason you're opting for MII instead of RMII?

You might find this thread helpful regarding RMII clocking:

 https://community.nxp.com/t5/S32K/RMII-clock-for-S32K3/m-p/2053530  

As a starting point, I would recommend using the lwIP example from the TCP/IP stack package. Please ensure that S32K3 FreeRTOS 11.1.0 6.0.0 CD01 is installed prior to S32K3 TCP/IP Stack 3.0.0.

Regarding your observation:
If you're using Gmac_Ip directly, you must set the PHY interface mode manually before calling Gmac_Ip_Init(). Specifically, this line should be placed as the very first instruction in your bring-up code:

IP_DCM_GPR->DCMRWF1 = (IP_DCM_GPR->DCMRWF1 & ~DCM_GPR_DCMRWF1_MAC_CONF_SEL_MASK) | DCM_GPR_DCMRWF1_MAC_CONF_SEL(0U);

This is essential because the PHY interface mode is latched during GMAC reset.

If you're using the Eth_43_GMAC stack, this configuration is already handled internally during the call to Eth_43_GMAC_Init(), so no manual register setup is required.

Best regards,

Pavel

[FrankLiu2019]

Hi Pavel

Thank you for your reply. There is no particular reason to use the MII interface, because the hardware is designed this way.

I configured PTD10 as CLKOUT_RUN and used it to test whether the configured clock was correct. The results show that emac_mii_rmii_tx and emac_mii_rx are both correct at 25 MHz.

I traced the Eth_43_GMAC_Transmit function all the way to Gmac_Ip_SendFrame, and found that the TxFrameBuffer data was consistent with that at the LLD stage.

However, as I mentioned earlier, the clocks for TX_EN and TX_DATA in MCAL are faster.

I'm not familiar with MCAL. Could you explain the reason?

[PavelL]

Hello @FrankLiu2019 ,

Apologies in advance if any of the following points are already clear to you — I just want to ensure we’re aligned on the fundamentals before diving deeper.

Based on the information provided so far, it’s a bit difficult to fully assess the situation. But let me try to summarize a few key aspects:

1. Internal Loopback Limitation
   Naturally, if you're using internal loopback mode (Gmac_Ip_InternalLoopback), the frames never leave the GMAC block — they are not transmitted on the physical interface. Therefore, Wireshark (connected via USB-Ethernet or another PHY) will not be able to capture any traffic.

2. Configuration Tool Settings
   In the S32DS Configuration Tool, please double-check that both MCAL/Eth_43_GMAC and Drivers/Gmac are configured correctly. Pay special attention to:

   • EthCtrlMacLayerType
   • EthCtrlMacLayerSubType
   • PKT_FILTERRECV_ALL (this should be enabled to allow reception of all frames)

3. Recommended Starting Point
   As I mentioned earlier, I typically start with the lwIP example from the TCP/IP stack package. This allows me to verify basic Ethernet functionality using tools like ping or iperf from a laptop.

4. gPTP Example Usage
   You didn’t mention whether you’re running any of the gPTP examples provided in the RTD. If not, I would recommend starting with one of those to ensure the stack is initialized and operating correctly.

Best regards,

Pavel

[FrankLiu2019]

Hello  Pavel ，Thank you for your reply. It's a great honor to discuss with you.

Regarding the specific details you mentioned, I will respond to each one individually.
 

1. Internal Loopback Limitation
I believe that the  frames should  not be sent to the PHY at loopback mode. However, the opposite is true. In the LLD API, the  frames can be captured by Wireshark both the loopback mode and the non-loopback mode . In the MCAL API, the frame can be read through Eth_43_GMAC_Receive  at the loopback mode (the waveform captured by the oscilloscope is different from that in the LLD), while Wireshark cannot capture any data both the loopback mode and the non-loopback mode.

2.Configuration Tool Settings

3.Recommended Starting Point

I used the Gmac_Ip_InternalLoopback demo for testing and comparison. I believe this is more similar to Eth_InternalLoopback. I have used lwIP on this board, but RTD2.0. If the GMAC transmission fails, i don't think a more advanced protocol stack will success.

4.gPTP Example Usage

I am currently running the s32k344 gPTP protocol stack in gPTP_1.0 and RTD 6.0.It couldn't send any messages, so I used Eth_43_GMAC_Transmit to send test frames to verify whether the Ethernet had been correctly porting.

Best regards,

Frank

[PavelL]

Hello @FrankLiu2019 ,

Thank you again for your detailed feedback and for sharing your observations. Your setup is quite complex, involving multiple RTD versions, driver layers (LLD vs. MCAL), loopback modes, lwIP, gPTP, and a non-NXP PHY. To help isolate the issue and move forward efficiently, I would recommend the following structured approach:

Recommended Test Sequence

1. Choose a Single RTD Version and Driver Stack
   Please select one consistent configuration — ideally:

   • RTD 6.0.0
   • Eth_43_GMAC driver stack

   This will ensure compatibility with the latest examples and protocol stacks.

2. Run the Eth_InternalLoopback Example (with loopback enabled)
   This test verifies basic GMAC functionality using internal MAC loopback. It confirms that the EMAC is correctly initialized and can transmit and receive frames internally.

3. Run the Same Example with Loopback Disabled
   Disable MAC loopback and optionally enable promiscuous mode. This will help verify that frames are physically transmitted and received via the PHY. You can use Wireshark or an oscilloscope to confirm activity on the line.

4. Run the lwIP Example
   This will validate the full Ethernet stack, including IP layer. I’ve personally tested the lwIP example on all NXP S32K3 Ethernet boards and found it reliable for bring-up. You should be able to perform basic tests like ping or iperf from a laptop.

5. Run the gPTP Example
   Once basic Ethernet functionality is confirmed, you can proceed to gPTP testing. If the previous steps are successful, the gPTP stack should also operate correctly.

Important Notes

• For S32K3 EMAC, clock configuration is critical. The MAC-PHY interface must be correctly clocked before EMAC initialization.
• Ensure that the PHY is in MII mode and is generating the required clocks (e.g., TX_CLK) before the EMAC is brought up.
• If the first example (Eth_InternalLoopback ) works correctly, it’s a strong indication that the clocking and EMAC setup are valid - and subsequent examples should also work.
• Even for the Eth_InternalLoopback example, the clocks and pin configuration must match your hardware design - otherwise the EMAC may not initialize correctly.

Bets regards,

Pavel

[FrankLiu2019 · Accepted solution]

Hello Pavel

Thank you for your reply.

I have solved this problem. The fundamental cause is that the order of initializing the port and clock was incorrect.

The correct sequence is to initialize the port first, and then initialize the clock. If the order is reversed, it will cause the clock on the MAC to be incorrect, but data can still be received in the loopback mode.

Bets regards,

Frank

[FrankLiu2019]

Some additional information

[FrankLiu2019]

HI Paverl ,I'm sorry that I didn't mention it.

My operating environment is 

• S32 Design studio 3.6.0 (Updated to 3.6.2) with NXP GCC 10.2.0; Version 1728; Build
id: 202307190908
• S32K3xx RTD 6.0.0 (SW32K3_S32M27x_RTD_R21-11_6.0.0_D2506)

• SW32K3xx_M7_gPTP_1.0.0_D2507

Best regards