GMAC RX interrupt of S32K328 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? Re: GMAC RX interrupt of S32K328 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 Re: GMAC RX interrupt of S32K328 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. Re: GMAC RX interrupt of S32K328 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-RTD600/ta-p/2355872
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 Re: GMAC RX interrupt of S32K328 Hello： I read the frame info by RTD function Eth_43_GMAC_GetRxStats, it looks has drop event. zyt_0-1787017861198.pngzyt_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. Re: GMAC RX interrupt of S32K328 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 Re: GMAC RX interrupt of S32K328 Hello: 1.I use RGMII 2. I use RTD 6.0.0. 3. I use the Eth_43_GMAC driver. 4. Interruption is like the following: zyt_0-1786962682804.pngzyt_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. Re: GMAC RX interrupt of S32K328 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
View full article
