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

[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

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

[Piranha]

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

And that is the proper way of doing it. A single line of code, but ST's developers cannot grasp it...

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

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

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.

[rromano001]

Hello Sebastiaan, in first Please accept my apologies if something was hurting you.

About my issue is not mine code, definitively Is Code generated from cubeide.

About profitability, ST has to remove issue from software otherwise good hardware has less power than worst of worst paced by good software.

What got me again more scared? Thread you pointed was seen by me but I realized late reading here is not calling the right api!

Link Up Link Down MUST be signaled to Stack by proper Link set up down. This code SHUT DOWN INTERFACE!! This is a **SEVERE** bug.

Read from LWIP documentation and you discover that API has this effect: "Bring an interface down, disabling any traffic processing."

https://www.nongnu.org/lwip/2_0_x/group__netif.html#ga641d07ed8c31fe5306bc01605a6790cf

netif_set_link_down(&gnetif); and netif_set_link_up(&gnetif); ***NOT*** netif_set_down(&gnetif); (Edit:) These API are to be handled by Ethernet driver not this way and not as consequence of link query. This is a contribution to deadlocking stack.

Again this is also on Piranha post, but two year later all bug are in place plus new ones.

I asked FAE if some customer use network and how they solved issue. It was unaware of. This is not for discarding this company, is near my home and in my country but I am asking for quality raise. Quality this way drop away.

Only solution now can be read in its entirety documentation of Adam Dunkel LWIP then rewrite from scratch an LL or register based Ethernet driver as was done by Piranha.

ST Hardware IPCORE from what I tested is perfect as can be my design.

(edit:) Check this too: https://www.nongnu.org/lwip/2_0_x/pitfalls.html

Flaw are addressed by Piranha in his post then in parallel to what I discovered before new sequence: shut down, ask FAE then wait for a while a possibly simple solution.

Cheer