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

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

[alister]

Too early. Not enough information. Load your app in a debugger. Put a breakpoint where you receive a packet. Step until you find where it fails or you find some prerequisite of what you're stepping isn't ok. If it doesn't reach your breakpoint, investigate its init.

I tested another sample code written for the Arduino platform, and it worked. STM32 was able to access the internet, and ping.exe received the correct answer.

UdpNtpClient_LAN8720.ino:

Begin Ethernet
Success to configure Ethernet using DHCP
localIP: 192.168.1.103
subnetMask: 255.255.255.0
gatewayIP: 192.168.1.1
dnsServerIP: 192.168.1.1
Seconds since Jan 1 1900 = 3792088790
Unix time = 1583099990
The UTC time is 21:59:50

Note: Need to edit stm32f4xx_hal_conf_default.h (LAN8720 addr = 0x01)

/* Section 2: PHY configuration section */
/* LAN8742A PHY Address*/
#define LAN8742A_PHY_ADDRESS 0x01U

Source code:

https://github.com/nopnop2002/Arduino-STM32-Ethernet-LAN8720

I did exactly what the person who did the tutorial did, around the year 2017. So I believe that there was a change in the code that IDE is generating.

I managed to make the ping.exe part work. I downloaded STM32CubeMX version 4.22.0, this version was already with the FW package of version 1.16.0.

The video shows SW4STM32, but I couldn't find instructions on how to install this IDE. So, I compiled with Atollic version 9.3.0.

STM32CubeMX old versions, links:

https://community.st.com/s/question/0D50X00009XkYVDSA3/please-provide-a-way-to-download-older-version-of-the-cube

If anyone has any problems with this, try version FW_F4 V1.24.2 or earlier (STM32CubeMX 5.4.0 or earlier).

(More details were added in the first post)

Setup:

Hi @Amel NASRI​,

Let me know if your team was able to identify the problem with the ping.

I'm trying to use DNS, but FW_F4 1.24.2 doesn't allow DNS functions to be activated when generating the code, I can only activate it manually (does not seem to find the reference in the lwipopts.h file).

In FW_F4 1.25.0 it seems that this problem with DNS has already been resolved. So, I wish I could use the latest version of FW_F4.

Thank you.

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.

Correction - Package: FW_F4 V1.24.2 worked.

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

I was unable to get STM32CubeIDE V 1.3.0 to work with FW_F4 V1.24.1, so I uninstalled the IDE.

I installed version 1.1.0, and for some reason, there was some confusion with the FW_F4 packages, and even after starting the project with FW_F4 V1.24.1, FW_F4 V1.25.0 was appearing when compiling, and it didn't work (ping.exe didn't get a response).

So I opened the package repository folder and removed all packages.

I uninstalled everything again, STM32CubeIDE and STM32CubeMX.

I installed STM32CubeMX V5.4.0 again and the reference for the FW_F4 1.24.2 package appeared (instead of 1.24.1).

I tested with this STM32CubeMX V5.4.0 + FW_F4 V1.24.2 configuration and it worked.

Oh Boy! Please confirm what was found.

I created two new projects, one with FW_F4 1.24.1 and the other with FW_F4 1.25.0.

I compiled the project with FW_F4 1.24.1 with Atollic (because there I can configure STlink to just download), the ping (ICMP) worked. The FW_F4 1.25.0 project did not work, as expected.

So I was replacing the project files with FW_F4 1.24.1 until it stopped working. I tapered until I got to the lwip.c.

Then, with the help of the ExamDiff program, it was easy to notice something missing in the file created with FW_F4 1.25.0, as follows:

[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.