FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [May 2015 Threads]
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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.