FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [January 2016 Threads] Preemptive mode fails on dsPIC33 portPosted by j-md on January 19, 2016 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
Preemptive mode fails on dsPIC33 portPosted by j-md on 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?
Preemptive mode fails on dsPIC33 portPosted by rtel on 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/RTOSTaskNotificationAsCounting_Semaphore.html
Preemptive mode fails on dsPIC33 portPosted by j-md on 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.
Preemptive mode fails on dsPIC33 portPosted by rtel on January 19, 2016 What is the priority of the interrupt? It needs to be set to the lowest
possible priority.
Preemptive mode fails on dsPIC33 portPosted by j-md on January 20, 2016 The interrupt priority is 1, the same as that of the timer interrupt that drives the kernel.
Preemptive mode fails on dsPIC33 portPosted by j-md on January 22, 2016
Preemptive mode fails on dsPIC33 portPosted by rtel on 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.
Preemptive mode fails on dsPIC33 portPosted by rtel on 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.
Preemptive mode fails on dsPIC33 portPosted by j-md on 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.
Preemptive mode fails on dsPIC33 portPosted by dragonflight1 on 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 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.
Preemptive mode fails on dsPIC33 portPosted by j-md on 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" ?
Preemptive mode fails on dsPIC33 portPosted by j-md on 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?
Preemptive mode fails on dsPIC33 portPosted by dragonflight1 on 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.
Preemptive mode fails on dsPIC33 portPosted by rtel on 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|