I am testing the ethernet on our custom board with a STM32H745IHx MCU attached to an 8740A phy chip. We want to use RMII mode. Currently, I am failing the loopback test. We are not sure why this failure is occurring.
I am testing the ethernet on our custom board with a STM32H745IHx MCU attached to an 8740A phy chip. We want to use RMII mode. Currently, I am failing the loopback test. We are not sure why this failure is occurring.
I put my code on a nucleo board, and the loopback test works, so I don't think it's my code. This problem occurs only on our setup. I have included a schematic of our setup so you can see it clearly.
The loopback mode is enabled by setting the loopback bit in the BCR register. The chip should send back on RXD0 and RXD1 what the MCU sends out on TXD0 and TXD1. I am wondering if we have an issue with the clock. Any ideas?
FYI, we can see signals on RXD0,1 and TXD0,1 and TXEN and CRS_DV seems to work. We noticed the TX signals seem to be working at a period of 40 ns, which indicates they are being transferred at 25MHz, which is odd, because we expected 50Mhz
I don't know anything here but I'll have a stab...
RM0433 rev7 describes the loopback (LM) in the ETH_MACCR register. Perhaps you're using early documentation?
In case it's pertinent, its description says "When this bit is set, the MAC operates in the loopback mode at MII. The MII Rx clock input (eth_mii_rx_clk) is required for the loopback to work properly. This is because the Tx clock is not internally looped back."
> we expected 50Mhz
The 8740A's the source. Is RMIISEL correctly strapped?
After you've resolved your PHY problem, check out my bug-fixes and improvements to ST's STM32H7 ETH driver and lwIP ethernetif.c at https://community.st.com/s/question/0D50X0000C6eNNSSQ2/bug-fixes-stm32h7-ethernet. Post questions about it there. If you use it, to assist other developers, please post a summary there confirming it's ok and/or any problems with it you'd had to solve. Thanks.
The loopback mode is not controlled by the MCU, it's set on the phy chip using the bcr register. All it does is direct the phy chip to send TXD signal from the MCU up the RXD signals to the MCU. On the nucleo, when I send the dhcp discovery packet, I can see the MCU firmware gets the dhcp packet in response. That's the test. No response occurs on our firmware.
The RMIISEL is correctly strapped high, and we can verify this by reading the SMR register. on the phy chip.
The next things that come to my mind are speed and duplex settings in both PHY and MAC. Does the settings in MAC match with the PHY? Also haven't looked into that, but.. how does autonegotiation deal with loopback test? What happens without loopback test - does it send and/or receive frames to/from some PC on a network?
And just to be sure you are informed the "quality" of HAL/CubeMX code non-working bloatware...
I am looking through the ethernet registers, but I haven't found a way to set the speed. I can set RMII mode or MII mode. We are set to RMII. There is also no speed setting in the STM32CubeMx app for the ethernet driver on the MCU. I thought speed was set by the reference clock that is provided to both the MCU and the phy chip from a external clock generator. We have checked (and checked again), that it is 50 Mhz. I believe that sets the speed between MCU and phy.
With respect to auto-negotiation, that's a process that relates to how phy chips communicate with each other. When I initialize the phy and before I set loopback in the BCR registers, the phy establishes a link to a switch. When I enable the loopback, the link light on the switch disappears, and the link light on our board stays on. That's because the loopback is a test of how the MCU communicates with the phy.
You are looking for bits FES and DM in ETH_MACCR register. Those must match the respective bits in PHY BCR register, when auto-negotiation is off, and HCDSPEED value in register 31, when auto-negotiation is on and done. The status of auto-negotiation can be read from both - BSR and register 31.
This is a screen capture of a scope trace of TXD1. This signal looks strange. We disconnected TXD1 from the phy so we could see only what was coming out of the MCU. Any ideas why this is happening?
Check the solder quality. Check the GPIO configuration, probably try different speeds for pins.
And this is what I wrote before the oscilloscope screenshot...
It still can be a software issue. Being able to receive few frames on one board doesn't mean that the code is correct. Do you use any of ST's code? Who wrote the ETH driver and related network code? Have you checked the code for issues described in alister's and my topics? =)
