Could not get example running on STM32F107RC

[ubruhin]

Hi,

First of all, many thanks for this awesome project! I am trying to get it running on a STM32F107RCT6 with LAN8720A, but unfortunately without success so far. Although I'm a professional firmware developer, I have no experience with Ethernet yet so I'm still trying to understand how all this works in general. Also I don't know if my custom hardware is fine or not.

It would help me a lot to get some feedback if the examples provided here should actually work out of the box with my hardware or if there's something missing or wrong. Let me quickly explain my situation:

Here's my schematic: d0-reader_v1_Schematic.pdf

What I did:

export DEFMT_LOG=info
export PROBE_RUN_CHIP=STM32F107RC
cargo build --release --example ip --features stm32f107,smoltcp-phy --target thumbv7m-none-eabi
cargo run --release --example ip --features stm32f107,smoltcp-phy --target thumbv7m-none-eabi

The output:

    Finished release [optimized + debuginfo] target(s) in 0.03s
     Running `probe-run target/thumbv7m-none-eabi/release/examples/ip`
(HOST) INFO  flashing program (38 pages / 38.00 KiB)
(HOST) INFO  success!
────────────────────────────────────────────────────────────────────────────────
INFO  Enabling ethernet...
└─ ip::__cortex_m_rt_main @ examples/ip.rs:45
^C────────────────────────────────────────────────────────────────────────────────
(HOST) INFO  program has used at least 9.06/30.92 KiB (29.3%) of stack space
stack backtrace:
   0: stm32_eth::dma::EthernetDMA::new
        at src/dma/mod.rs:69:15
   1: stm32_eth::new
        at src/lib.rs:139:15
   2: ip::__cortex_m_rt_main
        at examples/ip.rs:56:9
   3: main
        at examples/ip.rs:36:1
   4: Reset
(HOST) INFO  device halted by user

(aborted with Ctrl+C after the output stuck at "Enabling ethernet...")

I also tried to debug the firmware and it looks like the CPU hangs forever at waiting for the DMABMR.SR bit.

Do you have any suggestion where the problem might be located? I'd highly appreciate any input.

My general questions are:

• Is the example really expecting that RMII_REFCLK is provided by the LAN8720, not from the microcontroller? If I understand the LAN8720 correctly, the "clock output"-mode needs to be explicitly enabled, but I don't understand if and where this is done in the examples provided here.
• As far as I can see with the scope, there's indeed no clock signal on the RMII_REFCLK line at all - should the clock be continuously there or only if there's any data communication?
• Don't we also need to control the LAN8720 reset line from the microcontroller to ensure proper initialization?
• What should the LEDs connected to LAN8720 actually do, are they enabled by the example to indicate an active link and communication? Currently my green LED is constantly on, no matter if a cable is connected or not...

Thanks!

[datdenkikniet]

Hi, thank you for your feedback!

AFAIK all of the example boards (and all of the ways I have tried using this crate so far) rely on the PHY generating RMII_REFCLK, so the examples do so too. We should definitely add some documentation clarifying this.

• It should be possible to generate RMII_REF_CLK from the MCU itself. It is described in the reference manual. If you manage to get it working, please let me know so we can make sure the examples also support this :)
• I don't believe the ethernet parts of an stm32 ever actively interact with any reset pin (it is not part of the RMII interface). You can configure/set up the reset line separately, but it is not (currently) handled by either the ieee802_3_miim lib or stm32-eth. Since it is a GPIO function, we rely on a soft reset instead.
• I don't know what the LEDs on LAN8720 are supposed to do. If there is no ref_clk it may be that they are stuck in whatever their startup state is, or they are misconfigured in some other way.

[ubruhin]

Alright, thanks for clarifying!

AFAIK all of the example boards (and all of the ways I have tried using this crate so far) rely on the PHY generating RMII_REFCLK, so the examples do so too. We should definitely add some documentation clarifying this.

OK perfect, so in this case the examples should work with my board as well :thinking: It would be good to know on which boards you tested this crate (some ST eval boards? Or other boards with publicly available schematics?). Knowing the schematics of tested boards would allow users to design custom hardware the same way (using the same PHY and pinout) to be sure the circuit is fine and compatible with this crate.

It should be possible to generate RMII_REF_CLK from the MCU itself. It is described in the reference manual. If you manage to get it working, please let me know so we can make sure the examples also support this :)

Maybe you misunderstand my question, my intention is to use RMII_REF_CLK from the PHY :slightly_smiling_face: My hope is that this way the MCU doesn't need an external oscillator at all.

[datdenkikniet]

Hmm, yes then they should work.

One board I've tested on that worked for sure was a NUCLEO-F767I. I have found schematic.zip on the ST website, which has a LAN8742A and I think quite accurately describes what the setup should look like. For the purposes of the ref clock I think it is equivalent to a LAN8720A.

I think the LAN87XX needs an external oscillator to generate the ref clock as well, which doesn't seem to be present on your schematic :( As I understand it though, you should, theoretically, be able to generate the 25 MHz input clock using your MCU. Not sure what the specs of that clock signal are required to be, though. scratch that, it is obviously there but on the right side 🤦

Not entirely sure how it works (I was never a HW design person), but hope it helps!

[ubruhin]

OK thanks, then I'll compare the NUCLEO-F767I schematic with mine to see if there are any incompatibilities. But unfortunately it's an STM32F7 while I have an STM32F1 so even with the same circuit there could be incompatibilities in the MCU peripheral. Thus I still have no idea if my hardware should work with this crate or not.

Anyway, thanks for your help. I think we can now close this issue.

[ubruhin]

For those having the same problem, I found the root cause in my case: It was a missing 10k pull-down on the LED2/nINTSEL pin of LAN8720A :sob: The pulldown is required to enable clock output at the REFCLKO pin.

With this resistor in place, the clock is output on REFCLKO even in reset state - once I figured this out on a NUCLEO board, it was much easier to debug HW problems since firmware problems can be ruled out for clock problems.

After adding the missing resistor, stm32-eth works out of the box on my custom PCB! :rocket: