I observed a strange behavior with TCP connection.
In my solution I use TCP sockets for simple client-server command-response protocol. The messages are pretty short (up to 256 bytes) and are sent once every second. At the beginning of application sockets are created and are kept open for transmission. Client (the PC) sends message every one second and FreeRTOS device sends response.
However, once every 10-70 transactions the message is not sent. What is really interesting, the FreeRTOS_send is called successfuly (and returns true), but this packet is not outputed to xNetworkInterfaceOutput. What is even more interesting is that this message is being sent later, if any other communication occurs on this socket. But without poke from other side of the socket packet is delayed forever.
I also did some wireshark analysis. The transmission looks ok. Each packet from PC has ACK from FreeRTOS. If FreeRTOS decides to push my packet out - transmission to PC is also successful - ACK is sent back.
So the packet is sometimes delayed somewhere in the middle between FreeRTOS_send and xNetworkInterfaceOutput.
I also observed that after increasing priority of ip task, this is much less likely to happen (once every thousands).
This is not related to memory exhaustion (memory hwm never passes 30%) but could be caused by timing and scheduling. I also tested with no application logic (just pure os + ip stack), but results are the same.
This is indeed strange, and it is not something I am aware of anybody
reporting before.
Two things come to mind that could potentially be an issue here,
although to be honest it would be unlikely:
The relative priorities of the tasks using the TCP stack. There is a
known issue with the FreeRTOS_accept() function if the priority of the
task running the TCP/IP stack is lower than the priority of the task
using the TCP/IP stack. It is unlikely this is the case here though -
however as you mention raising the priority of the IP task improves the
situation maybe it could be related. Do you have the priority of the IP
task above the priority of any other task that is using the stack?
Perhaps you are running out of buffers, or buffer descriptors.
Although internally in the stack you should be protected from that
causing an issue, perhaps this could be an issue in your application
code? When you say it is not a memory exhaustion problem, have you also
checked you are not running out of buffer descriptors - the number of
which is fixed at compile time? See http://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/TCP_IP_Configuration.html#ipconfigNUM_NETWORK_BUFFER_DESCRIPTORS
Also, are you using an infinite timeout anywhere when using the TCP
stack? It is best to use a finite time out in case an operation cannot
complete.
Perhaps Hein will be able to provide more insight.
It can be also an issue of ENC28J60, if you use automatic pading in the PHY.
You have to remember to set correct the conrtol bits (the first byte) for each frame in transmit buffer of ENC28J60.
Once I forgotten and the ENC28J60 didn’t sent some time to time frames smaller than 60 Bytes because of random values of the bits in the buffer.
