Resuming after vTaskSuspend(NULL);

andy-pevy wrote on Tuesday, January 05, 2016:

Hi,

  I have a number of tasks and I am trying to synchronise one of them with another.

I am using the ST Cube tool to create the base code, and it starts all the tasks at boot time.

I therefore, within the first task issue a vTaskSuspend(TIMER_TaskHandle); call. I was hoping that this would allow the second task to complete initializing some hardware (that takes a variable amount of time).

I then, from the second task issue a vTaskResume(TIMER_TaskHandle);

But, the first task does not continue after the suspend line.

Code fragment :-

Timer task:

TIMER_Task_Suspended = TRUE;
vTaskSuspend(TIMER_TaskHandle);		// Stop here until allowed to resume...
TIMER_Task_Suspended = FALSE;   <- Never reached :(.....

Supervisor task :

if(MODE_DC == my_mode)    <- This is true...
{
	vTaskResume(TIMER_TaskHandle);	// Re start the timer task.
}

So, Firstly, is what I am doing correct and allowed, and secondly, if it is, why does it not appar to work ?.

Thanks,
Andy Pevy

rtel wrote on Tuesday, January 05, 2016:

Are you sure the value in TIMER_TaskHandle is correct?

If so, then is the second task (the one that is calling vTaskResume()) higher, lower or equal priority to the first task? If it is higher priority then the first task will only execute when the higher priority task enters the Blocked state. It will enter the Blocked state if it makes a blocking FreeRTOS API call, such as vTaskDelay(), or xQueueReceive() on an empty queue with a block time specified.

Regards.

andy-pevy wrote on Tuesday, January 05, 2016:

Hi, The value in Timer_TaskHandle is correct, and both tasks are running at the same priority.

The unblocking task enters “retval = xQueueReceive(Supervisor_task_queueHandle, (Transfer_Type *) &supervisor_inds, slot_time.sleep_time);” a few lines later so it should allow the timer task to run.

andy-pevy wrote on Tuesday, January 05, 2016:

Would adding a vTaskDelay or taskYIELD be a way of releasingf the timer task ?.

rtel wrote on Tuesday, January 05, 2016:

That shouldn’t be necessary.

Another thought - if the tasks are the same priority - are you 100% sure the task is suspended before you try un-suspending it?

For example, if:

  1. the first task set TIMER_Task_Suspended to true, then got swapped out before it called vTaskSuspend(),
  2. Then the second task executed, did its thing, and called vTaskResume(),
  3. Then the first task executed again and called vTaskSuspend()

you would end up with the behaviour your have observed.

Try creating the first task with a priority above that of the second task, so you know there is no chance of the second task executing until the first task has actually entered the Suspended state. Then when the first task leaves the Suspended state it can call vTaskPrioritySet( NULL, [whatever] ); to set its priority back down to the one you really want it to run at.

Alternatively, if the task is created before the scheduler has started, you can also suspend it before the scheduler starts, that way it will already be in the suspended state before any tasks run. vTaskSuspend() is one of the functions that it is ok to call before starting the scheduler.

Regards.

rtel wrote on Tuesday, January 05, 2016:

By the way, you can use eTaskGetState() to determine the state of a task.

andy-pevy wrote on Wednesday, January 06, 2016:

Bingo, looking at the relative timings, I think that this is a distinct possibility.

I will re-work the control logic to ensure that the timings are correct.

Thanks for your help.

Andy