FreeRTOS-Plus-TCP on a STM32F7xx

Hello,

I’m trying to use FreeRTOS-Plus-TCP on a STM32F7xx, and so far I did not manage to get it work. I follow the FreeRTOS+TCP Networking Tutorial and get other information on the forum, without success.

So far, I do the follow:

  • I generate a working project with STM32CubeMX. It compile and work with no problem. I have a basic task making a Led blink every seconde
  • I add the FreeRTOS-Plus-TCP file, the compiler and specific interface files. I also removed the stm32f7xx_hal_eth.c/h generated by CUBE to use the ones from FreeRTOS-Plus-TCP
  • I defined the vApplicationIPNetworkEventHook function, and make another Led Blink when eNetworkup is detected

The project compile with no error, but when launching it:

  • The Led from my task blink
  • It stop blinking when I plug an Ethernet cable
  • The Led from the NetworkUp event never toggle

With the debuger, I saw that:

  • Before the cable is plugged, the EventHook function is called every 3 sec approx
  • After the cable is plugged, the micro keep executing the HAL_ETH_IRQHandler function. The only flag UP in the ETH_HandleTypedef is the flag ETH_DMA_FLAG_NIS, “Normal interrupt summary flag”
  • My task is never executed
  • EventHook function is not executed either

Any help would be appreciated.

  • Is it normal to have NIS interruption keep triggering?
  • Where to look to debug my problem?

Thank you
Antoine

Hi Antoine,

you didn’t specify what hardware (board) you use.

From what you describe, the first thing to look at would be the PHY/MII/RMII interface configuration to determine whether you software setup matches your hardware. We’ve had this issue here several times before, just query the forum for PHY or RMII.

Thanks RAc

Hello RAc,

I’m using the Nucleo-F767ZI demo board. I use the default configuration generated by STM32CubeMX to configure the interface. So the function used to configure the GPIO is the HAL_ETH_MspInit function.
The default configuration use the RMII interface. I will have a look on the forum.

Thank you
Antoine

RMII looks ok for that board.

Next thing to do would be to compile and try to run one of ST’s ready made example for that board to see if you’ve got a hardware problem or (if that sample runs) piece by piece compare the ETH register contents between the two code basis.

Good luck!

If it helps, here is an example of a Makefile project written for STM32F746.

Are you using the STM32Fx network interface?

Like @RAc, I would also first check the RMII and the PHY.
In my STMF7x sample project, the GPIO’s are initialised in this HAL_ETH_MspInit(). Make sure that you version is 100% correct.

If you can step through the code, I would have a look in the functions of phyHandling.c. See if it finds the PHY by reading its ID? See if the PHY gets initialised properly?

@RAc
Yes I will have a look to compile and try a ready to use example from ST. As I am working on one of their demo board, I was assuming that hardware is correct. But having a check is a good idea.

EDIT: just compile and test one of the demo application for my board. It is working. I am able to connect to it and display an embedded page from it with my browser. So hardware is ok. I will have a look to see the configuration used in this project.

@htibosch
Yes I am using the STM32Fx network interface. I removed the stm32fxx_hal_eth.* file generated by Cube, and I put the file from FreeRTOS-Plus-TCP

The HAL_ETH_MspInit() function is called. It the one generated by Cube. Pin configuration correspond to the definition of the Nucleo User Manual. I have 2 differences with your function:

  • I have no RMII_MII_RXER gpio
  • NVIC priority is set to 5 in my file

phyHandling functions seems ok:

  • xPhyDiscover return 1
  • in xPysConfigure, pxPhyObject->ilPhyIDs ix 0x7C130, corresponding to LAN8742A as expected
  • the calls to pxPhyObject–>fnPhyWrite and fnPhyRead return HAL_OK

Thank you all

Hello,
Checking the value of the register was the solution. It point me that, in fact, the file Networkinterface.c was using an ETH_HandleTypeDef xETH while the eth.c file generated by Cube was using ETH_HandleTypeDef heth.

Changing ETH_HandleTypeDef xETH to extern ETH_HandleTypeDef heth do the job.
I am now able to ping the board.

Thank you
Antoine