STM32H7 PHY driver for LAN8742 2s delay

[JDosp.1]

Hi All,

Can somebody point me what is a reason for 2 sec delay at PHY driver for LAN8742?

I mean code below at function LAN8742_Init() inside file lan8742.c.

if(status == LAN8742_STATUS_OK)
{
 tickstart = pObj->IO.GetTick();
 
 /* Wait for 2s to perform initialization */
 while((pObj->IO.GetTick() - tickstart) <= LAN8742_INIT_TO)
 {
 }
 pObj->Is_Initialized = 1;
}

I am working at project with STM32H735 and ThreadX+NetX Duo. As PHY I use KSZ8081RNA, but I found that same delay need be there as at LAN8742 driver. Without this delay Ethernet does not work. With 2 sec delay works auto-negotiation with 100MB switch, but not with 1GB switch. For 1GB switch need be there ~3 sec delay.

I am not sure what is going on here. I didn't found anything related to this delay at KSZ8081 datasheet, IEEE spec for auto-negotiation or at STM32H735 errata. I will be gland for any comment.

Thanks.

Regards,

Jan

[Piranha]

The reported issue is relevant for all series with rewritten ETH drivers - F4, F7, H7.

There is no actual need for any delay at all. The only reason why there is such a delay is because the HAL/Cube developers are incompetent. They are waiting for auto-negotiation to complete for 2 seconds, but in reality Auto MDI-X + Auto-Negotiation often takes even more than 4 seconds. After LAN8742_Init() they call LAN8742_GetLinkState(), which is a stupid thing to do and with a too short timeout it is even broken. For example: NetX Duo and lwIP code. And CubeMX generates the same stupid code.

All of that should be irrelevant because the initialization code should not manage the link state at all. The HAL/Cube developers just cannot understand asynchronous and other non-trivial principles...

[Pavel A.]

@Piranha​ So what is the right way? Should there be a 'dead time' of N seconds from PHY reset to first check of negotiation state, or the nego state can be read immediately?

[Piranha]

The right way is to not do any link state management in initialization code at all. Just initialize the IP stack and other software in "link down" state and let the normal link state management code do what it's supposed to do. In the current implementations for lwIP it's the ethernet_link_thread() thread. That code monitors the link and auto-negotiation state and does the necessary reconfiguration when necessary. The action can be triggered by an external interrupt line from PHY, a periodic timeout or a smarter but simpler and more efficient Rx event timeout like I described in this topic.

And in my opinion the PHY reset is also an unnecessary code and delay. The PHY is already reset by the hardware - why would we need to reset it again?

[JDosp.1]

Hi Piranha,

Thank you for your answer. I get your point. I quickly looked into structure of driver and I agree with you. For real application this need to be rewritten including initialisation of Ethernet driver.

I mainly contribute to TI e2e community forum (~2.5k posts) but at ST forum I am newbie. Form this reason I really appreciate such answers like yours.

Jan

[Piranha]

In case you didn't found... Not everything is relevant for NetX Duo, but still check this:

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

[MWB_CHa]

Hi @Jan Dospěl​ ,

Welcome in STM32 forum.

We acknowledge there are still some weaknesses in the ETH drivers after the full rework done beginning of this year.

We fixed multiple points on HAL and applications based on customers' feedbacks. BSP remains to be addressed.

The timing in PHY Init function is indeed necessary in the current architecture and shall be explained more in details.

We will try to add some explanations about its value and its relation with different PHYs and different speeds configurations.

In the same time, @Piranha​'s suggestion about getting rid of the timing and changing the architecture, despite being disruptive, might make sense and will also be studied.

In any case, a more elegant solution shall be proposed allowing to remove the need for a timing loop.

We appreciate all the feedbacks (even when in harsh and exaggerated format). It allows us better serve customer's needs and I can ensure that our team is currently working on studying and answering as many points as possible.

Please have a look at this post that explains the HAL rework and issues addressed early this year: 

https://community.st.com/s/question/0D53W00001Gi9BoSAJ/ethernet-hal-driver-reworked-by-st-and-available-in-22q1-preview-now-available-on-github

Kind Regards,

[JDosp.1]

Hi Chekib,

Thank you for comment.

Current Ethernet driver initialisation is far from ideal. But it is nothing could not be relatively easily fixed, but end users need to be aware of this. Usage of delay for PHY initialisation is not such big issue, if we not count using blocking delay at RTOS environment. I think main problem is when PHY initialisation failed, than is not called HAL_ETH_SetMACConfig() and Ethernet will not work.

I don't think that my comment is harsh or even exaggerated. But if it seems that way, I apologize for that.

Regards,

Jan

[MWB_CHa]

Hi @Jan Dospěl​ ,

Thanks for the additional comments. Yes, absolutely, the management of the case when Init is failing due to wrong timing shall be added (and at best remove completely any timing usage).

No need to apologize, I wasn't meaning your comments specifically, but other users comments, that we absolutely understand and welcome regardless of their format.

Kind Regards,

[GJord.4]

Hi @MWB_CHa​ ,

We are currently in the process of switching to STM32H723ZG as the MCU in one of our products. We also plan to use it in the development of our new products. We are using it with Azure RTOS NetX, and found this same issue with the ethernet PHY driver. It is currently putting the project in risk, so we might have to look for alternative options.

What is the status of this issue? Are you working on releasing a fix for it soon?

Rgds Geir

[JDosp.1]

Hi Geir,

What issue do you have with driver? With some minor tweaking is PHY driver and link control state machine perfectly fine and works well. With STM32H735@400MHz I have no issue to transfer 70Mbps continuously via http protocol. For tests I used KSZ8081RNA. Now I moving to DP83826. DP83826 have better performance at long cable (100m+).

I found only a few minor issues with NetX Duo. DHCPv6 client have a few bugs and there is issue with cypher suites for tls, especially when you want to have HTTPs server.

Regards,

Jan

[GJord.4]

Hi,

The issue is the 2 seconds delay after initializing the driver. We are using RTOS with watchdog, so this will block the threads and make the watchdog expire. The init method should not just wait for nothing, it could return and let the user handle the linkstate separately, just like @Piranha​ suggested.

/Geir

[JDosp.1]

Hi Geir,

That delay can be removed from PHY init without any issue. At your link state handling thread you need to call nx_ip_driver_direct_command(&ipInstance, NX_LINK_ENABLE, &status); when you detect link up state.

Jan

[GJord.4]

Ok, thanks for the tip on the link state.

The problem with removing stuff from the driver, is that it will be reset when we recreate the files from CubeMX. We have to recreate the project several times during the development phase.

I will fix it manually for now, but ST should really update the driver for a permanent fix this.

/Geir

[MWB_CHa]

Hi @GJord.4​ ,

OK, the LAN BSP drivers are being fixed and the internal ticket number is 151568.

The fixe will be first deployed on STM32H7 then follow for the other series asap.

Sorry I can't provide an exact date for the moment since it depends on the overall maintenance plan of STM32H7.

Thank you for highlighting this point.

[GJord.4]

Hi @MWB_CHa​ ,

That is good news! We will make a workaround for now, and look forward to getting your permanent fix for this.

/Geir