From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25077 invoked by alias); 18 Oct 2013 15:00:40 -0000 Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org Received: (qmail 25068 invoked by uid 89); 18 Oct 2013 15:00:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.3.2 X-HELO: mail.carallon.com Received: from mail.carallon.com (HELO mail.carallon.com) (95.177.28.122) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Oct 2013 15:00:40 +0000 X-MDAV-Result: clean X-MDAV-Processed: mail.carallon.com, Fri, 18 Oct 2013 16:00:37 +0100 Received: from [172.20.1.41] by mail.carallon.com (Cipher TLSv1:-SHA:128) (MDaemon PRO v13.6.0) with ESMTP id md50001428894.msg for ; Fri, 18 Oct 2013 16:00:37 +0100 X-Spam-Processed: mail.carallon.com, Fri, 18 Oct 2013 16:00:37 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 172.20.1.41 X-Return-Path: andrewp@carallon.com X-Envelope-From: andrewp@carallon.com X-MDaemon-Deliver-To: ecos-devel@ecos.sourceware.org Message-ID: <52614D10.1040801@carallon.com> Date: Fri, 18 Oct 2013 15:00:00 -0000 From: Andrew Parlane User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: ecos-devel@ecos.sourceware.org Subject: Nested interrupts on ARM Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00000.txt.bz2 I found a bug with our product which boils down to a high priority interrupt not being called fast enough sometimes because we are in a different ISR (lower priority). We have CYGSEM_HAL_COMMON_INTERRUPTS_ALLOW_NESTING on, but looking through the code this does very little on ARM chips (just sets the min stack size). Looking at packages/hal/arm/arch/current/src/vectors.S it looks like the framework for nested interrupts is in place, but during an interrupt the IRQ bit in the CPSR register is never cleared. I wrote the following patch, which enables IRQs runs the ISR and disables IRQs again. This works, and I can now see nested interrupts working, however I'm now seeing it take 30us to get into my high priority ISR when I'm already in an ISR, rather than the 7us when I'm not already in an ISR. So my questions: 1) Does my patch make sense? 2) Any idea why this wasn't already in place? It seems like something so simple must have been left out for a reason. 3) Any idea on the 30us to get into my ISR? This may be the first ISR disabling IRQs for a bit, I need to look more into this area. Thanks, Andrew Parlane Carallon Ltd. --- a/packages/hal/arm/arch/current/src/vectors.S +++ b/packages/hal/arm/arch/current/src/vectors.S @@ -914,7 +914,14 @@ IRQ: #endif // CYGIMP_HAL_COMMON_INTERRUPTS_IGNORE_SPURIOUS b spurious_IRQ -10: ldr r1,.hal_interrupt_data +10: + // re-enable IRQs so we can have nested interrutps + ARM_MODE(r1,10) + mrs r1,cpsr + bic r1,r1,#CPSR_IRQ_DISABLE + msr cpsr, r1 + + ldr r1,.hal_interrupt_data ldr r1,[r1,v1,lsl #2] // handler data ldr r2,.hal_interrupt_handlers ldr v3,[r2,v1,lsl #2] // handler (indexed by vector #) @@ -926,6 +933,11 @@ IRQ: mov lr,pc // invoke handler (call indirect bx v3 // thru v3) + // disable IRQs + mrs r1,cpsr + orr r1,r1,#CPSR_IRQ_DISABLE + msr cpsr, r1 + spurious_IRQ: