STM32H573: ETH SWRESET fails, ETH_DMAMR_SWR stays set, timeout
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-02-03 10:18 AM
I want to initialize the STM32H573 ETH module using the STM32CubeMX code generator (see ioc file attached). It should run in MII mode using an external transceiver.
I kept the configuration unchanged, however it always jumps to ErrorHandler, because HAL_ETH_Init returns HAL_ERROR on timeout of ETH_DMAMR_SWR at the following routine:
SET_BIT(heth->Instance->DMAMR, ETH_DMAMR_SWR);
/* Get tick */
tickstart = HAL_GetTick();
/* Wait for software reset */
while (READ_BIT(heth->Instance->DMAMR, ETH_DMAMR_SWR) > 0U)
{
if (((HAL_GetTick() - tickstart) > ETH_SWRESET_TIMEOUT))
{
/* Set Error Code */
heth->ErrorCode = HAL_ETH_ERROR_TIMEOUT;
/* Set State as Error */
heth->gState = HAL_ETH_STATE_ERROR;
/* Return Error */
return HAL_ERROR;
}
}
From what I've read on this forum, the ETH somehow needs an external clock input from the transceiver. However, ETH_REF_CLK is only defined in RMII mode, but I want MII mode with RX and TX clocks. Does it still need permanently running clock? ETH_RX_CLK is currently served from the transceiver with 2.5 MHz (in 10 Mbps mode), the ETH module itself is clocked 100 MHz from PLL1Q:
I even tried rising the timeout threshold, but even 50 s is failing. Any ideas on how to get the initialization through?
Solved! Go to Solution.
- Labels:
-
DMA
-
Ethernet
-
STM32CubeMX
-
STM32H5 Series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-02-04 9:23 AM
Figured out the error. I was missing the propagation of the reset signal to the external PHY for bootstrap configuration. Just added it to the HAL_ETH_MspInit.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-02-03 1:25 PM
ETH_REF_CLK is for RMII. ETH_RX_CLK and ETH_TX_CLK are for MII.
I observed HAL_ETH_Init failing similarly for the STM32H7S78-DK last year and posted that and a fix at https://community.st.com/t5/stm32cubemx-mcus/bugs-caveats-misc-fixes-stm32h7s-cube/td-p/710992. For clarity, the peripheral clock's fix in HAL_ETH_MspInit was:
PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_ETH1REF;
PeriphClkInit.Eth1RefClockSelection = RCC_ETH1REFCLKSOURCE_PHY;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-02-03 5:50 PM - edited ‎2025-02-03 5:51 PM
This section does not exist in the autogenerated HAL_ETH_MspInit:
void HAL_ETH_MspInit(ETH_HandleTypeDef* heth)
{
GPIO_InitTypeDef GPIO_InitStruct = {0};
if(heth->Instance==ETH)
{
/* USER CODE BEGIN ETH_MspInit 0 */
/* USER CODE END ETH_MspInit 0 */
/* Peripheral clock enable */
__HAL_RCC_ETH_CLK_ENABLE();
__HAL_RCC_ETHTX_CLK_ENABLE();
__HAL_RCC_ETHRX_CLK_ENABLE();
__HAL_RCC_GPIOB_CLK_ENABLE();
__HAL_RCC_GPIOG_CLK_ENABLE();
__HAL_RCC_GPIOC_CLK_ENABLE();
__HAL_RCC_GPIOH_CLK_ENABLE();
__HAL_RCC_GPIOA_CLK_ENABLE();
/**ETH GPIO Configuration
PB8 ------> ETH_TXD3
PG14 ------> ETH_TXD1
PG13 ------> ETH_TXD0
PG11 ------> ETH_TX_EN
PC1 ------> ETH_MDC
PC2 ------> ETH_TXD2
PC3 ------> ETH_TX_CLK
PH6 ------> ETH_RXD2
PA1 ------> ETH_RX_CLK
PA0 ------> ETH_CRS
PC4 ------> ETH_RXD0
PH7 ------> ETH_RXD3
PA2 ------> ETH_MDIO
PC5 ------> ETH_RXD1
PA3 ------> ETH_COL
PA7 ------> ETH_RX_DV
*/
GPIO_InitStruct.Pin = GPIO_PIN_8;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
GPIO_InitStruct.Alternate = GPIO_AF11_ETH;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_14|GPIO_PIN_13|GPIO_PIN_11;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
GPIO_InitStruct.Alternate = GPIO_AF11_ETH;
HAL_GPIO_Init(GPIOG, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3|GPIO_PIN_4
|GPIO_PIN_5;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
GPIO_InitStruct.Alternate = GPIO_AF11_ETH;
HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_6|GPIO_PIN_7;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
GPIO_InitStruct.Alternate = GPIO_AF11_ETH;
HAL_GPIO_Init(GPIOH, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_1|GPIO_PIN_0|GPIO_PIN_2|GPIO_PIN_3
|GPIO_PIN_7;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
GPIO_InitStruct.Alternate = GPIO_AF11_ETH;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
/* USER CODE BEGIN ETH_MspInit 1 */
/* USER CODE END ETH_MspInit 1 */
}
}
Also, there is no RCC_PERIPHCLK_ETH... (as it is most likely directly clocked from PLL1Q).
Anything I am missing?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-02-04 1:42 AM
My bad, my clock fix applies the STM32H7S/R, not the STM32H7!
I've not used newer than Cube v5.5 with an STM32H7... Check your Cube generated code for the following macros. The __HAL_RCC_GPIOx macros are only necessary for the GPIO ports that have pins connected/used.
__HAL_RCC_ETH1MAC_CLK_ENABLE();
__HAL_RCC_ETH1TX_CLK_ENABLE();
__HAL_RCC_ETH1RX_CLK_ENABLE();
__HAL_RCC_GPIOC_CLK_ENABLE();
__HAL_RCC_GPIOA_CLK_ENABLE();
__HAL_RCC_GPIOB_CLK_ENABLE();
Check other resources:
- Example code at https://www.st.com/en/embedded-software/stm32cubeh7.html.
- Knowledge base at https://community.st.com/t5/stm32-mcus/how-to-create-a-project-for-stm32h7-with-ethernet-and-lwip-stack/ta-p/49308. There's a diagram of the required clock config there.
- Community search, as STM32H7 ETH is discussed often.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-02-04 1:45 AM
The code you mention isn't included in your Cube-generated HAL_ETH_MspInit looks very familiar. You need all of that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-02-04 1:53 AM
Please post whether it's an ST dev board and which one, or a custom board, your Cube version, and if it's an ST dev board, whether you loaded the board's default config in Cube.
@STea, could you or a colleague assist Lionheart1810 please?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-02-04 6:32 AM - edited ‎2025-02-04 6:36 AM
I am using STM32H573, not STM32H7 series.
STM32CubeMX version: 6.13.0
Firmware package version: STM32Cube FW_H5 V1.4.0
It is a custom board. I use DP83826 as Ethernet transceiver and 25 MHz oscillator. However, afaik it should be independent of the transceiver in MII mode for the reset.
I tried figuring it out and adding the missing code myself, but there are no such RCC_PERIPHCLK_ETH... macros in the entire HAL. I also just tried to initialize a blank project with just ETH enabled without success.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-02-04 7:26 AM - edited ‎2025-02-04 7:28 AM
PHY is the clock source for both Rx and Tx in MII mode.
So, you need the TX_CLK and RX_CLK outputs from PHY to be connected to ETH_TX_CLK and ETH_RX_CLK pins (marked in DS as ETH_MII_TX_CLK=PC3 and ETH_MII_RX_CLK=PA1) of the 'H5 respectively. These pins have to be set to AF in GPIOx_MODER and to the proper AF number (11) in GPIOx_AFR[]. Besides, RCC_AHB1ENR.ETHEN, .ETHTXEN, .ETHRXEN must be set (all 3 bits).
Read the RCC and ETH chapters in Reference Manual.
If CubeMX/Cube/HAL does not work for you, well, just don't use it, and program through registers directly.
PHY of course must be strapped (or configured through SMI) to MII mode.
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-02-04 9:23 AM
Figured out the error. I was missing the propagation of the reset signal to the external PHY for bootstrap configuration. Just added it to the HAL_ETH_MspInit.
