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 'FreeRTOSTCPIP.c' :

    s/pdMS_TO_TICKS/pdMS_TO_MIN_TICKS/g

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.

Regards.

Perhaps this issue is similar to what I just commented on in discussing pdMSTOTICKS. Many applications really want to specify a true minimum delay, pdMSTOTICKS 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.

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.