GMAC RX interrupt of S32K328

[zyt]

I use GMAC of S32K328, and want to use interrupt method to receive package from my PC. But found some differnt phenomenon：

1. Interrupt handler GMAC0_CH0_RX_IRQHandler can be called, and receive package normally.

2. Many seconds GMAC0_CH0_RX_IRQHandler called after PC send package.

3. GMAC0_CH0_RX_IRQHandler can't called, and no package receive?

What might be the reason? How to solve that?

[PavelL]

Hello @zyt ,

Could you please provide a few more details about your setup?

1. Which MAC/PHY interface are you using on S32K328, for example MII, RMII or RGMII?

2. Which S32K3 RTD version are you using?

3. Are you using the AUTOSAR MCAL Eth_43_GMAC driver or the lower-level GMAC IP driver?

4. Could you share the relevant interrupt configuration and the implementation of GMAC0_CH0_RX_IRQHandler?

5. What kind of frames are sent from the PC, for example ping/ICMP, UDP, raw Ethernet frames, broadcast or unicast frames?

As a reference test, I would also recommend trying to reproduce the behavior using an adapted S32K3 Ethernet/lwIP example first. This can help to separate a basic GMAC/PHY/clock/configuration issue from an application-specific interrupt or RX-buffer handling issue.

Regarding the symptoms, if the RX interrupt is sometimes called and the frame can be received correctly, the basic RX path is likely at least partially working. However, the inconsistent behavior may still be caused by one of the following points:

- RX buffer or descriptor handling: after a received frame is processed, the RX buffer/descriptor must be returned back to the driver/DMA. If this is not done correctly, RX buffers may become unavailable and further RX interrupts may stop or become inconsistent.

- Interrupt handling: please make sure that the RX interrupt is configured for the correct GMAC channel and that the expected driver interrupt handler/status clearing flow is used. If the interrupt status is not cleared correctly, the following RX events may not be reported as expected.

- Cache/memory coherency: if cache is enabled, please verify that the GMAC descriptors and RX buffers are placed in a suitable non-cacheable memory region, or that the required cache maintenance is performed. Otherwise, the CPU may see stale descriptor status or stale received data.

- Packet filtering/MAC address: for debug purposes, please try enabling receive-all/promiscuous mode temporarily. This helps to check whether the frame is rejected by the MAC address filter, VLAN filter, or another packet filter setting.

- Frame type and PC behavior: if the PC sends IP traffic such as ping, the first frames may be ARP requests/replies before ICMP traffic is sent. If ARP resolution fails or some frames are filtered/dropped, it may look like the interrupt is delayed by several seconds because the PC retransmits ARP or the application retries later.

- PHY link and clocks: please also confirm that the PHY link is up and that the required input clocks for the selected MII/RMII/RGMII interface are present and stable.

Please share the above configuration details and, if possible, the GMAC DMA/MTL/MAC status registers after the failure. This should help identify whether the issue is related to interrupt configuration, RX descriptor/buffer handling, packet filtering, or the external PHY/interface setup.

Best regards,

Pavel

[zyt]

Hello：

1. I use RGMII

2. I use  RTD 6.0.0.

3. I use Eth_43_GMAC driver.

4. Interrupt is like below:

zyt_0-1786962682804.png

5. I send unicast frames with python script.

All the packages I send are the same, and GMAC0_CH0_RX_IRQHandler is from RTD which is the lowest handler like picture above.

[PavelL]

Hello @zyt ,

Thank you for the details.

Please also check Pins/Clocks/device_init() accordingly to this thread:

S32K358 - GMAC Clock Configuration

From the screenshot, the GMAC0 interrupt vectors seem to be configured and mapped to the RTD handlers, including GMAC0_CH_0_RX_IRQHandler. Since this handler is sometimes entered and the frame can be received, the basic interrupt routing does not look completely wrong.

However, when using the AUTOSAR Eth_43_GMAC driver, please also check the receive flow above the low-level IRQ handler. The RX interrupt handler itself is not usually the complete application-level receive processing. The application or upper layer still needs to call the expected Eth_43_GMAC receive API flow, for example Eth_43_GMAC_Receive(), so that the received frame is read from the driver and passed further through the configured callback path.

Please check the following points:

1. Please confirm that Eth_43_GMAC_Receive() is called after the RX interrupt event, or periodically from your main/task context, according to your application design. If the interrupt occurs but the received frame is not consumed from the RX buffers, the following frames may not be received as expected.

2. Please verify that the received unicast frame destination MAC address exactly matches the MAC address configured in the GMAC driver. For debug purposes, you can temporarily enable receive-all/promiscuous mode to exclude MAC filtering as the reason.

3. Please check which RX queue/FIFO is used. Your screenshot shows RX interrupt handlers for CH0, CH1, and CH2. If the packet filter or queue configuration routes frames to another RX queue, the application must call the receive function with the corresponding FIFO index and handle that queue correctly.

4. Please verify RX buffer/descriptor availability. After a received frame is processed, the driver must be able to reuse or obtain RX buffers again. If the RX buffers are exhausted, the first frame may be received correctly, but later frames may be delayed or lost.

5. If cache is enabled, please verify that the GMAC descriptors and RX buffers are placed in a non-cacheable memory region, or that the required cache maintenance is performed. Otherwise, the CPU may see stale descriptor status or stale received data.

6. Since the frames are sent from a Python script as unicast frames, please also confirm by Wireshark that the PC really sends the frames continuously with the expected destination MAC address. If some frames require address resolution or if the destination is not reachable as expected, the PC side may introduce retries or delays, which can look like delayed RX interrupt behavior on the MCU side.

As a reference, I would recommend comparing the project with an adapted S32K3 Ethernet/lwIP example first. This can help to confirm that the RGMII PHY interface, clocks, MAC address, and basic RX path are working before focusing on the custom AUTOSAR Eth_43_GMAC interrupt receive implementation.

If the issue still remains, please share the Eth_43_GMAC receive part of the application, especially where Eth_43_GMAC_Receive() is called, the RX FIFO configuration, MAC address/filter configuration, and the GMAC DMA/MTL/MAC status registers after the failure.

Bets regards,

Pavel

[zyt]

Hello：

I read the frame info by RTD function Eth_43_GMAC_GetRxStats, it looks has drop event.

zyt_0-1787017861198.png

The RX flow all handled by RTD like below, I didn't modify.

GMAC0_CH0_RX_IRQHandler -> GMAC_RxIRQHandler -> Eth_43_GMAC_RxIrqCallback -> Eth_43_GMAC_Receive

What might be the reason for this? Thanks.

[PavelL]

Hello @zyt ,

RxStatsDropEvents suggests that some frames are seen by the GMAC, but are dropped somewhere in the RX path. This may be related to RX resource availability, RX FIFO/queue handling, descriptor/buffer availability, packet filtering or the upper-layer receive processing.

Please try the following checks:

1. Please send the same unicast frames slowly from the PC, for example one frame at a time or with a larger delay between frames, and compare the RX statistics before and after the test. If RxStatsDropEvents no longer increases, the issue may be related to RX buffer recycling, processing time, or burst traffic from the PC.

2. Please repeat the test with broadcast frames and then with unicast frames addressed exactly to the MAC address configured in the GMAC driver. This will help to exclude a MAC address/filtering issue.

Please also verify the RGMII clock and peripheral configuration. As a reference, I have published an S32K358 GMAC example on the NXP Community:

https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K358-GMAC-1G-lwIP-FreeRTOS-S32DS-3-6-1-R...

Please note that this example is for S32K358, not S32K328, so it must not be copied directly without checking the S32K328 pinout and clock configuration. However, it can be used as a reference for the overall clock setup, Eth_43_GMAC configuration and the DCMRWF register workaround.

If possible, could you please also share your zipped project? Without the project, it is difficult to determine whether the drops are caused by configuration, RX resource handling, queue routing or the application receive path.

Best regards,

Pavel

[zyt]

Hello:

I have tried both unicast frames or broadcast frames, the delay between every frame is 1 second, I think it's enough slow.

The phenomenon is the same, there is no RxStatsDropEvents at bigining, but it appears after a few frames.

My EB configuration is like attachment, please help to check if it's convenience for you.

Thanks.

[PavelL]

Hello @zyt ,

Thank you for sharing the configuration. Since I do not have EB tresos available, I reviewed the GMAC configuration manually from the provided files.

I compared your Eth_43_GMAC configuration with a working S32K358 GMAC 1G lwIP FreeRTOS reference project. One significant difference is the Egress FIFO configuration. In your project, the Egress FIFO buffer length is configured to 128 bytes and the MTL Egress queue size is 256 bytes. In the reference project, the Egress FIFO buffer length is 1536 bytes and the MTL Egress queue size is 4096 bytes.

If your application transmits any frames or if the upper layer sends responses, this small TX/Egress configuration may be too limited for standard Ethernet frames, especially in 1G RGMII mode. As a test, please try increasing:

- EthCtrlConfigEgressFifoBufLenByte to 1536

- EthCtrlConfigMTLEgressQueueSizeInBytes to 4096

For the RX path, the RX buffer length itself is 1536 bytes, which looks reasonable. However, your MTL Ingress queue size is also 1536 bytes, while the reference project uses 4096 bytes. Therefore, as another test, please also try increasing:

- EthCtrlConfigMTLIngressQueueSizeInBytes to 4096

In addition, for debugging, please temporarily enable receive-all mode. Your current configuration has PKT_FILTER_RECV_ALL disabled, while the reference project enables it. This can help to exclude MAC filtering from the analysis.

There are also other differences like EthEnableCacheManagement and

EthCtrlReleaseResourceAfterReception, but this is not necessarily wrong.

Best regards,

Pavel

[zyt]

Hello:

I follow the configuration as your advice like below:

zyt_0-1787045193851.png

zyt_1-1787045222335.png

zyt_2-1787045282610.png

zyt_3-1787045358003.png

The EthCtrlReleaseResourceAfterReception is gray could not be modified, because it's only applied when external data buffers are used.

zyt_4-1787045508280.png

After modify these, the result is the same, RxStatsDropEvents appeared.

zyt_5-1787045605969.png

The modified configuration file is like attachment.

Could you give some more advice? Thanks.

[zyt]

Sorry, I forget you do not have EB.

The attachment is the generated file after modification.

[PavelL]

Hello @zyt ,

Thank you for the update. I reviewed your files again and I haven't seen anything suspicious. If the behavior remains unchanged after increasing the FIFO/queue resources, I would not continue changing configuration parameters blindly. The next step should be to identify which frames are actually counted as RxStatsDropEvents. Please check whether the drop counter increases only when your Python unicast frames are sent or also when no Python traffic is running, as PC-side background traffic or filtered frames may also affect the RX statistics.

Bets regards,

Pavel

[zyt]

Hello：

Base my test, either broadcast or unicast frame can be drop, phenomenon are the same, and the PC will not send any other frames beyond my control.

I find one thing special, when sometimes I send a frame, the RTD function  Gmac_Ip_ReadFrame go into below branch:

zyt_0-1787101369298.png

It's because (((Bd->Des3 & GMAC_RDES3_OWN_MASK) != 0U) 

zyt_1-1787101442166.png

The function call flow is like below, all belong to RTD driver:

zyt_2-1787101651452.png

At this time, Eth_43_GMAC_Receive will not read data of GMAC buffer.

So after some times, the fifo of GMAC is full, so the frame come later will drop.

Do you think my analysis make sense？？

If so, why (((Bd->Des3 & GMAC_RDES3_OWN_MASK) != 0U) happened? What might be the reason?

Thans.

[PavelL]

Hello @zyt ,

Thank you for the detailed debugging information. Your observation is useful, but I would interpret the OWN bit differently.

When RDES3.OWN is set, the RX descriptor is owned by the DMA, not by the CPU. Therefore, Gmac_Ip_ReadFrame() correctly reports GMAC_STATUS_RX_QUEUE_EMPTY because the current descriptor has not yet been completed and returned to software. An RX descriptor with OWN = 1 is normally available to DMA, so this condition alone does not indicate that the RX ring is blocked or that the GMAC FIFO must become full.

The important question is why the RX interrupt callback is entered while RxCurrentDesc points to a descriptor that is still owned by DMA. The interrupt may have been caused by another RX/DMA status condition, or the completed descriptor may not match the current software descriptor pointer.

The generated code places the GMAC RX descriptors and RX data buffers into a non-cacheable MemMap section. However, I do not see the linker map file in the shared project, so I cannot verify whether this section is actually mapped to a non-cacheable memory region in the final executable.

Could you please share the linker map file generated by the build? In particular, I would like to check the final addresses and sections of:

- GMAC_0_RxRing_0_DescBuffer

- GMAC_0_RxRing_0_DataBuffer

- GMAC_0_TxRing_0_DescBuffer

- GMAC_0_TxRing_0_DataBuffer

Please also confirm whether GMAC_STATUS_RX_QUEUE_EMPTY occurs on the first Gmac_Ip_ReadFrame() call after the RX interrupt or only after one or more frames have already been read successfully. An OWN bit set to 1 may simply indicate the normal end of the receive loop, where the next descriptor is already owned by DMA and waiting for another frame.

Best regards,

Pavel

[zyt]

Hello：

The problem is caused by cache, when I delete macro D_CACHE_ENABLE from my project, all things go normal.

Is that mean cache coherency problem?

But when I add D_CACHE_ENABLE and Check the box below, the problem also occured.

zyt_2-1787215536381.png

I didn't modify any variable region settings of RTD, and I checked the RTD driver, GMAC_0_Rx/TXRing_0_Desc/DataBuffer is in no_cache region, but others don't, such as Gmac_apxState, it's in mcal_bss which is cached. It that reasonable?

zyt_4-1787215940789.png

So how to solve this problem with D_CACHE_ENABLE added?

Thanks.

[PavelL]

Hello @zyt ,

Thank you for the update. Yes, the fact that the issue disappears when D_CACHE_ENABLE is removed strongly indicates a cache coherency or memory-region configuration issue.

However, Gmac_apxState itself does not normally need to be placed in non-cacheable memory. It contains CPU-side driver state and pointers and is not directly accessed by the GMAC DMA. The important objects shared between the CPU and GMAC DMA are the hardware descriptor rings and the RX/TX data buffers.

I checked the generated files shared previously. In Gmac_Ip_Cfg.h, the generated configuration contained:

#define GMAC_HAS_CACHE_MANAGEMENT (STD_OFF)

At the same time, Gmac_Ip_Cfg.c places the GMAC RX/TX descriptors and data buffers into the NO_CACHEABLE MemMap section. Therefore, the generated configuration appears to rely on these objects being mapped to a genuinely non-cacheable memory region rather than on explicit cache maintenance by the GMAC driver.

Please regenerate the complete RTD configuration and perform a clean build after enabling EthEnableCacheManagement. Then please check the value of GMAC_HAS_CACHE_MANAGEMENT in the Gmac_Ip_Cfg.h file that is actually compiled. If it still remains STD_OFF, the checkbox is not enabling the low-level GMAC cache maintenance in the generated build.

Please also share the linker map file and the relevant linker/MPU memory-region configuration. We need to verify the final sections and memory attributes of:

- GMAC_0_RxRing_0_DescBuffer

- GMAC_0_RxRing_0_DataBuffer

- GMAC_0_TxRing_0_DescBuffer

- GMAC_0_TxRing_0_DataBuffer

The generated source places these objects into a non-cacheable section, but the linker script and MPU configuration must also map that section to a genuinely non-cacheable region. Otherwise, the CPU may read a stale cached descriptor value, for example OWN = 1, even after the DMA has updated the descriptor in RAM.

I would not recommend moving Gmac_apxState to non-cacheable memory at this point. The first step is to verify that all DMA-shared descriptors and buffers are placed in the correct non-cacheable MPU region, or alternatively that GMAC cache management is really enabled in the compiled driver configuration.

Best regards,

Pavel