BUG: STM32CubeMX code generator is calling ethernet_input instead of ethernet_link_thread.

[DOsbo]

Hi All,

When LWIP_NETIF_LINK_CALLBACK is enable in the STM32CubeMX LWIP middleware, it generates the following code from the FW_H7 V1.6.0 package:

/* Set the link callback function, this function is called on change of link status*/
  netif_set_link_callback(&gnetif, ethernet_link_status_updated);
 
  /* Create the Ethernet link handler thread */
  memset(&attributes, 0x0, sizeof(osThreadAttr_t));
  attributes.name = "EthLink";
  attributes.stack_size = INTERFACE_THREAD_STACK_SIZE;
  attributes.priority = osPriorityRealtime;
  osThreadNew(ethernetif_input, &gnetif, &attributes);

The thread function it is starting is ethernetif_input instead of ethernet_link_thread.

I think it's obviously a bug, so I'm not going to wait for confirmation and just log it as a defect. However, if I'm missing something please let me know.

Cheers

David

[Khouloud ZEMMELI]

Hi all , you need to add  STM32CubeMX topic ​to your request if you think that's a CubeMX issue.

Best Regards,

Khouloud.

[David Bathurst]

David, I don't wish to hijack your thread but do you use DHCP? If so, having got your link state monitoring task working by patching the function name, I'd be curious to hear how your system responds to this test:

• unplug your ethernet cable
• reset your target
• wait 10 seconds and then plug the ethernet cable back in.

For me, the link comes up but it won't request a DHCP address so remains unusable. I think the problem is also in MX_LWIP_INIT(), just before it sets up the link monitoring task. It only calls netif_set_up() if the link is up at the time MX_LWIP_INIT() is called. netif_set_up() sets the interface administratively up, i.e. tells the stack we want to use that interface - I think that should be done regardless of the link state. Interface state (a sysadmin concept) and link state (a physical PHY concept) are pretty much orthogonal parameters - either can be up or down without the other.

Failing to set the interface up means dhcp_start() aborts early with:

Assertion "netif is not up, old style port?" failed at line 727 in Middlewares/Third_Party/LwIP/src/core/ipv4/dhcp.c

So as far as DHCP is concerned it's not even running on that interface, so when the link does come up and dhcp_network_changed() gets called, it bails early because there is no DHCP client associated with that interface.

I "fixed" it in the same USER CODE BEGIN 3 section that my above patch lives in:

/* USER CODE BEGIN 3 */
 
  //
  // The interface should be brought up (administratively) regardless of current link state.  The
  // above code only does that if the link is up, when it's not that causes dhcp_start() to fail.
  // We recover that here.
  //
  if (!netif_is_up(&gnetif)) {
    netif_set_up(&gnetif);
    dhcp_start(&gnetif);
  }
  

[DOsbo]

Thanks Khouloud,

I'll be sure to do that next time. Personally, I would prefer if ST had a more controlled way of logging the defects for Cube like you do with the firmware. Maybe consider it for the future.

Cheers

David

[Khouloud ZEMMELI]

​We will try to do our best :)

Regards,

Khouloud

[Khouloud ZEMMELI · Accepted solution]

​Hi @DOsbo​  Issue fixed , the fix will be available in the next Release.

Best Regards,

Khouloud

[DOsbo]

Thank you for your assistance Khouloud.

Cheers

David

[DOsbo]

Our project is only at a stage where we want to confirm the hardware is working so I haven't tested the network stack in detail. I did notice that dhcp_start() fails if it is called before the link is up. I remember seeing an example (which I can't locate now) where DHCP was controlled by its own dedicated thread. When the link comes up it calls dhcp_start() and when the link goes down it calls dhcp_stop(). That might be a better way, but I haven't really spent much time with it yet.

[alister]

Fixes for the next problems are at https://community.st.com/s/question/0D50X0000C6eNNSSQ2/bug-fixes-stm32h7-ethernet