2025-08-28 6:10 AM - last edited on 2025-08-28 6:58 AM by STackPointer64
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:
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
2025-08-28 8:40 AM
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():
2025-08-29 1:07 AM
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
2025-09-04 11:12 PM
Any hints?
2025-09-30 1:32 AM
Some more info.
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?
2025-10-01 4:05 AM
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,
2025-10-01 5:08 AM
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).
2025-10-01 6:15 AM
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.