FreeRTOS+TCP howt to suspend IP task

I’m using FreeRTOS+TCP to have my embedded device communicate via UDP (I had to write a driver for my enc28j60 ethernet ic). It does DHCP and more or less works as I want it, but I could not find a way to deactivate the IP stack while I am not using it.

My device only needs network during short intervals, when sending gathered information upstream. Also, I need the SPI I use for ethernet for a different connection while I am not using ethernet. I can, of course, just let it running while I deactivate my ethernet, so that it just fails to communicate via ethernet, but I would rather not have a task running in background that interferes with the tasks I am actually needing to run.

So: is there anyway to put it to sleep? The API does not provide anything I could find. I would gladly completely de-init it and re-init it when I need it again (letting it do DHCP over again and all), but I read that you cannot do that and only use init once.

Hi Kratenko, why would you want to deactivate the IP stack? Low-power issues? CPU performance?

In FreeRTOS_IP.c you find the following declaration:

/** @brief The maximum time the IP task is allowed to remain in the
 * Blocked state if no events are posted to the network event queue. */
#ifndef ipconfigMAX_IP_TASK_SLEEP_TIME
    #define ipconfigMAX_IP_TASK_SLEEP_TIME  ( pdMS_TO_TICKS( 10000UL ) )

By default, the IP-task will wake-up every 10 seconds, just to do some checks, mostly for TCP. I recommend to define ipconfigMAX_IP_TASK_SLEEP_TIME in your FreeRTOSIPConfig.h as e.g. :

#define ipconfigMAX_IP_TASK_SLEEP_TIME pdMS_TO_TICKS( 300000UL )

In that case the IP-task will sleep in periods of 5 minutes.

There was recently a PR #222, which adds a function which returns the task handle of the IP-task.
I recommend not to use it. You could indeed suspend the IP-task, but the side effects might be undesirable: I think of a possible overflow of the work queue, exhaustion of the network buffers, strange side effects on timing.

Does your enc28j60 driver also have a task?

PS. I once adapted ipconfigMAX_IP_TASK_SLEEP_TIME for a low-power application, I put it on 1 minute: it all worked fine, the CPU had sleeps of at most 60 seconds, and the batteries lasted very long.

Hi Hein,
I guess I just like to have control over my device. Having a high priority task running, while I do timing sensitive work in a different task, does not feel right. Especially when there is nothing that task can really do, as no IP packets while go neither in nor out, while I have ethernet deactivated. I can work around that (mutex, critical sections, etc), but in some places I would prefer not having to do that. With my current project it is not that much of a problem.

The enc28j60 driver only has an interrupt dispatch task for the IP-stack. Right now I am disabling all enc-Interrupts and ignoring all calls by the IP-stack, while I turn off ethernet.

I guess I can live with the way it is, but I find it hard to believe that I am the only one finding this awkward. It takes away my full control over the cpu. This isn’t really an issue about performance but more about timing and predictive behavior, which to my understanding are important aspects when working with embedded systems.

Thank you, for your insights.

The definition ipconfigIP_TASK_PRIORITY can be set pretty low and keep the IP operational. The IP task generally sleeps waiting for events from the ethernet controller. It will also wakeup to keep any IP activities alive (expire the ARP Cache, check the age of DHCP, etc…) These activities should take very little time and are not time critical.

I would recommend you simply set the IP task priority very low and leave it alone.

One thing to consider, the enc28J60 gets a little touchy if the RX buffer overflows so if you disable the 28J60 interrupts to eliminate waking up the IP stack, you need to be prepared to flush the RX buffer and reset the device.

Joseph is right, you can also play with the task priorities.

About priorities: it is preferred to assign the following priorities:

  • higher : the network interface
  • medium : the IP-task
  • lower : tasks that make user of FreeRTOS+TCP

All other tasks are entirely free to choose their own priorities.

Joseph also mentions more activities that will be suspended, like ARP cache cleaning and DHCP renewal. I also recognise the problems that arise when the network device gets overflow errors because the packets are not handled by the IP-task.

But feel free to suspend the IP-task and see if it all works well again when you restart the network.

It is just that I had to warn you for the possible consequences :smiley:

Another thing to consider is that network management software may send periodic ICMP (ping) requests or other packets to your device to check for liveness and raise an alert if your device doesn’t respond. Also, there are retransmission and connection timeout timers at work that probably gp through the message pump as well. You don’t really want to risk starving those events, they may cause you weeks of debugging.

It is extremly unusual for a network device to completly cease networking activity.