Calling task blocks forever when I suspend another task inside of it

sarahaka wrote on Saturday, October 19, 2019:

I have 4 tasks that are periodically running each with their own period and handlers. Lets say inside task1, i would like to suspend task2 if it is not already suspended:

                //inside task1
				if (eTaskGetState(task2handle) != eSuspended ) { 
					vTaskSuspend(task2handle);
					printf("Beacon task suspended \n");
				}

eTaskGetState returns 1, coressponding to eReady (a task ready to run). However this causes task1 to block forever. I can’t see it running periodically anymore. Why is vTaskSuspend doing this?

richard_damon wrote on Saturday, October 19, 2019:

You are using different handles for the eTaskGetState and vTaskSuspend, could task2handle be 0, and thus mean suspend myself?

sarahaka wrote on Saturday, October 19, 2019:

Apolgies, I wanted to name the handler based on the question and forgot to change the other occurance. Indeed they are the same handler.
I also noticed that eTaskGetState returns 1 for tasks that have not been created yet.

richard_damon wrote on Saturday, October 19, 2019:

How can you have a handle for a task that hasn’t been created yet? The handle is the VALUE that the create returned, not the variable itself, so before you have stored the value of the create into the handle, it isn’t the handle for the task yet. (And if it is a global variable, it will have the value of 0, which generally means the current task).

sarahaka wrote on Saturday, October 19, 2019:

Task 2 does exsit. However I just mentioned an observation. Being a global varaible, GetState still returns 1 rather then 0 as you mentioned (technically GetState(NULL) == 1). Regardless, in the original question, all tasks have been created. All tasks exist. I am using FreeRTOS V7.5.3 if its useful.

richard_damon wrote on Saturday, October 19, 2019:

I think there may be a bit of an issue in terminology and communication. One big one is about using handles for tasks that havn’t been created yet, which is physically impossible, since the handle is the VALUE, not the variable (yes, you can use the variable you plan to store the handle into before creating it, but then it isn’t a handle to that task yet). The variable to store the handle in is not the handle and not the task.

First, FreeRTOS V7 is quite old, and the later versions check for a lot more conditions where errors in the applicaton might corrupt the system state, and state corruption can cause a lot of strange behavior. It might be useful to upgrade to the current version if possible.

sarahaka wrote on Saturday, October 19, 2019:

Yes, I understand. However I am using FreeRTOS with that is precompiled with an SDK I got. Unfortunalty I cannot update it.