We are using the NUCLEO-H753ZI family of boards with the specific MCU being STM32H753ZIT6.
We were following this tutorial: https://community.st.com/t5/stm32-mcus/how-to-create-a-project-for-stm32h7-with-ethernet-and-lwip-stack/ta-p/49308/page/2/show-comments/true
The difference between the hardware used in the tutorial and the hardware we use is that instead MII, which is what is used in the tutorial, we are using RMII
Even though we were following the tutorial to the dot, our implementation is still not working. We have reverted back from the lasted implementation of STM32CubeIDE to STM32CubeIDE 1.9.0 as mentioned in the tutorial as well.
CURRENT DIAGNOSIS:
We have confirmed with a digital oscilloscope that when we are pinging the STM32H753ZIT6, the CRS_DV Pin, which is pin 11, is not going high at all. We have observed, using the oscilloscope, that in our PHY (LAN8742A) on pin 8 that we are able to receive packets and that it is unable to transmit packets using TX pins.
This leads us to believe that the transmission of packets from the PHY to the MAC is not working for some reason.
So what we've said before is for the NUCLEO-H753ZI prebuilt board. This next part is for a custom board that uses the same STM32H743XIH6 as its MCU but uses the same PHY as the prebuilt board.
WHAT IS CONFIRMED WORKING:
REF_CLK (50MHz): PA1 receives valid 50MHz from LAN8742 pin 14. DMA software reset clears in 0ms every time, proving the clock is present and stable.
SYSCFG RMII Selection: SYSCFG_PMCR ETH_SEL = 4 (RMII mode). In the original production firmware this was 0 (MII mode) — we identified and fixed that. HAL_ETH_Init does not clobber it.
MDIO Communication: PHY ID reads correctly as 0x0007:0xC131 (LAN8742A). All PHY registers are readable and writable via MDIO.
GPIO AF Mapping: All 9 RMII pins confirmed AF11: PA1 (REF_CLK), PA2 (MDIO), PA7 (CRS_DV), PB11 (TX_EN), PB12 (TXD0), PB13 (TXD1), PC1 (MDC), PC4 (RXD0), PC5 (RXD1).
PHY Link/Auto-Negotiation: Link comes up at 100M Full-Duplex. Takes ~70-145 seconds. BSR shows link up, AN complete, ANLPAR = 0xDDE1. Speed indication register (SSR) reads correctly.
MAC Internal Loopback: Previously confirmed working by the user — MAC can TX and RX its own frames internally without RMII. MAC CRC generation/checking is functional.
CRS_DV Signal: GPIO bypass test on PA7 shows transitions (54-112 in 5 seconds) when traffic is present. The PHY IS driving receive data to the STM32 pins.
MTL Rx Queue Activity: MTL_RxQ_DBG shows pktCnt incrementing (frames entering the MTL FIFO) and RxQ state=1 (actively reading frame data). Frames DO pass from MAC through MTL.
What Is Broken
RX: 100% CRC failure on every received frame. MMC RxOK counter stays at zero permanently. CRC error counter climbs steadily (correlated with traffic rate from PC). Alignment errors also present. This happens at both 100Mbps and 10Mbps, on both the custom board and a prebuilt dev board.
TX: Not yet proven working. Bare-metal DMA descriptor TX attempts show TxOK=0 with DMACSR TBU (Transmit Buffer Unavailable) errors. HAL_ETH_Transmit was not yet tested (last firmware version). The Python sniffer on the PC never saw frames from the board's MAC address.
MACRxQCtrl0 (RXQ0EN) refuses to write. Tried before and after RE=1, tried after full DMA SWR — always reads back 0. However, frames still enter MTL despite this, so it may not be the blocking issue for RX.
Link takes extremely long (70-145s). PHY SMR register shows MODE=7 (reserved), suggesting strap pin configuration is not ideal. This doesn't prevent link-up but may indicate a strap issue.
Any ETH register manipulation before link-up prevents link from establishing. The DMA SWR or any MAC register writes before auto-negotiation completes seem to interfere with the PHY's negotiation process. Link only comes up reliably when the firmware waits passively (MDIO reads only).
