FreeRTOS+TCP : Cannot Initialize

On STM32F4 I start the FreeRTOS+TCP demo application.
FreeRTOS is unable ti initialize correctly because it is unable to create the prvEMACHandlerTask.
I played a little bit with the stack size but I didn’t get any good result beide FreeRTOS unable to create it.

Direct result is that the DHCP task isn’t started correctly (because no Network interface) and so no functional network stack.
PS: I add to do some tweaks to integrate te example in STM32CubeIDE 1.3.0 (HAL is v1.25)

I don’t know which project you are using but I’m guessing it is this line that is failing: https://github.com/FreeRTOS/FreeRTOS/blob/master/FreeRTOS-Plus/Source/FreeRTOS-Plus-TCP/portable/NetworkInterface/STM32Fxx/NetworkInterface.c#L471 Is that right? It also sounds like you know why it is failing, and have already tried adjusting configEMAC_TASK_STACK_SIZE, is that right? Are you absolutely sure it is because there is not heap space to available to create this task? You can verify that by stepping through the function in the debugger to be 100% sure, or defining a malloc failed hook just to see if an allocation fails somewhere. If you are running out of heap space then you will either need to increase the heap size if you have enough RAM or otherwise reduce the amount of heap used by other tasks (which could be done by tuning the stack sizes allocated to other tasks).

Hello Richard,

The base project is the Demo application from FreeRTOS+TCP 2.0.3 demonstrating an HTTP server for the STM32Lxxx.

You indeed identified the correct line.

What is strange is that I didn’t change anything to the project an as I am running on a F429 with 256kB SRAM I didn’t expect such an issue.

Thanks for the advice

The only reason why xTaskCreate() can fail is when pvPortMalloc() fails.
It will be called two times: once to allocate a new TCB, and once to allocate a stack for the new task.

I recommend using head_4 or headP_5. The former declares a fixed amount of heap, determined at compile-time. The latter allows to allocate free memory ( in blocks ) at runtime.

Maybe you can test your self, before calling FreeRTOS_IPInit(), if pvPortMalloc() and vPortFree() work for you? Just allocate like 32 KB.

I got a lot further.
ARP & ICMP are working. Still need work for my HTTP test though.
Issue were :

  • FreeRTOS_printf calls crashing the STM32. Don’t know why.
  • PHY detection and configuration not done ==> packets dropped before being sent.

Still need to look at the DHCP issue too.

Hello, if you want, I will test your application and see what goes wrong. That is a lot quicker than asking questions over and again.

Please clean the project ( remove *.o *.lib *.elf etc ), zip it and attach it to your post with this button:

image

If the forum does not allow you to attach files, please inform us.

Hello Hein,

I am using heap_4 as recommended.

The xTaskCreate is working. (I did the test as suggested) Crash happens on a printf in the prvEMACHandlerTask. The FreeROS_printf with %ul in it causes a crash.

That sais, there are still a few issues:

· DHCP client seems to not work as my interface never receives an IP address. à Put a fixed IP address.

· ARP requests are processed correctly but the replay is never sent. It looks like FreeRTOS thinks that the cable is disconnected. (xPhyObject->ulLinkStatusMask == 0) I suspect a Phy issue

Crash happens on a printf in the prvEMACHandlerTask

Is that function calling printf()? Who is defining printf()? It is part of the standard C library, but it can also be overridden by your library. The kernel and FreeRTOS+TCP don’t use it ( with the exception of the WinSim project ).

The FreeROS_printf with %ul in it causes a crash.

That is strange. Only a bad pointer %s could cause an exception.
What do you mean with “crash”? Is that a hardware fault?

The first thing to check is the PHY initialisation. No communication is possible without a proper working Ethernet PHY.

I hope that you have some kind of logging and that you can follow the code in Common/phyHandling.c

  1. xPhyDiscover() should return 1. If successful, it will print the ID as e.g. “PHY ID 7C0F0”.

  2. The next step is xPhyConfigure(), in which the PHY is reset and will be configured.

  3. The last step is xPhyStartAutoNegotiation(), in which the auto-negotiation is started. If you board is connected t a switch or router, they will come to an agreement about the properties.

If the above steps do not work, it is useful to check the hardware initialisation of the GPIO ports, the peripheral clocks, etc