HI, I have an issue with tasks that send messages out of a serial port stopping unexpectedly.

My setup is processor : SAM4N, Tools : Atmel Studio6.2, fitted with FreeRTOS viewer, RTOS : FreeRTOS 8.2.0

If I pause the program execution with the ICE, and look in FreeRTOS viewer I see tasks suspended that are never started or stopped with vTaskSuspend/VTaskResume. (as per latest FreeRTOS docs)

In fact I see this even if its running normally and I pause with the ICE.

Q1) Is the FreeRTOS viewer accurately reflecting the state of each task ? Q2) I have seen this before (FreeRTOS 7) when a task was blocked indefinitely showing as suspended But I thought that this was fixed in FreeRTOS 8. Tasks that show as blocked are tasks that have a timed delay that blocks the task for a certain period of time and not indefinitely. Tasks that are blocked, on queue or semaphore etc, with an indefinite delay show as suspended. Has this indeed been fixed in FreeRTOS 8 ?

I need to get a handle on the task status issue before I can progress . Any help gratefully accepted.

If I pause the program execution with the ICE, and look in FreeRTOS viewer I see tasks suspended that are never started or stopped with vTaskSuspend/VTaskResume. (as per latest FreeRTOS docs)

If you have INCLUDEvTaskSuspend set to 1 and block a task using portMAXDELAY as the timeout (which is generally a bad idea anyway as it does not allow for any error recovery) then the task will probably show in the debugger as being suspended. There is a little more work to do for the debugger to determine if a task is truly suspended, rather than just blocked indefinitely, but as far as I am aware there is only one such debugger plug in that actually does this.

Q1) Is the FreeRTOS viewer accurately reflecting the state of each task ?

I have no visibility into how the viewer is implemented, please ask whoever wrote it.

Q2) I have seen this before (FreeRTOS 7) when a task was blocked indefinitely showing as suspended But I thought that this was fixed in FreeRTOS 8

FreeRTOS functions that return the task's state now distinguish between tasks that are blocked indefinitely and tasks that are suspended, but you are using a third party debugger which is no doubt querying the data structures within the target's RAM and figuring this out for itself. It definitely won't be calling FreeRTOS functions to get the information - so in summary changes within FreeRTOS are not going to change how third party debuggers work.

Regards.