“FreeRTOS plugin shows both tasks as suspended.”
Be careful how you interpret what the plug-in is telling you. The plug-in cannot tell the difference between a task that is actually suspended (in the Suspended state) and a task that is in the Blocked state with an infinite timeout. Therefore if you call a blocking function such as xQueueReceive() and give it a block time of portMAX_DELAY then, if INCLUDE_vTaskSuspend is set to 1 in FreeRTOSConfig.h (which it must be in your case), the plug-in will show the task as being in the Suspended state.
It is almost certain that the task is actually in the Blocked state, not the Suspended state.
Regards.
I'm not sure why you would be allocating a packet in one task for use by another task - but assume if I saw all your code rather than this snippet it would be more obvious. Also personally I would always try and avoid repeatedly allocating and freeing memory blocks in this way - although heap_4.c would normally make this ok.
There is no suspend with timeout function. For that you would need to use a delay, not a suspend, but then there is no way of another task 'undelaying' as per your unsuspending (resuming). You could probably make the functionality by having the task block on a semaphore with a delay - then the other task can "give" the semaphore to unblock the task if the delay has not expired.
Task suspend and resume are not features I use very often myself. They can be dangerous to use as a synchronisation method because if a task tries to a resume another task that has not yet got to the point of suspending itself then the resume has no effect (and is not latches, as it would be if a semaphore were used instead).
Regards.