TCP Echo Server problem

In hardware setting a client is my PC on which
I’m running echotool and server is XCore407I dev. board, based on STM32F407 MCU, where FreeRTOS+TCP V2.3.2 is installed in STM32Cube IDE. The client and sever are connected directly by ethernet cable.

In order to run echo server I added to …/NetworkInterface/STM32Fxx directory SimpleTCPEchoServer.c file from FreeRTOS_Plus_TCP_Minimal_Windows_Simulator\DemoTasks
For memory management heap_4.c is used.

When running echotool I’m getting fail massage shown on the screenshot
below.

The Wireshark message below shows communication process when echotool is running . As I read it, the connection between Client and Server was established, but for unknown reason when Client is requesting data from sever, server resets connection and communication stops.

Additional info:
Pinging is working fine.
In debugging mode found, that prvServerConnectionInstance() task was never executed,
although Task Create function:
xTaskCreate( prvServerConnectionInstance, “EchoServer”, usUsedStackSize, ( void * ) xConnectedSocket, tskIDLE_PRIORITY + 1, NULL );
was reached.

Can you please check you are able to communicate successfully with the echo server just from the command line, rather than your FreeRTOS app. That will check it is not a firewall or anti malware program that is breaking the connection - although in both of those cases I would expect the connection not to be made in the first place. Please also upload the wireshark log so we can see the data on the wire. Thanks.

Yes, as a client my PC was successfully connected with the echo server sending commands from the command line. Was trying to upload Wireshark captured file, but it is not authorized to upload because of file extension unfortunately.

If the forum refuses a file type, you can always ZIP it before sending it.
These types are allowed: jpg, jpeg, png, gif, zip, gz, tar, c, h, cpp, 7z.

What I see in your PCAP: when the first echo data come in, the +TCP library responds with a RST. That is unusual and I think that it has encountered a problem, like a pvPortMalloc() that has failed or some other lack of resources?

It may be helpful when logging is enabled, see ipconfigHAS_PRINTF and ipconfigHAS_DEBUG_PRINTF in your FreeRTOSIPConfig.h.

From where did you get the “echotool”?

Update:

you wrote:

prvServerConnectionInstance() task was never executed, although Task Create function: xTaskCreate(...) was reached.

Then it looks like xTaskCreate() has failed, which is most probably because a prvPortMalloc() failed? What is the size of your heap?

Wireshark zip file is attached.Wireshark_echo_server.7z (658 Bytes)

In the FreeRTOSConfig.h configTOTAL_HEAP_SIZE defined as 15360

I got echotool from the GitHub, which was linked from > UDP Echo Client Example

I agree that somewhere heap memory is leaking and that’s why cannot create

prvServerConnectionInstance task.

Somehow my FreeRTOSConfig.h doesn’t include both ipconfigHAS_PRINTF and
ipconfigHAS_DEBUG_PRINTF definitions.

Today by elevating

prvServoConnectionInstance

task priority from 1 to 7 and decreasing

usUsedStackSize

from 520 to 256 was able to run

prvServoConnectionInstance

task.
Now (as I can see in debugging mode) this task continuously trying to read incoming data into pucRxBuffer but still is not getting data. Don’t know why.
As result Server doesn’t send RST command back to the Client (PC) anymore and the Client because isn’t getting data just is timing out.
Heap memory leakage (as I understand) was result of prvServoConnectionInstance task priority (1) was lower than prvEMACHandlerTask (6) and RTOS scheduler was running task with higher priority which lead to draining heap memory.
I tested it in debugging mode.

I do not see a direct relation between task priorities and running out of heap. Unless some higher-priority task is eating up all CPU time.

Can you try to give the maximum possible to the heap ( using configTOTAL_HEAP_SIZE? ) and also define a malloc hook function.

And about the priorities, the following scheme is recommended for FreeRTOS+TCP applications:

higher ; network interface task ( niEMAC_HANDLER_TASK_PRIORITY )
normal : the IP-task ( ipconfigIP_TASK_PRIORITY )
Lower : all tasks that are using the IP-stack

All other tasks are free to choose their priority.

PS. And maybe you can send a new PCAP file, if you have one?

In the FreeRTOSConfig.h configTOTAL_HEAP_SIZE is defined as 15360 and

in the FreeRTOS.h configUSE_MALLOC_FAILED_HOOK is defined as 0
Probably need to define it as 1.

Priorities are as following:
In NetworkInterface.c niEMAC_HANDLER_TASK_PRIORITY defined as: configMAX_PRIORITIES - 1 (7 - 1), because in FreeRTOSIPConfig.h default configMAX_PRIORITIES number was 7

In FreeRTOSIPConfig.h ipconfigIP_TASK_PRIORITY defined as just number 14
Now I can see that it is wrong.
What is your recommendation for niEMAC_HANDLER_TASK_PRIORITY and
ipconfigIP_TASK_PRIORITY values?

I don’t have PCAP file.

After reading discussions regarding use of FreeRTOS_debug_printf() and FreeRTOS_printf() macros located in FreeRTOSIPConfig.h for login file I still not sure how to make it working for logging debug info. Can you elaborate on this or give some links/examples. Thanks.

15360 byte heap is pretty small. I guess too small. If decreasing the stack size of a task helps to run the application it’s a clear sign that you’re lacking heap memory. Provided you’re using the normal i.e. non-Static version of xTaskCreate, which uses the heap to allocate the stack and other task resources.
You really should define/use the debugging features/macros like configUSE_MALLOC_FAILED_HOOK for development. Trial and error might get tedious :wink:

Thanks for useful recommendation. Will try to increase the heap size and configUSE_MALLOC_FAILED_HOOK to set to 1. What is average recommended heap size
for FreeRTOS + TCP ?

Depending on the heap implementation you are using you may also be able to call xPortGetFreeHeapSize(), xPortGetMinimumEverFreeHeapSize() and vPortGetHeapStats().

Where can I find definitions of the following API functions as:
vApplicationMallocFailedHook()
vPortGetHeapStats()

See Hein’s last post in this thread.

See my last post in this thread.

Sorry for my lack of understanding, but in the Hein’s link I can see only function prototype
of vApplicationMallocFailedHook() and in your link prototype of vPortGetHeapStats() function.

Sorry - I thought you were looking for the prototypes.

You can define vApplicationMallocFailedHook() to do anything you want. If you search for implementations of that function in the FreeRTOS download you will probably only find implementations that assert, and so stop the program, but heap exhaustion should be dealt with gracefully in real applications so you may just want it to print out a warning or hit a breakpoint.

You will find vPortGetHeapStats() used in several places in this project: https://github.com/FreeRTOS/FreeRTOS/tree/master/FreeRTOS/Demo/WIN32-MingW

Thanks, now I got it.