STM32H730 ETH receive not working

[Lukasz_Klis]

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.

[LCE]

Firmware:
You are 100% sure about the GPIO / AF settings?
Have you compared all the GPIOs in the datasheets? In the H723..H735 series not all are pin-compatible to each other.
Maybe the "new" GPIOs are re-initialised later on for some other peripheral?

Hardware:
- Have you checked the RMII signal lines with a scope? On both sides of the serial Rs?
- Have you checked the serial resistors in the RMII lines? Maybe there's some 10k instead of 33R.
- Checked for some soldering problems, maybe some solderball between some pins, or some pin not really connected to the pad?

[waclawek.jan]

 It's frustrating that you've already excluded the simpler problems, so I can't come up with them... :)

Can you write software so that you can run *identical* binary on both targets (for purposes of setting up those two pins, writing two branches, based on unique-id, package-id register if present, or state of some jumperable input pin, etc.)?

JW

[Lukasz_Klis]

Hi LCE,

Thanks for your reply.

I am 100% sure of this GPIO configuration, because only pins PB11 (RMII_MII_TX_EN) and PB12 (RMII_MII_TXD0) are different but transmitting works OK.

I checked all RMII lines with an oscilloscope and compared with Nucleo - No differences. Even the latency and noise level was a similar.

I checked 3 different assemblies (copies) of this device. They all have the same problem. Rather, bad soldering can be ruled out (RXD low/high signals are visible in the GPIOC->IDR register).

[LCE]

Okay, then it's seemingly not the PCB, the assembly, or the soldering.

Any other peripheral using these GPIOs?
Or something super simple, like GPIO clock not active?

[Lukasz_Klis]

Hi Janku,

I did exactly as you wrote - There is one firmware and I switch the configuration of two GPIO lines using one of the pins - nothing more, nothing less. :)

On Nucleo all is working perfect, on my device I see only TX frames (in Wireshark).

PC is connected to Ethernet switch and this port is configured as "data mirroring' (I see all eth communication packets).

Also all was tested on simple 100Mbps router too and nothing has changed. 

LK

[Lukasz_Klis]

Clock source is the same like in Nucleo (HSI + PLL1).

Firmware is the same. I described the differences in performance above.

LK

[waclawek.jan]

> There is one firmware

Is it the same *binary*?

JW

[Lukasz_Klis]

Sorry for the interruption (I got sick).
To make sure the firmware doesn't affect this problem I connected the PG11 pins to PB11 (ETH_TX_EN) and PG13 to PB12 (ETH_TXD0) on the Nucleo board.

I loaded exactly the same HEX file to my own PCB but the problem is exactly the same (you can see packets sent, and no packets received).

I have absolutely no idea what is going on.

At this moment I just wait for STM32H723 version in LQFP100 fitted in my PCB...

[Lukasz_Klis · Accepted solution]

I found it !!!

I don't know how I didn't catch it before, but PC4 was swapped with PC5 (RXD0 <-> RXD1).

The best part is that I thought the order was correct.

Problem solved.

Apologies for the confusion and best regards.