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

​Hello @DOsbo​ 

Could You please share your ioc file ?

Thanks,

Khouloud

I've got pretty much the same problem on an f207, and finding your report was a big help, thanks!. Did you come up with a workaround that doesn't involve having to patch the generated code each time you re-gen? I went with a kludge in the USER CODE 3 BEGIN section that comes just after the offending task creation code...

/* USER CODE BEGIN 3 */
 //
 // *** This fixes up the above task creation to make it point to the correct function, and to lower
 // its priority
 //
 TaskHandle_t t_id = xTaskGetHandle("LinkThr");
 vTaskDelete(t_id);
 attributes.priority = osPriorityBelowNormal;
 osThreadNew(ethernetif_set_link, &link_arg, &attributes);
 printf(" replaced bogus link state monitor with correct one - remove me when stm fix this\n"); 
/* USER CODE END 3 */

Although I guess there have been some changes between your version of the library and mine, as the task name is different for example.

Also, the original osPriorityRealtime doesn't work for me either - ethernet link bounces are of very little importance in my application, so I lowered that while I was relaunching the task.

I'm just patching the function name for now. I wanted to see what ST had to say about it first. It's strange STM32CubeMX doesn't give any control over creating the thread. I agree deleting the rogue thread is a bit nasty. In my case the unwanted thread is a copy of another real thread. It might be possible to disable LWIP_NETIF_LINK_CALLBACK and implement all the functionality as USER CODE, but I haven't investigated that yet.

I logged the bug with ST. It hasn't been assigned yet, but it has been labelled. 

What is the process for formally logging a bug? I posted one:

https://community.st.com/s/question/0D50X0000C4OLXtSQO/bug-stm32cubemx-task-stack-size-words-vs-bytes

in this forum a few days ago, but it quickly scrolled off into oblivion. Is there another place for bug reports?

Your're supposed to be able to log them here, but I find it's rare an ST employee will take ownership. I get a bit more traction on their GitHub site:

https://github.com/STMicroelectronics/STM32CubeH7/issues/23

I think it depends on the MCU how well it is monitored.

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);
 }
 

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.

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