FreeRTOS 8.2.1 PIC32MX port + heap_4.c Got some troubles when delete and recreate task. Here is test code:

static void empty_thread(void *param) { for(;;) { vTaskDelay(10); } }

static void ApplicationTaskThread(void *params) { for(;;) { uint32t priority = uxTaskPriorityGet(NULL) + 1; TaskHandlet task = NULL; xTaskCreate(emptythread, "empty", 128, NULL, priority, &task); ASSERTNE(task, NULL);

 vTaskDelay(0);

 vTaskDelete(task);
 vTaskDelay(1);

} }

void vApplicationIdleHook( void ) { for(;;) { taskYIELD(); } }

I can create breakpoint and see that idle hook get processor time. Still task resources are never freed. I am using MPLAB X RTOSviewer plugin for debuging.

Screenshot in attachment.

What am i doing wrong? Thanks in advance.

Update. Cant fomat code somehow readable. Is there any special tag?

Last sentense, third paragraph http://www.freertos.org/a00016.html your idle hook never returns.

Thanks alot. Still wonder why there is no word about that in vTaskDelete article and example.

Third paragraph http://www.freertos.org/a00126.html

I've read that. Not a word about that IdleHook should return.

With respect - if it is stated that the idle task is responsible for freeing memory, then you can assume the idle task contains code that performs the free operations, and also assume that if your hook function prevents anything executing in the idle task other than the hook function, then the free operations will never execute.

Regards.

To begin with, OP Valentin has two significant mis-understandings here that are hard to see for the experienced, might be worth adding to the documentation somewhere or making checkable by lint or a compiler or adding comments to the prototypes in the header file:

A hook function is not a task function. It is a piece of a system "task"(whether or not it has a TCB) within freeRTOS -- examples being the system idle task and the idle hook and the scheduler and the tick hook. As such, failure of such functions to return means an essential part of the freeRTOS system is rendered inoperable.

With or without lint, an upgraded prototype for a task would be NORETURN( void userTaskd(...); ) and an appropriate prototype for a hook function would be MUST_RETURN( void vXyzHook(void); )

That makes the point both clear to everyone, and automatically checkable.

A second possible misconception is that the idle task is actually completely idle. It actually does something important -- reclaiming memory from deleted tasks.

The third misconception is that taskYIELD is appropriate within the idle task. What lower-priority task would run when the idle task yields? Hint: the idle task itself, exactly where it left off. I don't think that is what the OP had in mind...so I'll speculate that OP has a higher priority something that he wants to run before the current scheduling tick is complete. That something should either be an interrupt or simply called once from the idle task hook.

taskYIELD is entirely appropriate in the idle task, as it allows switching to another priority level 0 task that might exist. (taskYIELD is only useful because you can have multiple tasks at the same priority level, as (since the task is still marked as "Ready") it will only let another task at the same priority run. I find it not uncommon to create additional priority 0 tasks that will normally execute in a round robin fasion, each performing some low priority 'maintance' operation.

An idle priority task yielding lets the other idle priority tasks get to use more time (as opposed to the idle task just repeatively checking the same flag to see if another task has been deleted to reclaim the space. (The disadvantage is that the task you switch to gets just what is 'left over' of the time slice, so might not get perfectly even time distribution between the various idle tasks.

The idlehook function is good to use when you have some simple idle level processing and don't want the overhead of creating a whole new task to do it. My guideline is something that takes much less than a tick to perform (and doesn't need to block) is a candidate for an idle hook, while longer operations, or operations that might need to block become independent tasks.

There is a configIDLESHOULDYIELD constant that can make the Idle task do this automatically but it needs to be used with care with ports that mean using the constant will result in the processor spending most of its time in a yield interrupt.

Regards.