2023-12-08 05:33 AM
Hi all,
For the last couple of weeks I've been trying to deal with receiving an ETH frame from PHY on my own PCB design with STM32H730VBT.
To make sure the firmware is OK I took a Nucleo-H723ZI (CPU from the same family) and configured it to work with lwIP under CubeMX - Everything works fine. Frames are sent and received and DMA operation looks like on other STM32H7s.
Then I corrected the GPIO configuration to match my design:
PB11 -> RMII_MII_TX_EN (CS_TX)
PB12 -> RMII_MII_TXD0
The remaining pinout for RMII is identical to Nucleo.
The schematic is typical for the LAN8742A (sorry for circuit quality):
After startup, frames are transmitted but any receive data (multicast, unicast, etc.) is missing.
To eliminate a possible PCB path length error, the port on the switch was forced to T10 (10mbits). The problem also occurs at the 100Mbps/Full-duplex setting.
The RMII paths on the PCB between the CPU and PHY are max 30mm long.
And here's a list of what I've already checked so far:
- GPIO and ETH register configuration: Since this is almost identical firmware to the Nucleo, the differences are only at GPIOB (TX_EN + TXD0). CPU_CLK=500Mhz (HSI+PLL). HSE disabled.
- CRS_DV, RXD0, RXD1 lines checked with oscilloscope at CPU itself - everything looks like on Nucleo. I added a simple routine to make sure the data is physically received by the CPU:
As you can see, high level states readings are appearing (according to whether a packet appears after ETH). If packets received by PHY do not appear then the counters do not increase.
- I checked CLKIN - It is ok. In a configuration with a external 25Mhz quartz on the CLKIN+CLKOUT lines, the reception problem still occurs.
- I soldered the new LAN8742A from the working Nucleo - did not help
- I soldered wires all the RMII lines between working Nucleo board after removing the CPU and my PCB. Same thing.
- The REF_CLK line generates a perfect 50Mhz. As a precaution, I connected an arbitrary generator for testing purposes - it didn't help. Data is transmitted but not received.
- A high signal never appeared on the LAN8742A RXERR line (no errors on PHY RX).
- After setting Loopback in LAN8742A (REG_0x00, bit 14) I can see on RXD lines the frame I transmit - still no data reception on CPU.
- Instead of the sample firmware generated by CubeMX, I used our (proprietary) libraries to support the STM32H730 - Only transmitting works.
And now the best part:
- After setting Loopback in ETH_MACCR.LM (bit 12), the firmware correctly receives the frames it sends - the buffers are filled correctly and the DMA works as it is written in DMARxDscrTab.
I can't think of anything else that can be checked.
I'll add that the problem occurs on other PCB copies of this project, so it's not likely a burnt CPU or PHY.
The current consumption of the whole (CPU + PHY) is about 250mA, which is similar to the Nucleo.
I am slowly starting to suspect some HW bug ;)
Any help to get this problem moving is welcome. Maybe I forgot something or don't know.
Greetings from Poland,
Lukasz.
Solved! Go to Solution.
2023-12-13 10:37 AM - edited 2023-12-13 10:42 AM
Hope you are better now.
> PC4 was swapped with PC5 (RXD0 <-> RXD1).
Glad you've found it.
> I don't know how I didn't catch it before
I know how. It's the classical case of author's blindness. The best way to solve this sort of problems is to explain the minute details to ANYBODY, especially to somebody who knows nothing of the problem and is not shy to ask dumb questions. @Andrew Neil used to say, "tell it to the teddy bear".
What you've done - that you went away from the problem for a couple of days - is just another great debugging technique.
JW
[EDIT] much of the links are rotten, but with some perseverance, here's where Andy's original link pointed.
2023-12-14 05:04 AM
Ah, great to see that the old 8052mcu.com is still there!
Last time I tried, it seemed to have disappeared.