STM32F4x HAL_ETH_ReadPHYRegister blocking mode

[Davide Dalfra]

Dear all

After having enabled ETH + LwIP stack we are experiencing that something in the init phase are keeping blocked all.

After a while we see that the root causes is inside HAL_ETH_ReadPHYRegister.

Specifically we are referring at this part of code:

Is there any way to make this in a better way?

Davide

[Pavel A.]

As you see from the code, reading the PHY register has timeout and should not loop forever.

Check that the HAL timer runs, isn't obstructed by a higher priority interrupt etc.

[Davide Dalfra]

Hi

Yes, the timeout in a way or in another finish. When i said all , i mean all "for a certain period of time".

I was wondering of a way to have a non-blocking mode for this.

[Piranha]

The main delays are caused by waiting on a link to become active and then waiting on auto-negotiation to complete. Without HAL modification you can initially disable auto-negotiation, which will avoid those two wait loops, but the code will then wait on this delay, which you can minimize with this macro. And in both cases the code will also always wait on this delay, which can also be minimized with this macro. One can enable auto-negotiation and detect link state properly after this initialization code has been run.

In reality in peripheral initialization code there is no reason for doing a peripheral reset, it should not wait on link or auto-negotiation status, and NONE of those delays are necessary at all. That code is written by completely incompetent people!

[Pavel A.]

IIRC in the expected ETH driver rework they plan to decouple ETH driver from PHY handling

[Davide Dalfra]

Thanks for this complete answer.

Also based on your suggestion on a previous post, i had managed out how to fix all the "re-entrant" issues LWIP integration in ST libraries.

If the same who wrote the integration of lwip have put his hands on HAL, it can explain how badly this has been made.

Thanks again

D.

[MWB_CHa]

Hello,

Let's agree first on one point:

• Before the while loop, there is the write of MACMIIAR register.
• After the while loop there is a read from MACMIIDR register

As you can see in reference manual extract below, the MACMIIDR is invalid until the busy flag is cleared. So before reading MACMIIDR, user must wait until busy flag is cleared.

 

So, we think The simple way to do deal with the problem described here, is to set PHY_READ_TO to 0.

Otherwise, when set the busy flag ETH_MACMIIAR_MB indicates that a read or write operation is ongoing. So you should wait until the bit is cleared.

I hope it helps.

[Piranha · Accepted solution]

You explained the obvious part of this, which was probably already understood by everyone anyway, but, of course, you completely ignored the actual issues with delays spread all through your broken bloatware, which I reported in my previous post...