Software Reset Fails In ETH Configuration For LWIP With F407

[Chao]

Hi,

Recently, I got a copy of code for LWIP working with F407ZG in Keil project, I successfully ported it into CubeIDE with full functionality of CubeMX except for ETH selection (i.e. ported the code into a normal CubeIDE project with .ioc file without ETH selection). It works fine with F407ZG, but when I ported it again into a CubeIDE project with F407VE, it reports a failure on Software Reset, the call to HAL_ETH_Init() in stm32f4xx_hal_eth.c returns HAL_TIMEOUT:

The original Keil project finished in October 2021, therefore the HAL driver is not up to date.

From F407ZG to F407VE, only 3 pins are different for ETH pin configuration:

The pin connections between the MCU and the PHY chip remain the same, and the ETH_RX_CLK and the ETH_TX_CLK are all enabled and checked with online debugging.

I wonder what is the reason of the Software Reset failure. Bad soldering of the MCU or the PHY chip? Or something else? The MCU and PHY have all been replaced for test. I don't know what to do next for debugging without knowing the possible reasons of the failure.

Therefore,  it would be highly appreciated if someone could give some suggestions. For example, after the LSB of  (heth->Instance)->DMABMR is set, the while loop waits for the software reset to reset the LSB of (heth->Instance)->DMABMR, then which resource would reset the LSB of (heth->Instance)->DMABMR? The MCU itself or the PHY chip?

Regards

Chao

 

[STea]

Hello @Chao ,

answering your question 

"Therefore,  it would be highly appreciated if someone could give some suggestions. For example, after the LSB of  (heth->Instance)->DMABMR is set, the while loop waits for the software reset to reset the LSB of (heth->Instance)->DMABMR, then which resource would reset the LSB of (heth->Instance)->DMABMR? The MCU itself or the PHY chip?"

the software operation is done by the MCU in software as can be found in your driver so the MCU set it to high and it will be automatically cleared once the Software reset operation is completed.

  /* 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 */

  SET_BIT(heth->Instance->DMABMR, ETH_DMABMR_SR);

passing now to possible issues making this behavior i recommend trying this code on a nucleo or discovery board and see if something related to your pin configuration is causing this issue i think it could be related to maybe gpio pin speed or other similar issues that could be causing this issue maybe if you can share the configuration to make sure if it is compliant with the F407VE you are trying to use.

 

BR 

[waclawek.jan]

DMABMR.SR clears automatically, if clocks are present and enabled.

- do you use MII or RMII? Check presence of the respective clock(s) using oscilloscope, directly on the pin(s).

- check if the MII/RMII switch is properly set in SYSCFG_PMC.MII_RMII_SEL

- check if the respective pins are set properly in GPIO by reading out and checking the GPIO registers content

- check if all three ETHMACxxEN bits in RCC_AHB1ENR are set (ETHMACPTPEN does not need to be set for basic operation)

JW

[Annette1]

Hi waclawek.jan

I am working with KSZ8863 and STM32F427. 

My problem is also that the ETH_DMABMR_SR never clears after initiating the Ethernet SW reset.

I checked the correct RMII configuration in MII_RMII_SEL, the clock is 50MHz, the RMII related pins are correctly configured, and the ETHMACxxEN bits are set.

Do you have any other ideas about how to debug the source of this issue as you suggestions from above do not seem to lead to the cause.

Best regards,

Annette