STM32H747I-DISCO with LWIP not working

[Ericson Joseph]

Hi,

I am working with STM32H747I-DISCO but the lwip not working. I have apply the recommendations here https://community.st.com/s/article/FAQ-Ethernet-not-working-on-STM32H7x3 but the LAN8742.c have infinity loop in line 170.

 while(regvalue & LAN8742_BCR_SOFT_RESET)

          {

            if((pObj->IO.GetTick() - tickstart) <= LAN8742_SW_RESET_TO)

            {

              if(pObj->IO.ReadReg(pObj->DevAddr, LAN8742_BCR, &regvalue) < 0)

              {

                status = LAN8742_STATUS_READ_ERROR;

                break;

              }

            }

            else

            {

              status = LAN8742_STATUS_RESET_TIMEOUT; // <-- LINE 170

            }

          }

Anyone can help me!

[Piranha]

Most likely wrong PHY/RMII clock and/or GPIO pin configuration.

[Ericson Joseph]

Thank you very much for your answer.

My GPIO configuration is:

    __HAL_RCC_ETH1MAC_CLK_ENABLE();
    __HAL_RCC_ETH1TX_CLK_ENABLE();
    __HAL_RCC_ETH1RX_CLK_ENABLE();
 
    __HAL_RCC_GPIOG_CLK_ENABLE();
    __HAL_RCC_GPIOC_CLK_ENABLE();
    __HAL_RCC_GPIOA_CLK_ENABLE();
    
 /**ETH GPIO Configuration    
    PG11     ------> ETH_TX_EN
    PG12     ------> ETH_TXD1
    PG13     ------> ETH_TXD0
    PC1     ------> ETH_MDC
    PA2     ------> ETH_MDIO
    PA1     ------> ETH_REF_CLK
    PA7     ------> ETH_CRS_DV
    PC4     ------> ETH_RXD0
    PC5     ------> ETH_RXD1 
    */
    GPIO_InitStruct.Pin = ETH_TX_EN_Pin|ETH_TXD1_Pin|ETH_TXD0_Pin;
    GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
    GPIO_InitStruct.Alternate = GPIO_AF11_ETH;
    HAL_GPIO_Init(GPIOG, &GPIO_InitStruct);
 
    GPIO_InitStruct.Pin = ETH_MDC_SAI4_D1_Pin|ETH_RXD0_Pin|ETH_RXD1_Pin;
    GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
    GPIO_InitStruct.Alternate = GPIO_AF11_ETH;
    HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);
 
    GPIO_InitStruct.Pin = ETH_MDIO_Pin|ETH_REF_CLK_Pin|ETH_CRS_DV_Pin;
    GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
    GPIO_InitStruct.Alternate = GPIO_AF11_ETH;
    HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
 
    HAL_NVIC_SetPriority(ETH_IRQn, 0, 0);
    HAL_NVIC_EnableIRQ(ETH_IRQn);

Is it ok for the STM32H747I-DISCO platform?

[Tomas DRESLER]

Seems legit. What PHY number does it use? Do you see communication on the MDC/MDIO lines?

Btw. do you have correct setup of register and flag positions in the PHY description? Like this BCR register and LAN8742_BCR_SOFT_RESET?

[Ericson Joseph]

Hi Tomas,

Thank you very much for your answer,

1. What PHY number does it use?

I using the ETH1 with interface RMII.

1. 2. Do you see communication on the MDC/MDIO lines?

I don't have an oscilloscope to verify :(

1. 3. you have correct setup of register and flag positions in the PHY description? Like this BCR register and LAN8742_BCR_SOFT_RESET?

This function 'pObj->IO.ReadReg(pObj->DevAddr, LAN8742_BCR, &regvalue) ' always set regvalue with 0xFFFF.

​I use HAL library for set PHY registers. I attach files that can help.

[Piranha]

> Btw. do you have correct setup of register and flag positions in the PHY description? Like this BCR register and LAN8742_BCR_SOFT_RESET?

BCR, BSR and some other registers are defined by MII specification and are the same on all PHY chips. The one to check is extended status register and it's bits, as those are vendor specific.

> I using the ETH1 with interface RMII.

That is not PHY address. PHY address is address of a PHY chip on a MDIO bus somewhat similar to I2C chip address on I2C bus.

> This function 'pObj->IO.ReadReg(pObj->DevAddr, LAN8742_BCR, &regvalue) ' always set regvalue with 0xFFFF.

Most likely because of wrong PHY address in that same pObj->DevAddr. For most if not all Nucleo and Discovery boards, including this one, PHY address is 0.

[Pavel A. · Accepted solution]

> have infinity loop in line 170.

Ah, another bug. A break from while loop is needed after line 170 . Reported.

-- pa

[Piranha]

So that's from where that code comes. Looked at that code more closely... Almost 1000 lines for basic PHY management, 80% of which could've been done universal, because most of the PHY functionality is defined by standard and registers are the same on all PHY chips. I have my own pretty flexible "OS" consisting of cooperative scheduler, unlimited software timers and event signal/wait functionality in 400 lines of simple code! Does ST have some internal contest of who will write more useless code bloat for the same functionality?

To me it seems that the higher the code abstraction layer, the more stupid ST's code is. BSPs seem to be the "best" in this regard. Seriously - is there anyone, who is actually using that crap?

[Pavel A.]

@Ericson Joseph @Tomas DRESLER​ ​

 Joseph, a ST engineer is looking at the issue on gihub and requests more info. Could you join there, please?

Thanks,

-- pa

[Imen.D]

Hello All,

Thanks for your contribution and highlighting this issue.

This problem was solved with the new release of STM32CubeH7 firmware package.

We will close this thread.

Best Regards,

Imen