Re: Ravenscar and context switching for Cortex-M4

[Patrick Noffke <patrick.noffke@gmail.com>]

On Thursday, August 6, 2015 at 4:05:15 PM UTC-5, Patrick Noffke wrote:
> On Monday, February 16, 2015 at 3:28:08 PM UTC-6, Simon Wright wrote:
> 
> > One thing that puzzles me is the locking/unlocking of the entry: this is
> > done (in that RTS) by raising the caller task's priority to the ceiling
> > priority of the task, if necessary. So what about interrupts? And when
> > the handler wrapper (you can see this by compiling the package with the
> > PO in with -gnatdg) locks the entry, it seems to raise the current
> > task's priority, where the current task has nothing to do with the PO at
> > all!
> > 
> 
> There is another bug that I've discovered in the GNAT 2015 Ravenscar-full runtime (Cortex-M4) that appears to be caused by the Interrupt_Wrapper changing the task's priority.  When there is no Runnable task, Leave_Kernel will Insert the non-Runnable task back into the ready queue (with state of Delayed or Suspended).  This task is also stored in the Running_Thread_Table (only one value in the table for a single CPU).  Then an interrupt comes along and raises the priority of the Runnable_Thread_Table task (which is Delayed) to that of the interrupt.  And the task that is woken up by the interrupt goes later in the ready queue, since its priority is now lower than the Delayed task.
> 
> This ultimately causes the task that was readied by the interrupt to not run (in my case, it never runs again).  I haven't traced all the subsequent behavior to know exactly why this happens, but if I don't change priorities in the Interrupt_Wrapper, the problem seems to be gone.
> 
> Does anyone have an idea why the task priorities are changed in the Interrupt_Wrapper?  I'm wondering if I'm introducing a problem that was supposed to be fixed by not changing the priorities.  But as Simon pointed out, the current running task may have nothing to do with the PO associated with the interrupt, so it seems odd to change the priority here.
> 

Not to mention, an interrupt handler (possibly with associated PO) may have nothing to do with *any* task, much less the current task.

A further point of confusion is why Self_Id.In_Interrupt is getting set to True while executing the user handler.  In_Interrupt is used by Current_Interrupt, which seems related to execution time stuff.  I'm not sure if this is needed (or accurate given the above).

Patrick