+TCP issue when configTICK_RATE_HZ is not equal to 1000 Hz

heinbali01 wrote on Friday, February 26, 2016:

Hello list,

Thanks to one of the users of FreeRTOS+TCP, Tamas Selmeci, we discovered an issue: a TCP connection may die as soon as a transmitted packet gets dropped (never arrives).

This can only happen when configTICK_RATE_HZ is defined as less than 1000 Hz.

Proposed change for now:

    Within 'FreeRTOS_TCP_IP.c' :


    In 'FreeRTOS_IP.h' please add this macro :

        #define pdMS_TO_MIN_TICKS( xTimeInMs )\
            ( pdMS_TO_TICKS( ( xTimeInMs ) ) < 1 ? 1 : pdMS_TO_TICKS( ( xTimeInMs ) ) )

The problem occurs when pdMS_TO_TICKS() returns zero. When pxSocket->u.xTcp.usTimeout becomes zero it means: this socket does not need attention from the IP-task. As a result, the connection would die.

Changing subject:

FreeRTOS+TCP will soon support multiple interfaces and IP-addresses!
If anyone would like to pioneer and help us with testing, pleas write to us directly ( e.g. to h.tibosch located at freertos.org ). We’d love to get feedback from you before releasing the new source code.


richard_damon wrote on Friday, February 26, 2016:

Perhaps this issue is similar to what I just commented on in discussing pdMS_TO_TICKS. Many applications really want to specify a true minimum delay, pdMS_TO_TICKS does not do this. You likely want the calculation to round up not down in computing the number of ticks (so if a floating point calc of the delay was .1 ticks, you would delay a tick) and likely also add 1 to the number to tick to account for the tick interrupt possibly happening immediately after the call.

Note that a timeout of 1 tick has a chance of being 0 time. The smallest time that makes sure that some real time passes is 2 ticks.

heinbali01 wrote on Friday, February 26, 2016:

Only that in this case a minimum of 1 clock tick would be OK. Even if this results in a sleep of less than 1 uS.