Ethernet does not work if uC starts with the cable disconnected

[#1]

When starting uC (or performing a reset) with the cable connected to the router, ping.exe receives a response normally. If the cable is removed, ping.exe does not receive a response, but after reconnecting, ping.exe receives a response.

The problem is that if the cable is disconnected, and the uC is initialized, then ping.exe does not receive a response, obviously due to the disconnected cable. But after connecting the cable, ping.exe still doesn't get a response.

I tried to force the execution of MX_LWIP_Init () but it didn't work, even if the Ethernet is already responding to ping.exe, it will stop responding if I call MX_LWIP_Init () again.

I noticed that MX_LWIP_Init () has a long timeout, 5000ms, but even so, I can't get it to work without restarting uC.

Note: DHCP: off. External PHY: LAN8720. uC: STM32F407VG.

I tested a code made with Arduino IDE, and it happens the same way it happens in STM32CubeIDE.

How to reset the Ethernet, without having to restart the uC?

[#2]

I added a output in milliseconds, it seems that for both (fixed) Static IP and DHCP the waiting time is the same.

UsrLog("%lu", HAL_GetTick());

Static IP (cable disconnected):

14:52:38.676: 0
14:52:43.926: 5272

Static IP (cable connected):

15:05:56.909: 0
15:05:58.553: 1569

DHCP (cable disconnected):

14:55:37.284: 0
 
14:55:42.534: Assertion "netif is not up, old style port?" failed at line 744 in ../Middlewares/Third_Party/LwIP/src/core/ipv4/dhcp.c
 
14:55:42.534: 5284

DHCP (cable connected):

14:56:45.753: 0
 
14:56:47.394: 1658

[Piranha]

The time difference is because of 4095 ms delay and it comes from there:

https://github.com/STMicroelectronics/STM32CubeF4/blob/a86ecaa2fb63029596ba7dabadab2d9c2c139560/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_conf_template.h#L223

https://github.com/STMicroelectronics/STM32CubeF4/blob/a86ecaa2fb63029596ba7dabadab2d9c2c139560/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_eth.c#L478

Post edited to adhere to community guidelines.

[#4]

> In your code above the initialization still may occur several times.

it seems not.

if(eth_is_initialized != 0) return;

[#5]

Maybe one day we'll get there, one step at a time.

[#6]

I managed to test the LAN8720 with the ESP32 chip, the performance seems to be similar to the STM32, in relation to data transfer.

But this problem of disconnected cable when booting does not seem to occur with ESP32.

(Unfortunately another type of problem also occurred, it seems that with ESP32 the LAN8720 is not being reset during the initialization of ESP32, but that is another story, for another manufacturer to resolve. [P.S.: (Solved) https://github.com/espressif/arduino-esp32/issues/3817])

ESP32 source code: https://github.com/espressif/arduino-esp32/blob/master/libraries/WiFi/examples/ETH_LAN8720/ETH_LAN8720.ino

[#7]

Hi,

Sorry, I think I made a mistake, I've been comparing incompatible codes. The STM32 code uses static IP and the Arduino code uses DHCP.

I added a static IP to the Arduino sketch, and now I can say that the ping is getting a response after connecting the cable, if the cable is disconnected before starting the microcontroller.

For the Arduino case, it must have been the lack of obtaining the IP address via DHCP. After I added another attempt to initialize Ethernet, both codes worked, using DHCP and with static IP.

Unfortunately, unlike Arduino, the STM32CubeMX (or IDE) code still doesn't work, for static IP (I am not referring to the lack of lines of code with IP address, already informed in another topic: https://community.st.com/s/question/0D50X0000CCqnibSQB/bug-found-external-phy-stopped-working-two-updates-ago-please-check-what-happened).

I would like to inform you that the Arduino code works and that it can serve as a basis for locating the problem.

Thank you.

Ref.: https://github.com/stm32duino/STM32Ethernet/issues/42

[Nick van IJzendoorn]

However the above solution works, the real problem is that `netif_set_up(&gnetif)` is never called when the cable is connected after the initialization routine is executed. It took me a day because I was to stubborn to accept this as a solution since hot-plugging afterwards works find. It's easily overlooked because the function names of netif_set_up and netif_set_link_up look near identical...

To my knowledge it's perfectly fine to call `netif_set_up(&gnetif)` when there is no network link because the link management is done via the function `netif_set_link_up(&gnetif)`. It's very easy to overlook because the functions look identical. The problem is thus also fixed by changing in the function `MX_LWIP_Init`:

if (netif_is_link_up(&gnetif))
  {
	/* When the netif is fully configured this function must be called */
	netif_set_up(&gnetif);
  }
  else
  {
    /* When the netif link is down this function must be called */
    netif_set_down(&gnetif);
  }

to

/* We must always bring the network interface up connection or not... */
  netif_set_up(&gnetif);

This avoid extra management of tracking if this is the first time that the cable is connected. LwIP is perfectly capable of managing that by itself, as long as netif_set_link_up and netif_set_link_down are properly used. And that they do as long as you call:

// check the link status
	ethernetif_set_link(&gnetif);

in `MX_LWIP_Process`

[Piranha]

You are completely right. Although it was already reported by me and others here, I added more details and a link to this topic to my Ethernet/lwIP issue list.