From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7976 invoked by alias); 22 Jul 2004 10:27:07 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 7948 invoked from network); 22 Jul 2004 10:27:05 -0000 Received: from unknown (HELO anchor-post-32.mail.demon.net) (194.217.242.90) by sourceware.org with SMTP; 22 Jul 2004 10:27:05 -0000 Received: from calivar.demon.co.uk ([83.104.54.243] helo=xl5.calivar.com) by anchor-post-32.mail.demon.net with esmtp (Exim 3.35 #1) id 1Bnan3-000Kqq-0W; Thu, 22 Jul 2004 11:27:05 +0100 Received: from xl5.calivar.com (localhost [127.0.0.1]) by xl5.calivar.com (Postfix) with ESMTP id 74D7128BDF; Thu, 22 Jul 2004 11:27:04 +0100 (BST) To: "Daniel Schmidt" Cc: ecos-discuss@sources.redhat.com References: <13967.1090490659@www32.gmx.net> From: Nick Garnett Date: Thu, 22 Jul 2004 10:30:00 -0000 In-Reply-To: <13967.1090490659@www32.gmx.net> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [ECOS] spurious interrupts X-SW-Source: 2004-07/txt/msg00324.txt.bz2 "Daniel Schmidt" writes: > I've debugged my ecos-test-application; and debugged to see where the > interrupt is from. But there is no one sending the interrupt (source=0; > *PXA2X0_ICIR=0) but before reaching this code position my code jumps > around in non program code. That sounds suspicious. Maybe it is just jumping to the IRQ vector, or partway into the IRQ VSR. So it's not a real interrupt at all. > > The spurious interrupt is after the first timerinterrupt (this runs ok) > but the scheduling is not doing well. So I'd assume the stackpointer for > interrupts is wrong (in my application). After proceeding the first > interrupt (timer) after some instructions there come a second jump into > the interrupt handler, but not issued by the interrupt controller. A simple test you could try is to increase the size of your thread stack and maybe the interrupt stack and see if that makes a difference. Another thing to look at is whether you are acknowledging the interrupts correctly. Also double check that the decoding in hal_IRQ_handler() is doing the right thing. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com/ The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss