STM32F207VC - Ethernet with LwIP works after flashing but not any more after power supply is set off and on again

[SRond]

Hello all,

I have a strange behavior with the ethernet connection of my STM32F207 application:

When I flash the software to the controller the software works. I can ping the controller, I can communicate with a client software to the serversoftware on the controller without problems. When I disconnect and reconnect the power supply I suddenly can´t communicate anymore. I don´t think that it is something software related because it works right after flashing.

I have flashed my programm with atollic true studio in debugger mode and with ST-Link-utility both with the same experience as mentioned above. I am flashing my custom board via a nucleo and even after I disconnect the Nucleo my application works as long as I don´t reset the power supply.

My hardwaresettings for ethernet are the default RMII pins on STM32F207() and for the flashing and debugging the swdio (PA13,PA14,NRST). I have quite some other pins in usage but they all work the same before and after only the ethernet does not work right. Maybe one other thing might be important: I don´t have an external timer quartz on my board but I don´t think, that is the problem because, again, why should it work when im communicating after flashing but not work anymore after i reset the power supply.

I believe the flashing sets some pin to another state permanently until the power supply is resetted but I haven´t figured it out yet. Maybe someone has an idea? Or had the same problem and a solution?

thanks in advance

[Piranha]

> I don´t have an external timer quartz on my board

How do you clock MAC and PHY?

> I don´t think that it is something software related because it works right after flashing.

False assumption. Debugger changes timings and flawed software fails because of that.

Do you use RTOS? On what the source code is based - CubeMX, ST's examples, other? For ST's code:

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32

The issues you describe most likely are consequences of the flaws related to incorrect use of lwIP API.

[Ozone]

I suggest to instrument your code to narrow down the exact issue.

Perhaps the debugger is clearing/initializing memeory the startup code doesn't ?

[SRond]

thanks for the quick answers.

@Piranha​ : Yes, I use Freertos. I configured my whole hardware with CubeMX and I don´t even touch the LWIP with my code. It´s a third party software(open62541) that uses Lwip. With running the debugger i get that there are changes in timings and while stopping at breakpoints stopping the programm and stopping the interrupts. But even if I only flash the programm with STM-ST-Link-Utility without any debugging and disconnect right away(disconnect the software and unplug the hardware to flash) I can communicate with ethernet. Unless this tool does something a debugger does or it doesn´t reset the controller to programmcode position 0 after flashing I don´t get why it should interfere with my code in another way than a power supply restart does.

@Ozone​ : If I run the ethernet-part code on a Nucleo-Board it works if i run the code on my customboard, even without the rest of the code, it does only after flashing/debugging not after just turning on the power supply.

again thanks for the quick answers and I am going to look into it.

[Piranha]

> But even if I only flash the programm with STM-ST-Link-Utility without any debugging and disconnect right away

PHY chip and a device on the other side of Ethernet connection is independent from the debugger and starts autonegotiation and/or other processing before you disconnect the debugger. That in consequence changes timings at least for PHY and MAC initialization code.

Also, please describe how the clocks and PHY configuration straps are done.

[Ozone]

> If I run the ethernet-part code on a Nucleo-Board it works if i run the code on my customboard, even without the rest of the code, it does only after flashing/debugging not after just turning on the power supply.

Perhaps some clock setup / stabilization issue ?

The discovery / Nucleo boards use to get clocked by the MCO from the ST-Link MCU.

A quartz on your custom board might have some stability issues, or needs longer startup times.

[SRond]

i use a LAN8742 PHY with the default settings of CubeMX for RMII and autonegotiation.

I didn´t make the hardwarelayout so I am very sorry that I misinformed you yesterday. There was a discussion to leave out the quartzes but actually the one for the PHY and for OSC32IN and -OUT are on board. But the quartz for MCO which was mentioned by @Ozone​ is not on the customboard.

The quartz for the PHY on board is strapped to XTAL1 and XTAL2 pins of the PHY and LED2 Pin of PHY is also pulled to ground so that pin NINT will work as the REFCLKO for RMII-interface.

Later today I am going to check if the quartz is working differently when i turn on the power supply versus after reflashing the software.

Thanks again for your help

[Ozone]

> But the quartz for MCO which was mentioned by @Ozone (Community Member)​ is not on the customboard.

Not sure if I made myself clear.

Later discovery boards and Nucleo boards do not have a quartz for the target MCUs anymore, probably for cost reasons.

The target clock input is fed from the MCO of the ST-Link debug MCU (F103).

Which is basically a standard GPIO, and not a high-impedance quartz.

[SRond]

Just checked the hardware components.

Quartz frequency between XTAL1 and XTAL2 is at 25MHz, frequency RMII-REF-CLK between PHY and µC is at 50MHz. These values are the same if I meassure them right after start or after flashing the code. I just checked with the reference manuals of the LAN8742 and of the STM32F207 that these should be the required values. Under 28.4.4(page 849/1378) of the µC manual is mentioned, that HCLK should be greater than 25 MHz. I have that checked with 120 MHz.

The only thing I am missing on my layout is shown in the picture. I don´t use the STM´s PLL and MCO-Output to generate the frequency. But as I understand it I can work with the way I do. Giving the MAC the 50MHz reference frequency with the RMII-REF-CLK and Setting HCLK over 25MHz. Maybe I am wrong with that?

Since there is no change in the frequencys measured before and after flashing on the peripheral it seems I have to look deeper into what happens when I flash the controller. @Piranha​ Seems your first assumption was right. Thanks again for the information but I wanted to check the easier solutions first.

I am going to share the solution as soon as i have it.

[SRond]

Short update:

when I trigger a system reset through IWDG or through some software reset function the ethernet will start working after the reset without any problems but that can´t be the solution because i have to write some variable to a flash or a rom two times for every power supply enable/disable cycle.

When I try to to reset the ethernet with HAL_ETH_MspInit/MspDeInit with a delay from around a second in between the calls of the first init, the deinit and the second init i can actually ping the controller after i switch on the powersupply and i receive an answer about 40% of the time. Haven´t found a solution to fully init and deinit the lwip stack yet.