Preemptive mode fails on dsPIC33 port

Kernel
1

j-md wrote on Tuesday, January 19, 2016:

Hi,

I have an application running on a dsPIC33F that has 3 tasks :

Task A priority tskIDLE_PRIORITY + 1
Task B priority tskIDLE_PRIORITY + 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

2

j-md wrote on Tuesday, January 19, 2016:

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?

3

rtel wrote on Tuesday, January 19, 2016:

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/RTOS_Task_Notification_As_Counting_Semaphore.html

4

j-md wrote on Tuesday, January 19, 2016:

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.

5

rtel wrote on Tuesday, January 19, 2016:

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

6

j-md wrote on Wednesday, January 20, 2016:

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

7

j-md wrote on Friday, January 22, 2016:

So, no clue?

8

rtel wrote on Friday, January 22, 2016:

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.

9

rtel wrote on Wednesday, January 27, 2016:

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.

10

j-md wrote on Wednesday, January 27, 2016:

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.

11

dragonflight1 wrote on Sunday, February 21, 2016:

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 portEND_SWITCHING_ISR( x ) / portYIELD_FROM_ISR( 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.

12

j-md wrote on Monday, February 22, 2016:

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” ?

13

j-md wrote on Monday, February 22, 2016:

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?

14

dragonflight1 wrote on Monday, February 22, 2016:

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.

15

rtel wrote on Monday, February 22, 2016:

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.