Because i want to run  multiple threats that oversize the heap, i want to kill an application if not needed. I tried a two simple tasks; one that flashes the LED’s continuously on the PIC32 Explorer16 board. This is the task that should be killed and created. Then i created another task, with the same  priority, that gives me information on the Explorer16 display. Also in this display task there is a simple counter that every time it reaches 3 it will kill or start the LED task. This display task has a task delay of 1000mS, so every 3 sec. the LED application should be started or killed. It seems that the function vTaskDelete somehow ends up in a endless loop. I noticed this because when I call it from the display task, the display task will freeze permanently after 21 sec. running time. Till 21 sec. it does it job; every 3 sec. it will kill or start the LED task. To prevent the display task from freezing (because then i cannot see any variables or use full info anymore on the display), i created a function that only gives the LED task a "true" variable so when the LED task gets executed it will read the "true" variable and thus killing itself. There are no other things running. The tasks above are the only ones. Below is the code of the LED task: -—————————————— /* Standard includes. */ #include <stdio.h> /* Scheduler includes. */ #include "FreeRTOS.h" #include "task.h" #include "queue.h" char Switch; char KillApp; xTaskHandle xHandle_led; void vLEDs(void *pvParameters) {     // initialisatie     mJTAGPortEnable( 0 );     TRISA = 0;     xHandle_led = 0;     while(1){            if(Switch){         PORTA     = 0;         Switch     = 0;     }     else     {         PORTA     = 0xFFFF;         Switch     = 1;     }                if (KillApp == 1)     {         PORTA = 0;         KillApp = 0;         vTaskDelete( NULL );            }            vTaskDelay( 20 );                // Taak code     } }    void vTaskCreateKnipperLed(void) {        xTaskCreate( vLEDs, "LED",configMINIMAL_STACK_SIZE * 2, NULL, tskIDLE_PRIORITY, &xHandle_led ); } void vTaskDeleteKnipperLed(void) {     KillApp  = 1;    }

> It seems that the function vTaskDelete somehow ends up in a > endless loop. I noticed this because when I call it from the > display task, the display task will freeze permanently after > 21 sec. running time. Have you actually seen on the debugger that vTaskDelete() ends in a loop?  I’m not sure there are any loops in that function.  If you pause the code on the debugger, where does it end up? > Till 21 sec. it does it job; every 3 > sec. it will kill or start the LED task. Could this be a memory fragmentation issue?  Which heap_x scheme are you using? > To prevent the display task from freezing (because then i > cannot see any variables or use full info anymore on the > display), i created a function that only gives the LED task a > "true" variable so when the LED task gets executed it will > read the "true" variable and thus killing itself. Why create a task to do this, rather than just set the variable from the display task?  Although there is no reason why just deleting the task directly should not work. When calling vTaskDelete() it is very important that the idle task is not starved out as the memory the task was allocated is freed from within the idle task.  However you said there are no other tasks running so this cannot be the problem (unless you are using an idle task hook that never returns?). Take a look at the file FreeRTOS/Demo/Common/Minimal/death.c.  This example creates and deletes tasks at run time.  I think the standard demo app that comes for the PIC32 on the Explorer 16 includes this demo file. Regards.

[quote] Have you actually seen on the debugger that vTaskDelete() ends in a loop? I’m not sure there are any loops in that function. If you pause the code on the debugger, where does it end up? [/quote] At the moment I do not have a debugger for this PIC32, so unfortunately i cannot check this. [quote] Could this be a memory fragmentation issue? Which heap_x scheme are you using? [/quote] heap_2.c is used. According to the information on Freertos, this should be no problem. Although, I must admit that I do not have much knowledge (yet) in FreeRtos memory organization. [quote] When calling vTaskDelete() it is very important that the idle task is not starved out as the memory the task was allocated is freed from within the idle task. However you said there are no other tasks running so this cannot be the problem (unless you are using an idle task hook that never returns?). [/quote] I`m not using the idle hook (disabled in the FreertosConfig). So there should be plenty of time left for the idle "tasks". [quote] Take a look at the file FreeRTOS/Demo/Common/Minimal/death.c. This example creates and deletes tasks at run time. I think the standard demo app that comes for the PIC32 on the Explorer 16 includes this demo file. [/quote] There was no death.c example for the PIC32. In the FreeRtosConfig, task deletion was also disabled. Together with vTaskCleanUpResources ( i think this is the IDLE memory defrag?) I enabled it in the config. But anyway, i did analyze the death.c earlier today and I don’t see much of a difference. At the moment the display keeps running and does everything correct. What I see is that, even at the first task deletion, the LED task keeps running (while I’m certainly that the task delete function was executed). After having the kill variable set multiple times (and thus calling the taskdelete multiple times) the LED task will stop.

SOLVED! There was a problem in the display task that kills and create the LED task. In both files (LED task and Display task) i used the same variable "int Switch". This Switch variable indicated me in the display task whether the last action was "kill the task" (Switch = 0) or "create the task" (Switch is 1).  The same name variable Switch did i used in the LED task to toggle the LEDs, so i know there last state (i know, i could have check the PORTA state too). Apparently i may not use the same variable name  in both files. Anyway, the program now runs as it should be! Thanks!