In order to access the QSPI flash, I suspend the Touchgfx task from another thread.
The other thread has highest priority. Today the function hang somewhere, maybe at this place:
(void) osThreadSuspend( Task_TouchGFXHandle );
while ( osThreadIsSuspended(Task_TouchGFXHandle) != osOK)
My question: Is it guaranteed that osThreadIsSuspended delivers osOK once after osThreadSuspend and thus no endless loop can occur? Otherwise I would build in a counter and reset in case of a hang.
You discard the result returned by osThreadSuspend. The documentation ^^ says that the thread can be in a state when suspend is not allowed. In this case osErrorResource is returned.
The source code of the suspend function is:
osStatus osThreadSuspend (osThreadId thread_id)
#if (INCLUDE_vTaskSuspend == 1)
So it delivers always the same value osOK and therefore I ignore the return value.
> So it delivers always the same value osOK and therefore I ignore the return value.
It is only one version of implementation, it can change later or if the underlying RTOS changes. When writing code against CMSIS_RTOS contract (as documented) we cannot rely on specific implementation. If you use only FreeRTOS (which makes perfect sense), just use FreeRTOS functions (vTaskSuspend) and refer to documentation. From the docum and example, vTaskSuspend seems to act immediately and cannot fail so there is no need to loop and check the task state.
If I look into the sourcecode of the underlying rtos functions it is not so straight forward to see if there could occur any endless looping, as there are operations with lists. An endless loop would occur, if the task never becomes suspended. Maybe it could happen if interrupts of other tasks are occuring, like for communication errors?
Nevertheless, I have modified my source code in order to make a reset if it hangs.
Yes this does not look impossible. My RTOS experience is very limited, thus instead on using the CMSIS RTOS abstraction over something unknown, I would just write FreeRTOS based code, that relies on known behavior of FreeRTOS. The rule of thumb is not to write code paths which you won't be able to test.