STM32F767ZI Nucleo sometimes not receiving ethernet packets after debugger reset

[riwe]

I built a custom application based on the LwIP_HTTP_Server_Netconn_RTOS example in the CubeMX SDK 1.17.4. RX and TX work after power-up and in 50% of cases also after a debugger reset. However, in 50% of cases, RX doesn't work at all. The symptoms in the error case:

• the yellow LED flashes once when booting, then it's constantly on
• The link is detected as "up"
• The MMCTGFCR register shows that some packets have been successfully sent (my application sends some packets after boot)
• No packet is received at all
• replugging the network cable usually makes everything work, but not always

I restart the debugger multiple times until it works, but the whole situation is annoying. I wonder what the problem could be? Since I use the initialization code in the example, only the timing is different. Is there any timing dependency between phy and eth driver? Or can I rule out the phy as a potential problem here?

I found this thread with a maybe similar problem, but the workaround proposed there seems not relevant as the eth driver code has been rewritten in the meantime.

Thanks

[Guillaume K]

Hi

are there CRC errors in RX ? (register MMCRFCECR )

it can happen on STM32F7s when RMII is used.

if it is the case, you have to reset the RMII interface.

if you use the LwIP_HTTP_Server_Netconn_RTOS application, it should be already handled in RMII_Thread():

see STM32CubeF7/Projects/STM32F767ZI-Nucleo/Applications/LwIP/LwIP_HTTP_Server_Netconn_RTOS/Src/ethernetif.c at master · STMicroelectronics/STM32CubeF7 · GitHub

[riwe]

Thanks. I did indeed check this and found the MMCRFCECR always being 0. Nevertheless, the RMII watchdog thread is running fine, but since no packets are received, it won't stop (note that my MCU revision seems unaffected anyway). I also tried to soft-reboot the PHY by writing into the BCR register as the first step, but it didn't have an effect. The problem remains. TX seems working, no packets are received after boot.

Is there any possibility for me to check whether the problem is the 8742 PHY or whether it is the MCU? Is my debug init procedure correct? I use:

load
monitor reset init

[riwe]

Any hints?