STM32F767 : No Ethernet when APB2CLKDivider = RCC_HCLK_DIV8 or greater

[Joerg Wagner]

My SysClock is 200 MHz, AHB Prescaler=1.

I want to slow down some timer to filter glitches from external input.

But when APB2 peripheral clock is set lower than 50 MHz

the Ethernet DMA does not send any data: no ARP, UDP or TCP.

Even when ABP2 timer clock is set to 200 MHz to give it a try.

Why does APB2 peripheral clock takes advantage of Ethernet traffic?

I cannot find any dependencies on page 19 in the datasheet.

Thank you.

[waclawek.jan]

Cut down the program to ETH only. Still problem?

JW

[Joerg Wagner]

Yes, I wrote a tiny one without RTOS. I'm sure it has the same effect in one of the FW examples (udp_client).

You can reproduce it:

APB2 Peripheral clock >=50 MHz okay

APB2 Peripheral clock <50 MHz not okay

I didn't try other frequencies as well to find the border, i.e. using another SysClk freq to get 48 MHz.

[Joerg Wagner]

Okay, it does not depend on the absolute frequency.

It occurs when

RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV8;

or greater.

DIV4 and less are okay.

[waclawek.jan]

So, now there's no APB2 peripheral used, i.e. if you read out RCC_APB2ENR it is all zero?

What's the read-out content of RCC_CFGR?

Do you use MII or RMII on ETH? Please read out and post content of SYSCFG_PMC.

How is the PHY clocked?

JW

[Joerg Wagner]

RCC_APB2ENR = 0x0000940A (PPRE2=0x4, PPRE1=0x5, SWS1=1, SW1=1)

RCC_CFGR = 0x00004020 (USART6EN=1, SYSCFGEN=1)

Board is STM32F767-NUCLEO (STM32F767ZI), Firmware 1.15.0, CubeMX 5.2.1 generated project

PHY is clocked with 25MHz in Schematic.

[Piranha]

I tested this on NUCLEO-F767ZI at HCLK 216 MHz with Debug and Release builds of this code:

https://community.st.com/s/question/0D50X0000AhNBoWSQW/actually-working-stm32-ethernet-and-lwip-demonstration-firmware

All APB2 suitable dividers (2, 4, 8 and 16) run perfectly fine and Ethernet performance isn't impacted also.

Conclusion... Nothing new, I'm telling it all the time - STM32 HAL ETH driver and lwIP implementation is broken beyond repair and nobody cares.

[Joerg Wagner]

I tested this with the demo code of the 1.15.0 FW (LwIP_HHTP_Server_Netconn_RTOS):

Setting DIV8 in # line 253:

 RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV8;

Ethernet does not work anymore.

Code is flashed, no Debug session.

The only APB2 peripheral Ethernet topic I found is in SYSCFG_PMC Bit 23: MII_RMII_SEL: Ethernet PHY interface selection

No other APB2 peripheral has a relationship with Ethernet.

@Piranha​ It's nice that your code works with any ratio. But I (and the others) have no advantage of this.

Probably you can share your experience as a library without providing the source code.

[waclawek.jan]

> Board is STM32F767-NUCLEO (STM32F767ZI),

OK so it's RMII with PHY having crystal and providing the reference clock.

Post content of SYSCFG_PMC.

JW

[Joerg Wagner]

SYSCFG_PMC = 0x800000

Bit 23 MII_RMII_SEL is set.

This means RMII is selected.

[waclawek.jan]

Then I'm out of the simple ideas, and debugging as usual should follow, i.e. observing the behaviour through ETH registers and comparing to the working case.

JW

[Adam BERLINGER]

Hi all,

I know this is quite old thread, but I recently handled same issue and some other users might find this information useful.

The problem seems to be with initialization sequence and configuring MII/RMII selection which is in SYSCFG block (clocked by PCLK2 from APB2). In the sequence, the switch is configured and then MAC is reset by software (clocked by HCLK from AHB). However when APB2 is much slower than AHB, it might happen that the reset is done before MII/RMII switch in SYSCFG and the peripheral is not working properly.

Below is a simple workaround that forces synchronization between SYSCFG and ETH (HAL_ETH_Init function in stm32f7xx_hal_eth.c):

 /* Select MII or RMII Mode*/
 SYSCFG->PMC &= ~(SYSCFG_PMC_MII_RMII_SEL);
 SYSCFG->PMC |= (uint32_t)heth->Init.MediaInterface;
 (void)SYSCFG->PMC; // <---- Workaround: Dummy read to sync SYSCFG with ETH
 /* Ethernet Software reset */
 /* Set the SWR bit: resets all MAC subsystem internal registers and logic */
 /* After reset all the registers holds their respective reset values */
 (heth->Instance)->DMABMR |= ETH_DMABMR_SR;

With this workaround you should be able to choose arbitrary HCLK/PCLK2 ratio. But please note that there is still HCLK>=25MHz minimum frequency needed for Ethernet to work properly.

I think this is valid for all STM32s with ethernet, although the critical HCLK/PCLK2 ratio might differ between families. It has been reported internally and should be fixed in next releases.

Best regards,

Adam Berlinger

[waclawek.jan]

Hi Adam,

Thanks for the info.

Are you talking about this one? https://www.eevblog.com/forum/microcontrollers/stm32f417-any-reason-why-a-min-pclk2-speed-is-required-for-ethernet-to-work/?all

RM0090 in description of SYSCFG_PMC.MII_RMII_SEL says this:

Note: This configuration must be done while the MAC is under reset and before

enabling the MAC clocks.

It's not clear, which reset does this note talk about - whether RCC_AHB1RSTR.ETHMACRST or ETH_DMABMR.SR - but given the latter is self-clearing thus it would be difficult to ensure it's still on when SYSCFG_PMC.MII_RMII_SEL is switched, it's probably the former. I presume Cube implementation closely follows the RM, so following this note won't resolve the problem?

Also, as I wrote in the linked thread, I tried my implementation and it works with any APB2 setting. My implementation is based on the original SPL-based "library", and it first switches SYSCFG_PMC.MII_RMII_SEL, after that enables the three clocks in RCC_AHB1ENR, and only after that (as part of ETH process going up/down as configured by user) the resets are performed, first in RCC_APB1RSTR then the self-clearing internal reset in ETH_DMABMR. Note that this does not obey the "configuration must be done under reset", but appears to be fully functional regardless.

In any case, could you please give a definitive ETH initialization sequence and make sure it appears in the relevant RMs? Cube is just one of the implementations, thus entirely irrelevant from documentation point of view.

Thanks,

Jan

@Adam BERLINGER​