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