Re: Ravenscar and context switching for Cortex-M4

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

On Thursday, February 12, 2015 at 2:25:40 PM UTC-6, Patrick Noffke wrote:
> I am porting the GNAT Ravenscar-sfp runtime to work with the TI TM4C MCU, using the STM32F4 implementation as a starting point.  I am having a problem where one of two tasks blocked on entries (each in separate protected objects) is not getting activated.
> 
> Here is the situation:
> 
> I have two POs, each with an interrupt handler and an entry.  PO1 services UART interrupts and PO2 services SPI interrupts.  When each interrupt fires, the barrier in the corresponding entry is released.
> 
> Then I have two tasks, T1 and T2.  T1 is blocked on PO1's entry and T2 is blocked on PO2's entry.
> 

I have changed things up a bit now just to see if I can get any more insight.  Now T2 is the main program (no longer an Ada task, but AFAICT the runtime doesn't distinguish between main and a task with regard to context switching).

> The problem happens when the interrupts happen very near in time to each other.  Then, both entries are still executed, but only one task runs after the last entry completes.  I have instrumented the run-time as well as my code to toggle GPIOs and see what's happening when.  Here is the timing that fails:
> 
> 1. SPI interrupt triggers.
> 2. Interrupt_Request_Handler in s-bbcppr-armv7m.adb is executed.  It calls my interrupt handler or PO2, followed by the entry (entry called in the interrupt context), and triggers a context switch for T2.
> 3. Before the task T2 can run, the UART interrupt triggers.
> 4. Interrupt_Request_Handler calls my interrupt handler for PO1 and its entry, and triggers a context switch for T1.
> 5. T1 then runs until it blocks again on the entry for PO1.
> 
> T2 never runs.  Furthermore, after this occurs, the entry for PO2 is never executed again (though its interrupt handler is).  T2 also never runs again.
> 

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.
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 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.

Please let me know if you have any suggestions.

Best regards,
Patrick