From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.150.33 with SMTP id uf1mr5933356pab.33.1424376883610; Thu, 19 Feb 2015 12:14:43 -0800 (PST) X-Received: by 10.140.33.202 with SMTP id j68mr136235qgj.27.1424376883557; Thu, 19 Feb 2015 12:14:43 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!hl2no19392199igb.0!news-out.google.com!n6ni12qar.0!nntp.google.com!i13no2405530qae.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 19 Feb 2015 12:14:42 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=74.203.194.21; posting-account=bXcJoAoAAAAWI5APBG37o4XwnD4kTuQQ NNTP-Posting-Host: 74.203.194.21 References: <27492d6c-3bf8-4eb9-8ebb-4d9f621235eb@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <247a5033-337c-4bf9-8b37-c82759d8a2dd@googlegroups.com> Subject: Re: Ravenscar and context switching for Cortex-M4 From: Patrick Noffke Injection-Date: Thu, 19 Feb 2015 20:14:43 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:24988 Date: 2015-02-19T12:14:42-08:00 List-Id: On Monday, February 16, 2015 at 3:28:08 PM UTC-6, Simon Wright wrote: > Patrick Noffke writes:=20 > =20 > > Here's what happens now (the order of the interrupts may change=20 > > between runs, but this is for one capture):=20 > >=20 > > 1. UART interrupt triggers. 2. PO1's entry executes.=20 > =20 > because the entry body is executed in interrupt context. See=20 > below.=20 > =20 > > 3. SPI interrupt triggers twice (see below). 4. PO2's entry=20 > > executes. 5. T1 (UART task) executes. This is the first thing=20 > > wrong. T2 is higher priority than T1 so T2 should run first.=20 > > 6. T2 (SPI task) executes twice. Upon the second execution, I=20 > > get a program error because Object.Entry_Queue is null. The=20 > > exception is=20 > =20 > Entry_Queue is *not* null, as you said in the next post.=20 > =20 > > raised in s-tposen-raven.adb (line 167 in my copy) in=20 > > Protected_Single_Entry_Call.=20 > >=20 > > This may be relevant -- the SPI interrupt triggers twice. This=20 > > is because the interrupt is for a DMA completion, and it fires=20 > > both when TX and RX complete (since it's SPI, they complete at=20 > > the same time). I take care in my interrupt handler to release=20 > > the entry from only one of the two interrupts. Perhaps with the=20 > > interrupt firing twice, the runtime may get confused and=20 > > activate the task twice (even though the entry only executes=20 > > once). But for the above run, the entry was released during the=20 > > second SPI interrupt.=20 > =20 > The RTS does this (I hope I have it right):=20 > =20 > The entry call (Protected_Single_Entry_Call): >=20 > 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 >=20 > The handler wrapper: >=20 > locks the entry > calls another wrapper for the handler itself > calls Service_Entry > exits >=20 > 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 >=20 > I really don't see how the sequnece you describe happens! >=20 > 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! >=20 Thank you for all this! It helps a lot. I didn't know about -gnatdg -- ve= ry useful. I suspect the problem may stem from the fact that Leave_Kernel in s-bbprot.= adb can insert a suspended task into the thread queue. I am guessing someh= ow this is tripping up the runtime when multiple tasks become runnable at t= he same time. I stepped through the debugger at startup, and I can see the suspended task= going into the queue. Then another task is woken up and put at the front = of the queue, so the first task is Runnable and the Next task is Suspended.= Then when Leave_Kernel resumes running (it enables interrupts after inser= ting the suspended task) it may not call Extract (since the running thread = state is Runnable) -- it never considers that the Suspended task it inserte= d might be later in the queue. I haven't yet been able to directly correlate the Leave_Kernel behavior wit= h the task incorrectly waking up twice. I'll keep trying things, but I wan= ted to share what I found so far. What I have confirmed is that I can get the system into a state where there= are two Runnable tasks in the thread queue, and the "Next" field of the la= st one points to the first one. That is: First_Thread_Table (CPU_Id) =3D First_Thread_Table (CPU_Id).Next.Next Right before this happens is when the two tasks are woken up at the same ti= me. It appears the task that runs twice (when I get the Program_Error I reporte= d earlier) is the one that gets put in the queue in the suspended state at = startup (an empirical data point after changing priorities of my tasks). Best regards, Pat