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?

[riwe]

Some more info.

• The problem occurs completely independent from whether the board runs with debugger or stand-alone.
• I can trigger it only by connecting the board to a certain router (Atheros 8030 ethernet chip). When connecting it directly to my PC, it always works.
• When the problem occurs, I see a 1 in the LAN8742's SECR register. If the connection works, the register contains value 0. All other registers are identical.

Here is a full register dump of the PHY:

ANAR	(hex) 1e1	
ANER	(hex) 6d	
ANLPAR	(hex) dde1	
ANNPRR	(hex) 4000	
ANNPTR	(hex) 2001	
BCR	(hex) 3100	
BSR	(hex) 782d	
CLR	(hex) 4000	
ENCTR	(hex) 41	
IMR	(hex) 0	
ISFR	(hex) c8	
MCSR	(hex) 2	
MMDAADR	(hex) 0	
MMDACR	(hex) 0	
PHYI1R	(hex) 7	
PHYI2R	(hex) c131	
PHYSCSR	(hex) 1058	
SCSIR	(hex) a	
SECR	(hex) 1	
SMR	(hex) 60e0	
TCSR	(hex) 0	
TPDCR	(hex) 9b9d	

Any idea somebody what I could check next? Maybe the PHY is not the problem, but the error handling code?

[STackPointer64]

Hello, 

Could you please capture the network traffic using Wireshark when you connect the board to the router? Additionally, try stepping through the link speed and duplex negotiation code section to verify if it succeeds. Also, ensure that you use the project that works correctly when connecting the board directly to a PC instead of the router.

Best regards,

[riwe]

Thanks. I cannot capture the network traffic between board and router since the problem only occurs with the router (contains a switch) directly connected to the board. Auto-negotation always succeeds for some reason, but in some cases, I don't receive any packets (yellow LED on the connector is stuck after blinking once). I noticed that connecting any random ethernet switch in between the Nucleo and the router box makes the problem go away.

Therefore, I will put the issue aside for now. It looks like it is a problem specific to this particular router device. It's an older AVM FritzBox used as a wireless access point for my testbed).

[STackPointer64]

I understand. If you encounter the same issue with other hardware, please add the details to this thread. This will help us identify common factors between the cases and potentially pinpoint the root cause.