Stack at prvCheckTasksWaitingTermination()

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()

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()

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()

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()

Yes, i’m using ConfigASSERT() and i’m using heap_4.c with vApplicationMallocFailedHook() defined aswell.

Stack at prvCheckTasksWaitingTermination()

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?