FreeRTOS_send seems successful but no data on wire


I am running FreeRTOS+TCP on the STM32F746 discovery kit. The initialization and configuration seems ok since I can ping the discovery kit successfully. Then, I created a task that bind and listen to a port:

  • I am able to accept connection from a tcp client.
  • I am able to receive data from the connected tcp client.
  • I am NOT able to send data to the same client.

When trying to send 5 bytes using FreeRTOS_send, the function will return 5 meaning that all 5 bytes have sent but the client does not receive the data. I also do NOT see data sent from my device on the network using Wireshark.

I traced FreeRTOS_send() with breakpoints and I can see my data being added to the tcp socket stream using the function uxStreamBufferAdd().

Also, after a while of trying to send those 5 bytes, FreeRTOS_send() will return -28 (which is “No space left on device”.

So it appears to me that FreeRTOS_send() is doing its job correctly by adding data to the tx stream of the socket … but the tx stream is never emptied so data is never sent on the wire.

(reminder: I can ping my device successfully so it means I can receive and send correctly.)

What am I missing? Ideas?


can we see a wireshark trace? Your description is unclear. Note that especially with TCP, there is “behind the curtain” traffic on the wire aeemingly unrelated to the user data (eg ack frames). As soon as a TCP connection is established, there must have been bidirectional valid traffic, so the lower layers must be functional. How can you tell that something fails or succeeds?

Hello Philippe,

@RAc wrote:

can we see a wireshark trace?

I just asked permission for you to attach files in this forum. You will have to ZIP it before sending. Drag and drop works.

And maybe you can also attach your FreeRTOSIPConfig.h?

Should be able to attach a zip file now.

Hi guys,

I am attaching my FreeRTOSIPConfig.h and a capture from Wireshark.

My device is
I am using port 10000.

Here is the sequence seen in the capture:
1- The capture is showing “ping” frames at the beginning.
2- The capture he showing my client (running on my laptop) opening port 10000 which my device is listening to.
3- Once, the port is opened, the device is trying to send data, using FreeRTOS_send() but no data is sent.
4- After a while, the client timeout and close the socket.

Thanks for your help,
Philippe (7.2 KB)

Can you do the following:

  1. Add the following breakpoints:
  2. Verify that the data you send using FreeRTOS_send reaches xNetworkInterfaceOutput function.
  3. Verify that the control reaches here and we start the DMA transaction.
  4. Verify that HAL_ETH_TxCpltCallback gets called.
  5. Verify that the task notification from HAL_ETH_TxCpltCallback calls vClearTXBuffers here.
  6. See how many descriptors were given to DMA and how many were transmitted successfully: FreeRTOS-Plus-TCP/NetworkInterface.c at main · FreeRTOS/FreeRTOS-Plus-TCP · GitHub


The PHY seems to be good, ping works. TCP shows a strange value, the sequence number in packet 17 is “negative”, 0xffffffff.

It seems like packet 16 has not been seen by x.x.x.138

Are you using the latest release of FreeRTOS, I assume?

Are you using a good randomise function (xApplicationGetRandomNumber()) that always starts with a random number after a reboot?

Thanks Gaurav !

I did trace all functions you have mentioned and they were all called.

I did dig in DMA descriptors and how memory is handled in tcp sockets. I activated the vApplicationMallocFailedHook() and boom … found out I had memory issues. I decreased the allocated Rx and Tx memory allocated by my socket using the FREERTOS_SO_RCVBUF and FREERTOS_SO_SNDBUF option and FreeRTOS_setsockopt(). This has fixed the mem allocation issue … and now I can transmit and receive with my device.

Thanks again.

My xApplicationGetRandomNumber() was not random at all. I activated the RNG module (HAL_RNG_MODULE_ENABLED) from the STM32Fxxx HAL, and created a better random function. That change alone did not fix my issue since I had memory allocation issue as mentioned in my previous post. Thanks Hein for your help.