I am trying to understand the result reported by eTaskGetState(). In my simplified case I have Task 1 querying the state of Task 2. Task 2 gets put in suspend mode when it is not needed, during which Task 1 is not allowed to do some "thing". But when Task 2 is not suspended, Task 1 'd better do this "thing" or it will go all haywire.

What I have noticed is that when I use eTaskGetState() to check Task 2 for !eSuspended and I know that Task 2 has been resumed, at times Task 2 still reports being suspended. It appears that when I think Task 2 may be blocked, it reports eSuspended instead. The code seems to bear this out, indicating something to the effect that if portMAX_DELAY is used as part of the blocking call, it puts the task into suspend mode--something that causes me to misinterpret its real state.

What's the reason for this? And what's a better way to identify if a task is suspended or not than using a variable in parallel with the suspend and resume calls?

FreeRTOS 7.4.2

Task 1:   while(1) {       ...       if (eTaskGetState(task2_tid) != eSuspended) {         <>       }       ...   }

Task 2:   while(1) {     ...     xSemaphoreTake(semid, portMAXDELAY);     ...   }

Other code:   ...   vTaskSuspend(task2tid);   ...   vTaskResume(task2tid);   ...

You are right. If INCLUDEvTaskSuspend is set to 1 in FreeRTOSConfig.h then a task using portMAXDELAY as a block period is placed in the suspended task list. A side effect is what you are observing. The task is not really suspended though.

I think this is documented somewhere, but I've just checked the eTaskGetState() documentation on the web and its not documented there. Maybe I read it in the book.