FreeRTOS_recv priority and tasks

friesen wrote on Thursday, May 23, 2019:

I have a situation where it would appear that recv is blocking lower priority tasks from running. The FREERTOS + TCP network tasks is priority 2, and the FreeRTOS_recv calling task is priority 2, and priority 1 tasks don’t seem to be getting called when network connectivity is poor and the recv timeout has not been reached. What types of situations could cause this scenario, and how might one fix this issue?

heinbali01 wrote on Thursday, May 23, 2019:

Erik, from experience, it is recommended to assign the following priorities in a FreeRTOS+TCP project:

  • Highest : the Network Interface driver (niEMAC_HANDLER_TASK_PRIORITY)
  • Medium : the IP-task (ipconfigIP_TASK_PRIORITY)
  • Lower : the tasks that make use of FreeRTOS+TCP

You are free to assign any priority to other tasks that are not using TCP/IP.

PS. the #define niEMAC_HANDLER_TASK_PRIORITY may not be used as such in all drivers. Please check your NetworkInterface.c, and look for xTaskCreate().

What time-out is being used when you call FreeRTOS_recv()?
This is the value of ipconfigSOCK_DEFAULT_RECEIVE_BLOCK_TIME, unless you set it specifically with the socket option FREERTOS_SO_RCVTIMEO.

Can you verify that the function does block for longer periods of time?

The IP-task blocks on a call to xQueueReceive().

Your priority 1 task will run as long as the high-priority tasks are in a blocked state.

But maybe your problem gets solved if you assign the recommended priorities.