Skip to main content
Michi1225
Visitor
October 4, 2026
Question

STM32N6 RGMII RX Traffic but no Rx Packets

  • October 4, 2026
  • 0 replies
  • 10 views

Hello,

I am facing some issues with NetXDuo, where i see traffic on the RGMII RX lines, but RX DMA does not process any frames / no interrupts fire. I have the following setup:

I am using a custom board based on the STM32N657 with an ADIN1300 Gigabit Ethernet PHY connected over RGMII.

Software stack:

  • STM32Cube FW_N6 V1.3.0
  • ThreadX
  • NetXDuo
  • Static IPv4 configuration
  • Secure only application
  • Caches disabled

The PHY is configured over MDIO and link comes up successfully. The resolved PHY speed matches with what is seen on the host side and with the MAC speed configuration.

What is working:

The PHY side appears to be working correctly. For example, when forcing 10Mbps, i can clearly probe the RGMII lines and see:

  • RX_CLK present
  • RX_CTL activiy for each incoming ARP/ping
  • RXD0..3 activity during the frame

This confirms that Ethernet frames are being received by the PHY and forwarded onto the RGMII interface toward the MCU.

The following have also been checked/tried:

  • RGMII pin mux
  • tried disabling broadcast filtering
  • explicit descriptor memory placement

The MAC speed bits are configured to match the PHY link, for example at 100Mbps: 

  • RE = 1
  • PS = 1
  • FES = 1

The Ethernet receive queues are enabled (MACRXQC0R = 0x0000000A).

I have also found some suspicious / wrong code generation issues:

Firstly, the generated _nx_driver_hardware_enable() does not call HAL_ETH_Start()/HAL_ETH_Start_IT(). After adding the ETH_Start_IT() manually.

I also found, that ETH_PHY_1000MBITS_SUPPORTED was not defined, so the 1Gbps case in the NetX driver was compiled out. I corrected that as well; neither change fixed RX.

Current problem:

Despite seeing valid RGMII RX traffic at the MCU pins, the Ethernet RX DMA does not appear to process any frames. After calling HAL_ETH_Start_IT() I observe the following RX DMA registers:

MACRXQC0R          = 0x0000000A
MTLRXQDMAMR        = 0x00000100

DMA_CH0.DMACRXCR   = 0x00200C01
DMA_CH0.DMACRXDLAR = 0x3409D480
DMA_CH0.DMACRXDTPR = 0x3409D4C8
DMA_CH0.DMACRXRLR  = 3

DMA_CH0.DMACCARXDR = 0x3409D480
DMA_CH0.DMACCARXBR = 0x00000000
DMA_CH0.DMACSR     = 0x00000000

When repeatedly sending ARP requests or pings from the host, I do not see any receive-side activity in the DMA:

  • DMACCARXDR remains unchanged
  • DMACCARXBR remains unchanged
  • DMACSR remains 0
  • no ETH interrupt is generated

At another point during debugging, I also observed DMADSR = 0x00040400, while both RX DMA channels had DMACRXCR = 0x00200C01. The RX descriptor base and tail pointers appear valid, and explicitly placing/aligning the descriptor tables at fixed RAM addresses did not change the behavior.

The main contradiction I am currently trying to understand, is that the PHY is visibly presenting incoming frames on the RGMII lines, but the RX receive path of the MCU shows no corresponding descrptor movement or interrupt activity.

The application runs in Secure mode. I am not entirely sure whether any additional RIF/RISAF configuration is required for ETH1 DMA access. I left the RISAF configuration at its default settings, so I would also appreciate confirmation on whether any specific RIF/RISAF setup is required for ETH1 or its internal DMA.


 

Terms & ConditionsAccessibility statement