[BUG FOUND] External PHY stopped working two updates ago. Please check what happened.

[#1]

Update 4:

The definition of these variables was missing (FW_F4 1.25.0), the generated code did not insert this part:

File Src/lwip.c (line 58)

void MX_LWIP_Init(void)
{  
  /* IP addresses initialization */
  IP_ADDRESS[0] = 192;
  IP_ADDRESS[1] = 168;
  IP_ADDRESS[2] = 1;
  IP_ADDRESS[3] = 111;
  NETMASK_ADDRESS[0] = 255;
  NETMASK_ADDRESS[1] = 255;
  NETMASK_ADDRESS[2] = 255;
  NETMASK_ADDRESS[3] = 0;
  GATEWAY_ADDRESS[0] = 192;
  GATEWAY_ADDRESS[1] = 168;
  GATEWAY_ADDRESS[2] = 1;
  GATEWAY_ADDRESS[3] = 1;
 
 /* Initilialize the LwIP stack without RTOS */
  lwip_init();

Update 3:

STM32CubeMX version 5.6.0 (FW_F4 1.25.0) did not work.

STM32CubeMX version 5.5.0 (FW_F4 ?) did not work.

STM32CubeMX version 5.4.0 (FW_F4 1.24.2) worked.

STM32CubeMX version 5.2.0 (FW_F4 1.24.1) worked.

STM32CubeMX version 4.27.0 (FW_F4 1.19.0) worked.

STM32CubeMX version 4.22.0 (FW_F4 1.16.0) worked.

Update 2:

I downloaded STM32CubeMX version 5.2.0 (FW 1.24.1) and it worked.

STM32CubeMX version 5.6.0 did not work.

I imported the Atollic project (made with FW1.24.1) in STM32CubeIDE (1.3.0) and it worked.

So it's not a problem with the STM32CubeIDE, but with the FW package.

I will download (STM32CubeMX) the versions between 5.2.0 and 5.6.0, it seems that at some point there was some change that should not have occurred.

=========== X ============

Update:

I managed to make it work with STM32CubeMX version 4.22.0 (FW 1.16.0) but it didn't work with STM32CubeIDE 1.3.0 (FW 1.25.0)

=========== X ============

I found an example, step by step, of using the LAN8720, including video, but ping.exe is not receiving responses.

It seems that there were some changes in the automatic code generation.

What could be happening?

The LEDs on the network card are showing activity, the connections between STM32F407VG and LAN8720 show activity only at startup, should there be activity all the time?

(The material is in Russian, but using subtitles and translators it is possible to understand)

Website:

http://narodstream.ru/stm-urok-96-lan8720-lwip-tcp-client-chast-2/

Movie:

https://www.youtube.com/watch?v=L8nLqsp5nSo

I found other tips too, but it didn't work:

https://community.st.com/s/question/0D50X00009XkduA/use-lan8720a-for-phy-init-ethernet

[#2]

Hi @Amel NASRI​ ,

I found a missing part in the Src / lwip.c file (line 58 to 70)

void MX_LWIP_Init(void)
{  
  /* IP addresses initialization */
  IP_ADDRESS[0] = 192;
  IP_ADDRESS[1] = 168;
  IP_ADDRESS[2] = 1;
  IP_ADDRESS[3] = 111;
  NETMASK_ADDRESS[0] = 255;
  NETMASK_ADDRESS[1] = 255;
  NETMASK_ADDRESS[2] = 255;
  NETMASK_ADDRESS[3] = 0;
  GATEWAY_ADDRESS[0] = 192;
  GATEWAY_ADDRESS[1] = 168;
  GATEWAY_ADDRESS[2] = 1;
  GATEWAY_ADDRESS[3] = 1;
 
 /* Initilialize the LwIP stack without RTOS */
  lwip_init();

Thank you, I hope I helped.

[VaZso]

I wonder how this problem could be still unresolved.

Using latest (!!!!!) firmware version of V1.25.2, it still don't work for me while it works using 1.24.1.

At STM32 side, I can see it receives IP of 192.168.10.137, however, I can not ping it.

At server side, I see the following log:

Nov 09 23:05:03 XXXX dnsmasq-dhcp[2775]: DHCPDISCOVER(br0) xx:xx:xx:xx:xx:xx

Nov 09 23:05:03 XXXX dnsmasq-dhcp[2775]: DHCPOFFER(br0) 192.168.10.137 xx:xx:xx:xx:xx:xx

Nov 09 23:05:03 XXXX dnsmasq-dhcp[2775]: DHCPDISCOVER(br0) xx:xx:xx:xx:xx:xx

Nov 09 23:05:03 XXXX dnsmasq-dhcp[2775]: DHCPOFFER(br0) 192.168.10.137 xx:xx:xx:xx:xx:xx

Nov 09 23:05:03 XXXX dnsmasq-dhcp[2775]: DHCPDISCOVER(br0) xx:xx:xx:xx:xx:xx

Nov 09 23:05:03 XXXX dnsmasq-dhcp[2775]: DHCPOFFER(br0) 192.168.10.137 xx:xx:xx:xx:xx:xx

Nov 09 23:05:03 XXXX dnsmasq-dhcp[2775]: DHCPREQUEST(br0) 192.168.10.137 xx:xx:xx:xx:xx:xx

Nov 09 23:05:03 XXXX dnsmasq-dhcp[2775]: DHCPACK(br0) 192.168.10.137 xx:xx:xx:xx:xx:xx

Nov 09 23:05:03 XXXX dnsmasq-dhcp[2775]: DHCPRELEASE(br0) 192.168.10.137 xx:xx:xx:xx:xx:xx

So it seems it receives the IP address, STM32 acknowledges it, then release it...

...I don't know why it does a release while it still thinks it has a valid IP address anyway.

If I make dhcp_release_and_stop() to do nothing in LwIP/src/core/ipv4/dhcp.c then it does not release the IP and magically network connection works (I can ping it and it responds).

However, for a real solution, it should be debugged why it thinks it should release its IP address, which is a call of dhcp_release_and_stop() function and may achieved also by dhcp_release() or dhcp_stop() functions.

I am currently don't have time for digging into it as I have another project running, which will need LAN connection in a later point, just wondered this problem is still exists after months without any fixes.

So, basically STM32 releases its IP address immediately after it had received and acknowledged it but still thinks its received IP address is valid.

Ps: While I wrote this comment, I was continuously gathered more and more information so it describes how I went through the process...

Okay, so I finally found the problem.

There is a DHCP state machine found in example section earlier which worked with older firmware but not with the current one as it has a dhcp_stop(netif); line in DHCP_WAIT_ADDRESS state inside an "if (IPaddress !=0)" condition where IPaddress=netif->ip_addr.addr.

After commenting this out, the firmware works well.

Also, there is a dhcp_supplied_address condition check in latest examples, so apparently, it is modified in current example applications.