From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19077 invoked by alias); 23 Jul 2012 08:42:38 -0000 Received: (qmail 18757 invoked by uid 22791); 23 Jul 2012 08:42:35 -0000 X-SWARE-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Jul 2012 08:42:22 +0000 Received: by wibhm11 with SMTP id hm11so2171160wib.12 for ; Mon, 23 Jul 2012 01:42:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.81.165 with SMTP id b5mr47021863wiy.17.1343032940811; Mon, 23 Jul 2012 01:42:20 -0700 (PDT) Received: by 10.194.28.198 with HTTP; Mon, 23 Jul 2012 01:42:20 -0700 (PDT) In-Reply-To: <50083CAF.8060604@kuantic.com> References: <50082BCC.4020905@kuantic.com> <50083CAF.8060604@kuantic.com> Date: Mon, 23 Jul 2012 08:42:00 -0000 Message-ID: From: Alan Bowman To: ecos-discuss@ecos.sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Interrupt stacking issues X-SW-Source: 2012-07/txt/msg00034.txt.bz2 I think I've got some understanding of why I'm seeing my stack overflow, and I'm not quite sure what to do about it. I think that this describes the circumstances: 1 A character arrives at the serial port, triggering the ISR. 2 The ISR runs to completion, signalling the PendSV handler. 3 The PendSV handler pushes a "fake" stack frame onto the stack of the executing thread, adding hal_interrupt_end and hal_interrupt_end_done into the backtrace. 4 PendSV exits, returning the processor to its normal mode, but running hal_interrupt_end. 5 hal_interrupt_end ultimately results in DSRs being called. 6 Normal thread execution is resumed. I think that the problem might occur if another interrupt arrives while step 4 is occurring. There is an extra frame on the stack, but all the interrupts (and PendSV) have run and are capable of being re-run. If another interrupt arrives at this point, the ISR/PendSV runs again, and _another_ fake frame is pushed to the stack. A series of evenly spaced interrupts (such as one would find in a serial stream) will push fake frames to the stack until overflow. I could disable serial interrupts in the ISR and re-enable in the DSR, but that defeats the object of the STM32 serial driver copying data into an intermediate buffer in the ISR. This would also be affected by any other unfortunately timed interrupts. If I've understood this right, one doesn't just need to size stacks based on the number of simultaneously triggered ISRs that might occur, but also on the number that might occur in a row one after another. I really hope that either a) I've misunderstood the issue, or b) I've missed an obvious fix. Can anyone confirm that I've understood this, or suggest any options? Thanks Alan -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss