Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

TCP/IP: FreeRTOS_send drops packets

Posted by peku33 on August 10, 2016

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.

Some facts: STM32F107 + ENC28J60 100Hz Ticks TCP Windowing off 1 * mss tx & rx buffers 4 tx, 8 rx descriptors

Best regards, Pawel Kubrak


TCP/IP: FreeRTOS_send drops packets

Posted by rtel on August 11, 2016

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:

1) 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?

2) 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/FreeRTOSPlusTCP/TCPIPConfiguration.html#ipconfigNUMNETWORKBUFFER_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.


TCP/IP: FreeRTOS_send drops packets

Posted by heinbali01 on August 11, 2016

The problem is the clock rate: only a 1,000 Hz and higher will work properly with the current release. This will be repaired in the next release.

For now you can replace 4 or 5 occurrences of pdMS_TO_TICKS() in FreeRTOS_TCP_IP.c with pdMS_TO_MIN_TICKS(), which is defined as:

~~~~

define pdMSTOMINTICKS( xTimeInMs ) ( pdMSTOTICKS( ( xTimeInMs ) ) < ( ( TickTypet ) 1 ) ? ( ( TickTypet ) 1 ) : pdMSTO_TICKS( ( xTimeInMs ) ) )

~~~~

With 100 Hz, small time-out values were rounded down to zero ticks. The above macro returns 1 or more. A time-out value of 1 is OK.

Sorry for the inconvenience :-)


TCP/IP: FreeRTOS_send drops packets

Posted by kerub on September 5, 2016

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.

Regards

Andrzej


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS