STM32F439 delay required before sending packets in LWIP

[michael123]

I am using the ethernet and lwip drivers provided by the STM32CubeMX software on a nucleo-144. I have a program, which upon start, sends out a UDP packet. I set the program to soft reset after a few seconds to characterize this issue. Using a GPIO line, I set a point in the code to toggle after successful initialization (i.e. all initialization functions return a non error status). I found that the board would continuously reach the toggle command periodically, though the UDP packet which I am sending was not periodic, often missing 1/3 of the time. As a guess based on some debugging patterns I noticed, I decided to add in a 1 second delay before sending the first UDP packet. After doing this, I see a huge improvement, with almost all the first packets being sent out correctly. Why would this be? Is there someone else I should be watching for to reach a certain state before I send the first packet? Somewhere in the STM32 driver, or the PHY (LAN8742A)?

[Piranha]

Ethernet auto-negotiation can take up to 3,7 seconds. After that DHCP, if used, can take few more seconds to get IP address. For this lwIP has a possibility to set up two callback functions with netif_set_link_callback() and netif_set_status_callback().

[michael123]

Thanks for the response. I'm using a static IP address. I've previously set the netif_status_callback and checked for NETIF_FLAG_LINK_UP without any success. The driver itself provided by CubeMX checks for the NETIF_FLAG_LINK_UP before setting netif_set_up. Without the netif_set_up being triggerd I don't think it would ever start working. Is there a better flag to be checking?

[Piranha]

Application must call netif_set_up() once to enable that interface. This function is just enabling software interface for processing and is not related to link status. All they (ST) have to do in a driver, is call netif_set_link_up()/netif_set_link_down() when physical link changes - everything else ir wrong. The wrongness comes from old code and not reading documentation...

https://www.nongnu.org/lwip/2_0_x/upgrading.html

(2.0.0)

 ++ Application changes:

 * Changed netif "up" flag handling to be an administrative flag (as opposed to the previous meaning of

  "ip4-address-valid", a netif will now not be used for transmission if not up) -> even a DHCP netif

  has to be set "up" before starting the DHCP client

Also ST's implementations don't respect multi-threading. Again not reading documentation...

https://www.nongnu.org/lwip/2_1_x/multithreading.html

Putting it all together, the full answer is there:

https://community.st.com/s/question/0D50X0000AyAzvwSQC/stm32f746zg-nucleo-lwip-problem

[michael123]

I see you have made a driver to address the issues you have noticed in ST's code. Is there a specific failure point in their generated code that you are aware of that would explain the issue I am seeing?