STM32F4 Ethernet issue with firmware version V1.25.0

[VaZso]

Hello,

I ran into a problem with Ethernet using an STM32F407VET6 microcontroller a few weeks ago.

That time I have searched this problem and found somebody facing the same issue and conclusion, but I did not found that thread now.

So using the latest HAL, which is currently V1.25.0, Ethernet seems to be not working.

It asks DHCP for an IP, it receives an IP address, but it does not respond to ping requests and also it does not appear in DHCP's lease table.

If I regenerate the project using HAL version V1.24.2 then it works perfectly, so it appears in lease table and also responds to ping requests.

Does ST know about this problem?

Thank you in advance.

[Piranha]

ST's non-working HAL/Cube bloatware has never been working, especially if RTOS is used. They know that very well, but they are not able of fixing it as their HAL/Cube team is intellectually incapable of even understanding those problems.

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32

[VaZso]

Really sad. :(

Anyway, Ethernet used to work without RTOS (at least it was answered to ping requests and I could send data through UDP), but now it isn't.

It seems I should not enable RTOS as it will not works well either and there is not even any warning about it is incomplete.

I remember when I have tried to use FSMC interface for the first time and even initialization code was not generated, it was not even compileable.

Anyway, don't they test the functions before releasing a new "firmware"?

:(

[Piranha]

“Program testing can be used to show the presence of bugs, but never to show their absence!�?

― Edsger W. Dijkstra

For ST's code testing doesn't even make sense, because there is no sense in testing obviously flawed code. One can open their GitHub page, look at the code and find hundreds of flaws in a few hours. Reporting those will take more time than to read the reference manual and develop new driver from the scratch. An even, if you report them, most will be ignored and those few simplest ones, which will not be ignored, will be "worked on" for at least a year and there will still be only 50% chance that the solution will actually fix the problem. I'll not even fantasize of them reworking the library architecture into actually high level, flexible and useful...

[VaZso]

True, but if something is working, it would be good to remain working after an upgrade...

The code itself really has some problems and also design flaws like the USB Device support of only one class and one device altogether and it is even should be rewritten to have combo device functionality.

Also it is not consistent so networking works on F4 using DP83848 and works on H7 using LAN8742.

I have designed a panel using DP83848 because it was working well with F4 and it is easily solderable, but had to modify software for H7 to also work with it.

Moreover, there were parts in the code which should have been modified but there were no USER sections, so it was tricky for the modification remain untouched by code generation later.

So yes, there are a lot of problems... unfortunately.

[VaZso]

Mmm, I wrote a bit more detailed reply in this thread as I was wondering this problem still exists in latest firmware (V1.25.2).

Basically, the problem is that STM32 releases its IP address just after it received and acknowledged it and that is why it stops working while it still think its IP address is valid.

If I disable the effect of dhcp_release_and_stop() function which is also called by dhcp_release() or dhcp_stop() functions, then I can ping the device.

However, currently I don't have time to dig into why it thinks the IP address should be released, however, it should be debugged...

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.