FreeRTOS TCP/IP Stack. Stuck in HAL_ETH_ReadPHYRegister (Nucleo-F767z1)

I’m trying to get the FreeRTOS TCP/IP stack running on the Nucleo-F767Zi to communicate directly with my PC using an Ethernet cable. I’m trying to establish a TCP connection, where the Nucleo-F767Zi is the server.
For the start I have created a FreeRTOS project in the CubeIDE, where I configured FreeRTOS and the Ethernet interface. (The ethernet interface is set to RMII and otherwise the default values were used.) After I followed the FreeRTOS+TCP Networking Tutorial and fixed the smaller bugs like the missing xApplicationGetRandomNumber function, I was able to compile without errors. When I started debugging the disillusionment came, that I got stuck in the function HAL_ETH_ReadPHYRegister. More precisely in the following section:

		/* Check for the busy flag */
		while( 1 )
			tmpreg = heth->instance->MACMIIAR;

			if( ( tmpreg & ETH_MACMIIAR_MB ) == 0uL )
				/* Get MACMIIDR value */
				*RegValue = ( uint32_t ) heth->Instance->MACMIIDR;
				xResult = HAL_OK;
			/* Check for the timeout */
			if( ( HAL_GetTick( ) - tickstart ) > PHY_READ_TO )
				xResult = HAL_TIMEOUT;

I replaced the driver stm32f7xx_hal_eth.c and the header stm32f7xx_hal_eth.h created by the CubeIDE with the driver stm32fxx_hal_eth.c and the header stm32f7xx_hal_eth.h and header stm32fxx_hal_eth.h from FreeRTOS.
Can anyone help me with this problem or does anyone have a working FreeRTOS TCP/IP program for the Nucleo-F767Zi?

PS. Is it a problem if I use TCP Plus 10.3 with the FreeRTOS 9.0 from the CubeIDE?

[edited for code formatting]

There should not be a problem using using the latest TCP stack with version 9 of the kernel.

The code you posted contains a timeout:

so I assume you get stuck because it never timers out? That could happen if HAL_GetTick() was not working. HAL_GetTick() (which is an ST function, not a FreeRTOS function) relies on a periodic tick interrupt - can you confirm that tick interrupt is executing? You could do that by determining which clock it is using and placing a break point in the clock’s interrupt handler, or just viewing the tick counter in the debugger (you can find the variable used to hold the tick count value by looking at the implementation of HAL_GetTick()).

At what point in the code is this function being called? If it is called in main() after FreeRTOS API functions have been called then you may find the interrupt used for the HAL tick count is masked, so not running. That could be fixed by initialising the PHY before calling any FreeRTOS API functions, or by initialising the PHY from an RTOS task after the RTOS scheduler has been started.

Ideally the PHY would not time out and just work, but that is not the immediate problem.

Thanks for the quick answer.
I have looked it up and my HAL_GetTick() works. The problem is, when the timeout is reached the function starts again. So I stay with this function until this condition is met:
if( ( tmpreg & ETH_MACMIIAR_MB ) == 0uL )

The function is called by MX_ETH_Init();. This is executed in the main before all FreeRTOS API functions.

Normally, the IP-task will be the first task to poll the PHY. It will call xNetworkInterfaceInitialise(), which in turn will call the function HAL_ETH_Init().

That function will call HAL_ETH_MspInit() which is provided by the user. It must set all PGIO’s involved and select their proper peripheral functions.

HAL_ETH_Init() will als call vMACBProbePhy(), defined in NetworkInterface.c.

I am not sure what the function is of MX_ETH_Init(), but I can’t find it in any of my STMF32 sources. I think it will work when you skip MX_ETH_Init().

Many thanks for the answer. Unfortunately I will not be able to try it today. I will try it tomorrow morning.

Thank you very much. It works. It was due to the MX_ETH_Init(). This was added by CubeMX. I commented it out and now I can connect.