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.70.35.70 with SMTP id f6mr5423087pdj.7.1423772739403; Thu, 12 Feb 2015 12:25:39 -0800 (PST) X-Received: by 10.182.68.113 with SMTP id v17mr53776obt.38.1423772739077; Thu, 12 Feb 2015 12:25:39 -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!news.glorb.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!hl2no10743584igb.0!news-out.google.com!db6ni25589igc.0!nntp.google.com!hl2no10743583igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 12 Feb 2015 12:25:38 -0800 (PST) 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 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Ravenscar and context switching for Cortex-M4 From: Patrick Noffke Injection-Date: Thu, 12 Feb 2015 20:25:39 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:24953 Date: 2015-02-12T12:25:38-08:00 List-Id: I am porting the GNAT Ravenscar-sfp runtime to work with the TI TM4C MCU, u= sing the STM32F4 implementation as a starting point. I am having a problem= where one of two tasks blocked on entries (each in separate protected obje= cts) 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 b= locked on PO2's entry. The problem happens when the interrupts happen very near in time to each ot= her. Then, both entries are still executed, but only one task runs after t= he last entry completes. I have instrumented the run-time as well as my co= de 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 int= errupt 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 ent= ry, 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= . I'm not yet familiar enough with the runtime to know what's happening. But= perhaps the issue is related to using Pend_SV_Handler to trigger the conte= xt switch. Does the "pending" context switch for T1 never get executed sin= ce T2 is switched in before the Pend_SV_Handler can execute? I'm reluctant= to muck with Pend_SV_Handler to instrument the code since I don't want to = perturb the processor registers and break that which I'm trying to instrume= nt. If it's useful, T1's priority is 10 and T2's priority is 190. So even thou= gh T1 is lower priority than T2, T1 is switched in before T2 can run. Both interrupt handlers are the same priority. Also, if the second interrupt does not happen before the first task can run= , then everything is fine (i.e. both tasks get their turn to run). According to http://docs.adacore.com/gnathie_ug-docs/html/gnathie_ug/gnathi= e_ug/the_predefined_profiles.html#ada-restrictions-in-the-ravenscar-profile= s, at most one task may be queued on an entry. I take this to mean *on a s= ingle entry* and that two tasks may be simultaneously queued on separate en= tries. Is that correct? If not, then this is the problem. But I've seen = other suggestions in this list that my interpretation is correct. Best regards, Patrick