STM32F767ZI Ethernet not working without MX_USB_OTG_FS_PCD_Init()

[BTurc.2]

I am using an STM32 Nucleo-F767ZI with RMII Ethernet + LAN8742A PHY and an example project based on lwIP/TCP-IP.

I noticed a strange behavior: if I comment out MX_USB_OTG_FS_PCD_Init(), Ethernet communication stops working. If I keep it enabled, Ethernet works correctly.

The peripheral initialization order is:

MX_GPIO_Init();
MX_USART3_UART_Init();
MX_LWIP_Init();
MX_TIM3_Init();
MX_SPI4_Init();
MX_CAN1_Init();
MX_UART5_Init();
MX_USB_OTG_FS_PCD_Init();

Additional observations:

• SystemClock_Config() does not change

• Replacing MX_USB_OTG_FS_PCD_Init() with HAL_Delay() does not fix it

• So it does not look like a timing issue

• It seems that HAL_PCD_Init() / HAL_PCD_MspInit() for USB is enabling or configuring something indirectly that Ethernet depends on

My question is:

What could USB FS initialization be configuring that would make Ethernet work, even though they should be unrelated?

I am thinking about possibilities such as:

• GPIO clocks being enabled indirectly

• MSP/NVIC configuration side effects

• Some indirect dependency affecting HAL_ETH_MspInit() or lwIP

Has anyone seen something similar with STM32F767 + LAN8742A + lwIP?

[STackPointer64]

Hello @BTurc.2, 

This is unusual. I cannot say for sure without analyzing the application in depth. Could you please attach your project so I can review it? If the project is private, feel free to send me a private message, and I can provide a secure line for you to upload the project.

Best regards,

[BTurc.2]

Hello @STackPointer64,

My project is derived from the following repository:
https://github.com/ahmetkcavusoglu/nucleo-f767zi_lwip

With the original repository, TCP/IP communication with the Nucleo works correctly even when MX_USB_OTG_FS_PCD_Init(); is fully commented out.

Since my project is private, I will send it to you by private message.

In my project, I observed the following behavior inside MX_USB_OTG_FS_PCD_Init():
I can comment out all the initialization code and TCP/IP communication still works, as long as this line remains present:

hpcd_USB_OTG_FS.Instance = USB_OTG_FS;

If that line is also removed, the board is no longer reachable over TCP/IP.

So at the moment it seems that the issue is not related to full USB OTG FS initialization itself, but rather to some side effect associated with assigning the USB instance to the PCD_HandleTypeDef.

[STackPointer64]

Hello @BTurc.2,

After analysis, it appears the issue is related to LwIP misconfiguration, particularly the LwIP RAM heap pointer address. I made several adjustments:

• Changed LWIP_RAM_HEAP_POINTER in lwipopts.h to 0x20074000.
• Increased memory size to 16 KB to support your application; you can modify it if needed:
   

  #define MEM_SIZE 16*1024
  

Regarding the function being commented out or uncommented, the issue might be related to memory alignment or a similar cause. I have been pinging the app nonstop, and everything seems to work well.

Additionally, please refer to this article for further details and as a reference for future work:

• Implementing a LwIP and FreeRTOS™ v1 UDP echo server on the STM32F7 series 

Best regards,