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] [October 2015 Threads] Stack at prvCheckTasksWaitingTermination()Posted by chaabanemalki on October 14, 2015 Hello,
I'm using FreeRTOS V8.0.0 with pic32MX.
When trying to delete few tasks. att some point the kernel gets stuck at prvCheckTasksWaitingTermination (), in the while loop
while( uxTasksDeleted > ( UBaseType_t ) 0U )
{
}
The variable xListIsEmpty keeps having 1 and apprently the kernel can't delete a task.
my code is like the following
vTaskDelete(task1);
vTaskDelete(task2);
vTaskDelete(task3);
.
.
vTaskDelete(taskn);
Now i'm not sure in which task this problem is hapenning and this doesn't happen all the time so it's hard to catch it.
Any idea on what might be wronge in my code ? and how i track it when it happens ?
Thank you
Stack at prvCheckTasksWaitingTermination()Posted by heinbali01 on October 14, 2015 Hi Hicham
The following looks sounds like an easy victim for an optimising compiler:
~~~~~
while( uxTasksDeleted > ( UBaseType_t ) 0U )
{
}
~~~~~
What if you replace it with the following:
~~~~~
while( *( ( volatile UBaseType_t * ) &uxTasksDeleted ) > 0U )
{
}
~~~~~
Just to make sure that 'uxTasksDeleted ' will be fetched again and again?
There is a second problem with such a loop: if the task performing the loop has the highest priority, no other task will be able to change te value of 'uxTasksDeleted '.
Best regards.
Stack at prvCheckTasksWaitingTermination()Posted by rtel on October 14, 2015 This loop is actually FreeRTOS code, and the uxTasksDeleted variable is declared volatile, so should be fine. I'm pretty sure the 'comprehensive' build of the standard demo for this part continuously creates and deletes tasks, so the code is well exercised.
Do you have configASSERT() defined in your application? Also, which heap memory manager are you using?
Stack at prvCheckTasksWaitingTermination()Posted by heinbali01 on October 15, 2015
This loop is actually FreeRTOS code, and the
uxTasksDeleted variable is declared volatile
I'm sorry, I should have dug a little deeper and find out (grep) where the code comes from :-)
Stack at prvCheckTasksWaitingTermination()Posted by chaabanemalki on October 15, 2015 Yes, i'm using ConfigASSERT() and i'm using heap_4.c with vApplicationMallocFailedHook() defined aswell.
Stack at prvCheckTasksWaitingTermination()Posted by rtel on October 15, 2015 Hmm. Not sure, is it possible the idle task is getting starved of processing time? (probably not, if the code you posted is running when you stop the debugger, as that is in the idle task).
I was thinking perhaps there was a corruption in the memory you were trying to free, but having configASSERT() defined is the best that can be done to detect that (I presume your assert function will halt execution, so you know if it gets called).
Other than that it could just be an old fashioned memory corruption somewhere. Can you stop the debugger when this issue occurs and step into through the code to see what it is doing - and why the task's memory doesn't get freed?
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|