Hi, I have an application running on a dsPIC33F that has 3 tasks : Task A priority tskIDLEPRIORITY + 1 Task B priority tskIDLEPRIORITY + 2 Task C priority tskIDLE_PRIORITY + 3 Task C performs a short piece of code, then deletes itself. Only tasks A and B remain then. Task A is a loop timed with a vTaskDelayUntil, which execute once every second. Task B is a loop controlled by a vTaskSuspend( NULL ) ; it is awaken by an interrupt service routine, with a priority equal to that of the kernel, which calls xTaskResumeFromISR when data is available. If I configure the project to be in cooperative mode, it works correctly. If I use the preemptive mode, tasks C and A execute once each, and task B executes twice, then all is frozen. The kernel runs forever without returning to any task. I had a look at the code, and found that the execution went throug xTaskIncrementTick forever, without switching any task. If I understand correctly, this function only handles the time slicing of tasks of tskIDLE_PRIORITY. Since my tasks have both higher priorities, they are not considered in this function and their execution is frozen. I suppose that sometime before, a call to portYield has been missed? Please advise me. Jean-Marc

Addition to my previous post : I am using the MPLAB-X 3.05 IDE, with the FreeRTOS viewer plugin v2.3. The viewer has one problem : the running taks is never shown as running, only as ready. Since the viewer is said to be compatible with FreeRTOS up to version 8.0, Is there a change since that prevents the viewer from showing the running task?

Don’t synchronise a task using vTaskSuspend()/xTaskResumeFromISR()! You are creating a race confiditon for yourself, and suspect that is the problem. Use a direct to task notification instead, as shown by the code snippet on the following page: http://www.freertos.org/RTOSTaskNotificationAsCounting_Semaphore.html

Thanks for the advice. Using the Notify mechanism is simpler to use. However, I am sorry to tell it, but the problem did not disappear. The same phenomena occur after modification.

What is the priority of the interrupt? It needs to be set to the lowest possible priority.

The interrupt priority is 1, the same as that of the timer interrupt that drives the kernel.

So, no clue?

No, don’t know I’m afraid. If you could create a very (very!) small and buildable application (with no absolute paths that will prevent building on a different machine) and send it to me I could have a look. You can send it to r [ dot ] barry _ at _ FreeRTOS [dot] org.

Having looked at the code the first thing I notice is you are using a dsPIC ‘E’ part, and our distribution only supports the extended parts for PIC24, and not the dsPIC, as far as I recall (the primary reason being that the dsPIC has some context registers that cannot be saved and restored by software – although avoiding those registers is quite easy I think). Next I see the code has been modified quite heavily, so I’m afraid we are unable to provide support.

I am aware that the official port excludes the dsPIC33E, but there is a contribution that fills this gap, provided the dsp specific instructions are not used. Thus the kernel that is included in my project is the pure FreeRTOS 8.2.3, plus the port I found at http://interactive.freertos.org/entries/28123677-FreeRTOS-V7-5-3-port-for-ALL-16-bit-pics-with-hardware-stack-checking-SPLIM- No other change has been made, except the tuning in the FreeRTOSConfig.h file.

It might have been nice if you had not given up and just looked at his tasks – you would have immeadiately noticed that he didn’t call port yield after calling vTaskNotifyGiveFromISR( TacheCalcul, &xHigherPriorityTaskWoken ); especially since you just fixed the bug in vTaskNotifyGiveFromISR not setting vTaskNotifyGiveFromISR. PS. note neither portENDSWITCHINGISR( x ) / portYIELDFROMISR( x ) are defined in the PIC24 ports – what is the correct choice? As for my version of the port being heavily modified, may I remind you that what I did was combine the 2 asm and 1 C files into one, removed the dependance on MPLAB, made it much easier to add new versions and added the dsPIC E. I also added hardware stack checking which I am more than happy to remove.

Mike, could you please help me understand what you write? I understand I should call port yield from my ISR just after calling vTaskNotifyGiveFromISR, is this right? And if yes, why? What do you mean with “you just fixed the bug in vTaskNotifyGiveFromISR not setting vTaskNotifyGiveFromISR” ?

Mike, I had only read your last post, not that meanf for me. I have added the call to PortYield and it works now. Thanks. Will the bug you mention be fixed in a version due soon? Or should I patch it myself?

J-M the big was fixed in December, but not yet released. As long as you call PortYield (at some point to be fixed to the right name), which is what you want to do regardless, you don’t have to worry about the bug.

There is a release candidate for V9 available now – although there was one very small change made since whereby the xYieldRequired variable is set in all cases, whereas in the release candidate it was only set if the pxHigherPriorityTaskeWoken parameter was NULL.