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]

​Hello @DOsbo​ 

Could You please share your ioc file ?

Thanks,

Khouloud

[DOsbo]

sure.

[David Bathurst]

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.

[DOsbo]

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. 

[David Bathurst]

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?

[DOsbo]

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.

[Khouloud ZEMMELI]

​Hi @DOsbo​  this will be internally checked.

Best Regards,

Khouloud

[DOsbo]

Thanks Khouloud. Let me know if you need more information.

Cheers

David

[DOsbo]

Seems ST only take firmware bugs at the GitHub site. Bugs relating to STM32CubeMX have to be logged here in this forum.