lwIP stuck at xSemaphoreTake

[Petr3]

Hi, i have STM32F767 and im using FreeRTOS V2 and lwIP. Im facing known bug which should be fixed in FW_F7 V1.17 and im using FW_F7 V1.17.2 and still facing this.

When i connect the ethernet cable, after 2 seconds FW is stuck at following place:

I tried to disable DHCP everyting is ok, but when i try to ping the board the result is the same.

Can you help me to solve this issue?

[STea]

Hello @Petr3,

are you sure you are using the latest version of CubeFirmware as you can see that this fix is available on GitHub 
Release v1.17.2 · STMicroelectronics/STM32CubeF7@767d083 

in the new version the fix is as follows :

do
  {
    if(HAL_ETH_Transmit_IT(&EthHandle, &TxConfig) == HAL_OK)
    {
      errval = ERR_OK;
    }
    else
    {

      if(HAL_ETH_GetError(&EthHandle) & HAL_ETH_ERROR_BUSY)
      {
        /* Wait for descriptors to become available */
        osSemaphoreWait( TxPktSemaphore, ETHIF_TX_TIMEOUT);
        HAL_ETH_ReleaseTxPacket(&EthHandle);
        errval = ERR_BUF;
      }
      else
      {
        /* Other error */
        pbuf_free(p);
        errval =  ERR_IF;
      }
    }
  }while(errval == ERR_BUF);

the fix is related to LWIP application and not Ethernet and it is present in V1.17.2 and here are the changes:

• LwIP Applications
  • Use RCC_HSE_BYPASS value in SystemClock_Config() API for NUCLEO-F767ZI related projects, and adjust PLL parameters when needed, to comply to technical documentation.
  • Fix Wrong use of DHCP API in application code & ethernet_link_thread.
  • Fix Ethernet low_level_init() API to handle return code from LAN8742_init() and DP83848_init() APIs.
  • Fix mismatch in linker section names between linker file and source file.
  • Fix DeadLock in the transmit output.
  • Adjust iPerf bandwidth higher than 90Mbs.

Regards

[Petr3]

Hello STea,

i hope im using latest version of FW pack:

 but the lwIP code seems to be different:

where i can update lwIP for latest version? I thought it is part of FW pack for F7 family.

[STea]

Hello @Petr3 ,

you are right, the generated code with MX is generated with the old Ethernetif.c template I'm able to reproduce this and I reported it internally (ticket number 194996 internal reference only) for investigation
in the meanwhile, I suggest you make those changes to your code manually and you should be good to go.
Regards

[Petr3]

Hello @STea ,

thank you for your quick answer. I'll try to edit Ethernetif.c manually but for now im often regenerating the code, so i can work on another part of my FW. Do you know, how much time take the invetigation and release fixed FW pack?

Regards

[STea]

Hello @Petr3 ,

I'll get back to you as soon as i get a clear timeline for this.
Regards

[SURLEAU.Frederic]

Hi,

We have a problem with the new code when sending packets of more than 400 bytes .

The old version had no problem for us, I don't see the point of the new version...

A modification (of the new version) that work for us, is to move the call to "HAL_ETH_ReleaseTxPacket(&EthHandle);" in "HAL_ETH_TxCpltCallback( ETH_HandleTypeDef *handlerEth )"

With this modification, we never fall in HAL_ETH_ERROR_BUSY...

What do you think ?

Regards,

Fred.

[STea]

Hello @SURLEAU.Frederic 
can you open a new thread for better visibility.
Regards