Skip to main content
Visitor II
November 11, 2021
Solved

STM32F4x HAL_ETH_ReadPHYRegister blocking mode

  • November 11, 2021
  • 4 replies
  • 3873 views

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:

0693W00000GXG4xQAH.pngIs there any way to make this in a better way?

Davide

    This topic has been closed for replies.
    Best answer by Piranha

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

    4 replies

    Super User
    November 12, 2021

    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.

    Visitor II
    November 12, 2021

    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.

    Graduate II
    January 15, 2022

    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!

    Super User
    January 16, 2022

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

    ST Employee
    February 10, 2023

    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

    0693W00000YAUeMQAX.pngAs 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.

    0693W00000YAUcWQAX.png 

    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.

    PiranhaAnswer
    Graduate II
    February 12, 2023

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