Dear All,

I am using FreeRTOS version 7.5.2 since about 2 years without any problem on PIC24F, until I decided for some technical reasons to change task priority, if all my task has same priority NO problem, if the task ( or any task) has lowest priority than the others , this task never start, if you can give some way to search or debug in my complex source file, it will be fine.

here my a part of my main source code :

xTaskCreate( vTaskCOM1Process,( signed char * )"C1P", configMINIMALSTACKSIZE*2,NULL, 3,NULL); xTaskCreate( vTaskCOM2Process,( signed char * )"C2P", configMINIMALSTACKSIZE,NULL, 3,NULL); xTaskCreate( vTaskStartP24,( signed char * )"CCP", configMINIMALSTACKSIZE,NULL, 5,NULL);

xTaskCreate( vTaskPOOLAnalog,( signed char * )"CANA", configMINIMALSTACKSIZE*2,NULL,2,NULL);

vTaskSerial1Start();

vTaskSerial2Start();

vTaskStartScheduler();

The vTaskPOOLAnalog with priority 2 never start !

Regards David

If a higher priority task never blocks (calls a delay function, or waits for queue data or semaphore etc) then lower priority tasks will be 'starved', meaning they wont ever be scheduled.

Dear,

My higher priority task looks like this :

void vTaskCOM2Process( void * pvParameters ) { COMfifonode comget; for (;;) { if( xSemaphoreTake( xCOM2fifo_protect,0) == pdPASS ) { /// undisclosed code

   xSemaphoreGive(xCOM2_fifo_protect);

} else { taskYIELD(); } } }

is there is any problem here ?

Rgds

is there is any problem here ?

Yes. This code is using 0 as the block time so is not waiting for the semaphore. It will just spin round the loop very quickly, not letting lower priority tasks run. The taskYIELD() will let tasks that have the same priority run, but that is all. If you use a block time in your call to xSemaphoreTake() it should fix your problem.

Look at the xTicksToWait parameter http://www.freertos.org/a00122.html

And how to determine block time ?, for my understand any value should be fine since as soon as semaphore is free to use the test will succeed.

If the task has nothing to do until it has the semaphore then use portMAX_DELAY, which will leave it in the blocked state as long as possible.

The basic problem is that Yield doesn't block, it only lets other tasks of the same priority run before you.

Since all you are doing on the Semaphore take is yielding, you might as well put in a block time and let the task just block until the semaphore is given.

The block time could be set to the max, or if you want to have some error recovery, make it longer than you every should need to wait, and then you have the option of seeing if you see signs of problems before retrying.