STM32MP133C Ethernet/PHY issue

Aerokii · ‎2025-12-16

Hello! I'm working on bringing up a bare-metal STM32MP133C bare-metal on the dev kit from DIGI, using the HAL layer from ST. The problem I'm running in to is we're getting stuck on HAL_ETH_Init as when we enable the MAC clock, DMAMR's 0 bit (the reset bit) is stuck at 1, causing a timeout.

From reading the reference manual, all related clocks need to be enabled for the reset to work, so I'm operating under the assumption there's a clock issue. I've initialized/configured the peripheral clock for PLL4, I'm enabling the relevant GPIO clocks, along with the ethernet clocks ETH1CK, ETH1TX, ETH1RX, and ETH1MAC. This leads me to believe the issue may be with the PHY clock. As we're using the Marvell PHY that comes with the board, I've (attempted) to set it so the PHY uses PLL4 by changing the appropriate bits in syscfg's PMCSETR.

I figured that would be enough to get it all going... but it still seems I'm missing something. I've tried generating the code from CubeMX to see if it was a GPIO issue with no luck. I've attached the (very rough) file I'm working out of at present.

Thanks in advance for any support provided!

Pwxn · ‎2025-12-17

Hello,

Could you give me the version of CubeMX you're using? A similar issue where ETH_DMAMR_SWR stay up during the Init function was fixed with the 6.16 release.

You can applied a Work Around to your current version of CubeMX by replacing __HAL_RCC_ETHxMAC_CLK_ENABLE() (x={1,2}) by __HAL_RCC_ETHxCK_CLK_ENABLE() on line 423 and 505 of stm32mp13xx_hal_msp.c

Please use latest version of CubeMX if it's not the case.

Regards

Aerokii · ‎2025-12-17

Of course! It was originally done via 6.15, but I upgraded to 6.16.1 this morning. Sadly it was to no real success, as I'd already added that clock manually.

PatrickF · ‎2025-12-17

Hi,

you should setup the 'magenta' clocking path to use 125MHz root from PHY (CLK_125 pin) .

Did you check the 125MHz PHY output clock presence with an oscilloscope ?

Have you set high the PHY reset GPIO before initializing the GMAC (sound it is PI2, to be double checked with DIGI documents) ?

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
NEW ! Sidekick STM32 AI agent, see here

PatrickF · ‎2025-12-17

Hi @Aerokii,

I also see in your code some GPIO mistakes (still to be confirmed with DIGI documents), for instance:

ETH1_RX_CLK seems to be on PD7-AF10 while you used PA1-AF11

ETH1_CLK125 is not used in your code (should be on PF12-AF11), but you might want to use 125MHz from RCC.

You should check carefully each PHY signals connection usage to STM32MP13 within DIGI HW.

SOM: https://www.digi.com/resources/documentation/digidocs/pdfs/90002551.pdf

BaseBoard: https://hub.digi.com/dp/path=/support/asset/connectcore-mp133-dvk-schematics-pdf/

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
NEW ! Sidekick STM32 AI agent, see here

Aerokii · ‎2025-12-17

Hello again!

I've updated the GPIO, at least for ETH1 since that's what I'm focusing on now. It's based on ccmp13-dvk.dtsi along with some confirmations from the provided digi documents. At present I don't have access to a scope, a continuing frustration I've brought up with management, but unrelated to this ticket beyond that.

Double checking the sent file... I did seem to be using PD7 with AF10, so that shouldn't be an issue. I've double checked it, and I'm attaching the updates. I've still no luck after enabling PF12 in mode AF11, nor with manually setting to 125MHz from the RCC. Still a puzzler, it seems.

PatrickF · ‎2025-12-18

Hi,

Did you check the PHY reset pin is released by your SW (sound like it is PI2) ? If you don't have scope, a voltmeter or checking GPIO IDR with debugger might be enough.

Regards

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
NEW ! Sidekick STM32 AI agent, see here

Aerokii · ‎2025-12-18

At present, PI2 is at the reset value (0) according to the debugger. For fun I've tried setting/resetting it, but there's no change in result. I also wasn't able to confirm within the documents that PI2 is the right pin for that. I'll continue looking through the docs to see if I can confirm the correct pin for that if applicable.

FUTURE NOTE: Pi2 is the correct pin. It wasn't listed (obviously) for the reset function in the ConnectCore doc, but in the schematics it is.

PatrickF · ‎2025-12-19

Have you carefully checked the RM figure related to ETH clocking (see this previous post) and confirm your settings inside SYSCFG_PMCSETR and RCC are ok to have clock going to GMAC.

You probably need to check:

- ETH1_SEL[2:0]=1 for RGMII

- ETH1_CLK_SEL = 0 if 125MHz clock come from ETH1_CLK125 pin (from PHY),
or 1 if coming from PLL (RCC should define PLL4 or PLL3 as well as correct ETH1_SRC to ensure 125MHz clock path is ok)

- ETH1_REF_CLK_SEL = 0

- all GMAC clocks are enabled in RCC

Maybe worth to ask for some help to DIGI (e.g. https://docs.digi.com/resources/documentation/digidocs/embedded/dey/5.0/ccmp13/iomux_index.html ).

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
NEW ! Sidekick STM32 AI agent, see here

Aerokii · ‎2025-12-19

Yup, RGMII selected in ETH1_SEL[2:0]. Prepped it for ETH2 as well. ETH1_CLK_SEL is set to 0, though for fun I've tried 1 as well with PLL4 set up to provide the clock. GMAC clocks... I don't see any in RCC. Am I missing something?

And sure, I'll pester Digi, a fine idea as well. Thanks!