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.

[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.

[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.

[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.

[Sebastiaan]

Hello,

Have you made more progress?

I am observing the same issue, I believe. I'm just trying to hunt it down. It seems that HAL_ETH_ReadPHYRegister always returns RegValue 0xffff after poweron, untill a new reset (and initialization) occurs. The consequences are drastic, the first one I spotted is that when autoneg is enabled, it's likely that the settings are incorrect. But clearly, any action based on a PHY register value can cause issues.

A likely root cause is that the STM32 ethernetif.c library does not correctly initialize the ethernet interface (PHY and/or MAC?). It's clearly not a timing issue because introducing a sleep of 1 (or more) seconds before e.g. GPIO initialization doesn't change a thing.

Please confirm if you have the same issue (HAL_ETH_ReadPHYRegister returning RegValue 0xffff).

To make your workaround a bit more robust, you could change the ethernetif.c to do a system reset (HAL_NVIC_SystemReset) if 0xffff is returned by the read function.

[Sebastiaan]

This workaround seems to work fine for me. I put it in HAL_ETH_Init just below the first HAL_ETH_ReadPHYRegister function (which will only work if autoneg is enabled in your config!!!).

Maybe another idea to explore is to see if the PHY reset just above actually works (by scoping the MDIO interface).

[sne_123]

Hello Everyone.. I am facing the same issue. I am trying to reinitialize ethernet and lwip stack through software but its not working... Once deinit is called, netlink fails to go up after initializing it again....Can anyone help me on how to reinitialize ethernet and lwip stack

[rromano001]

Hello sne_123, at first PHY reset is same as MCU or separate?

LWinit is called from default task and no patch can be added delay few mS by osDelay function to assure complete PHY chip reset was done.

If you added a reset PHY GPIO then add a delay after release of port.

Why you need reinitialize Ethernet and stack too?

Which chip are you using?

[Sebastiaan]

I might have found the issue that I was suffering from. In my case, the RX_ER pin was configured to be high, in order to have a PHY address of 1. However, I left the PHY address of the LAN chip in cubeMX to be 0. Clearly this does not make much sense.

So my conclusion is that the LAN chip first sampled the GPIO on a moment that it was high (hence using address 1 and not working on address 0). Then, after a reset, the CPU and LAN are reset simultaneously, and all GPIO's are LOW at that time, resulting on phy address 0, even though RX_ER was later put HIGH again in my case.

So @sne_123​ please verify your RX_ER setting and phy_address configuration.

[Sebastiaan]

Another important point to realize is that LWIP only sets the netif up if the link is up at initialization. See MX_LWIP_Init:

 if (netif_is_link_up(&gnetif))

 {

   /* When the netif is fully configured this function must be called */

   netif_set_up(&gnetif);

 }

 else

 {

   /* When the netif link is down this function must be called */

   netif_set_down(&gnetif);

 }

=> if your ethernet cable is not plugged in at startup, and "netif_set_up()" is not called explicitly, the packet intake will fail (see e.g. ip4_input_accept() in ip4.c)

=> I changed this into always setting the network interface up, even if there is no ethernet cable.

[rromano001]

Hello Sebastiaan, I got here from link you posted in my thread:

PHY register returning 0xffff is due to a flaw of software, if you or other like I can post full log of MDIO data traffic. Anyway this is not useful than proving Software has lot of issue. Patching register access on CUBE_IDE or CUBE_MX solve some but too many bug still remain in place, first of all is HAL!!

@Piranha​ @Tilen MAJERLE​  Code style resemble hobby grade than professional. Wonder it work sometimes, cannot figure how a large company team has no knowledge about OS theory nor Network coding. Tilen, I seen your Library and I like coding style, please can you help us in some way to try kick out buggy library?

@Amel NASRI​ @Imen DAHMEN​ 

hello, I seen you got called about these issues, please can you tell us why programmer are not able to address OSes and concurrent network programming? Please also check my post is following this line. Thank you

https://community.st.com/s/question/0D53W00000yVgYSSA0/stm32f407vet6-custom-board-ethernet-not-working?t=1629273027633

Here you can see in first post PHY protocol was analyzed wrong PHY address is used on register 0x1F.

Ping ICMP and ARP appear at PHY Rx side but no activity on TX side. (Expected ARP reply and ping reply)

[Sebastiaan]

Romano, let's calm down.. STM's profitability is in selling chips. Yes, they provide examples and libraries as support, but libraries are almost never perfect. Let's focus on your issues in your thread.