Multiple xTaskCreate calls consume all memory

Our processor runs a server in the background which listens for commands. We can command it to send a low value to a pin, wait a bit, and then reset the pin to the default high value. Because of the running server, It is important that the above process is executed as a separate task. As stated here http://www.freertos.org/a00126.html, we create the task (via xTaskCreate(mixer, "Mixer", UINT32_C(2048), NULL, UINT32_C(2), &mixerTask)) which calls the following function: ~~~ void mixer(void * pvParameters) { (void) pvParameters;
    // set PIN LOW code here

    vTaskDelay(1000);

     // set PIN HIGH code here

   vTaskDelete(mixerTask); // delete the task itself (memory is scheduled for being freed)
} ~~~ The task runs each time our server receives a specific command, which is ~10-20 seconds. Apart from the server, we have a timer (created via vTimerCreate) running every 600ms performing a simple task. The problem is that we run out of memory after 3 calls to the vTaskCreate function. Searching the web reveals that the IDLE task is responsible for freeing the memory after the call to vTimerDelete. Should we create this IDLE task ourselves or how else can we solve this problem?

Multiple xTaskCreate calls consume all memory

The idle task is created automatically – you do not need to create it yourself. However, if you are deleting tasks (or in FreeRTOS V9 just if a task deletes itself) you do need to ensure the idle task gets some processing time. The idle task runs at the idle priority (stating the obvious ;o) which is priority 0. If you have tasks above priority zero that never enter the Blocked state (don’t call vTaskDelay(), vTaskDelayUntil(), or otherwise enter the Blocked state to wait for a queue/semaphore/direct to task event) then the Idle task will never run – and I suspect that is your problem. As an aside, why do you create and delete a task each time anyway? When the command is given you can set the pin low and reset a software timer. Once the software timer expires its callback function can set the pin high again.