Re: Ravenscar and context switching for Cortex-M4

[Simon Wright <simon@pushface.org>]

Patrick Noffke <patrick.noffke@gmail.com> writes: 
 
> Here's what happens now (the order of the interrupts may change 
> between runs, but this is for one capture): 
> 
> 1. UART interrupt triggers.  2. PO1's entry executes. 
 
because the entry body is executed in interrupt context. See 
below. 
 
> 3. SPI interrupt triggers twice (see below).  4. PO2's entry 
> executes.  5. T1 (UART task) executes.  This is the first thing 
> wrong.  T2 is higher priority than T1 so T2 should run first. 
> 6. T2 (SPI task) executes twice.  Upon the second execution, I 
> get a program error because Object.Entry_Queue is null.  The 
> exception is 
 
Entry_Queue is *not* null, as you said in the next post. 
 
> raised in s-tposen-raven.adb (line 167 in my copy) in 
> Protected_Single_Entry_Call. 
> 
> This may be relevant -- the SPI interrupt triggers twice.  This 
> is because the interrupt is for a DMA completion, and it fires 
> both when TX and RX complete (since it's SPI, they complete at 
> the same time).  I take care in my interrupt handler to release 
> the entry from only one of the two interrupts.  Perhaps with the 
> interrupt firing twice, the runtime may get confused and 
> activate the task twice (even though the entry only executes 
> once).  But for the above run, the entry was released during the 
> second SPI interrupt. 
 
The RTS does this (I hope I have it right): 
 
   The entry call (Protected_Single_Entry_Call):

     locks the entry
     if the barrier is open then
       asserts that Call_In_Progress isn't set
       sets Call_In_Progress
       calls the entry body wrapper
       clears Call_In_Progress
       unlocks the entry
     else
       if the Entry_Queue isn't null then
         unlocks the entry
         raises PE
       end if
       sets the Entry_Queue
       unlocks the entry
       sleeps
     end if

   The handler wrapper:

     locks the entry
     calls another wrapper for the handler itself
     calls Service_Entry
     exits

   Service_Entry:
     if the Entry_Queue is set and the barrier is open then
       clears the Entry_Queue
       asserts that Call_In_Progress isn't set
       sets Call_In_Progress
       calls the entry body wrapper
       clears Call_In_Progress
       saves the caller task_id
       unlocks the entry
       wakes the caller
     else
       unlocks the entry
     end if

I really don't see how the sequnece you describe happens!

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!

My version of lock does

   procedure Lock (Object : Protection_Access) is
   begin
      if FreeRTOS.Tasks.In_ISR then
         null;
      elsif Object.Ceiling in System.Interrupt_Priority then
         FreeRTOS.Tasks.Disable_Interrupts;
      else
        --  do ceiling priority stuff