From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5331 invoked by alias); 31 May 2007 19:43:16 -0000 Received: (qmail 5318 invoked by uid 22791); 31 May 2007 19:43:15 -0000 X-Spam-Check-By: sourceware.org Received: from stelecom.gomel.by (HELO stelecom.gomel.by) (82.209.213.61) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 31 May 2007 19:43:13 +0000 Received: from localhost (localhost [127.0.0.1]) by stelecom.gomel.by (Postfix) with ESMTP id DE771B00117D; Thu, 31 May 2007 22:43:10 +0300 (EEST) Received: from stelecom.gomel.by ([127.0.0.1]) by localhost (stelecom.gomel.by [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20189-41; Thu, 31 May 2007 22:43:09 +0300 (EEST) Received: from localhost (unknown [86.57.140.74]) by stelecom.gomel.by (Postfix) with ESMTP id 2C77AB00DF97; Thu, 31 May 2007 22:43:09 +0300 (EEST) Date: Thu, 31 May 2007 21:07:00 -0000 From: Sergei Gavrikov To: Neeraja Cc: ecos-discuss@ecos.sourceware.org Message-ID: <20070531194221.GA5749@ubuntu> References: <10887747.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10887747.post@talk.nabble.com> User-Agent: Mutt/1.5.13 (2006-08-11) 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] Board is hanging running for long duration X-SW-Source: 2007-05/txt/msg00221.txt.bz2 Neeraja wrote: > > Hi, > > I am working on at91rm9200 board.Ecos application is running fine but > after running for more than 1 day board is hanging.I could see in > hyperterminal it is coming to the hal_arch_default_isr( ) function with the > interrupt number 1 after the board got hanged.Ethernet interrupt and IRQ0 > interupt and two alaram timers one with one sec and the other with 8 sec > intervals are being used in the application.Could the cause of this can be > spurious interrupt or can any one suggest me what could be the cause for > such behaviour? 1. _Seek_ through out the discuss-list and even _grep_ ecos sources (whole tree) about spurious interrupts report. You will found there the good bits. 2. Usually, the 'spurious interrupt report' is an issue of bad worked (or designed) hardware. If there is no man which use same target and cry about, that means, your hardware fails. Sometimes, some random event occurs (say, it's a "noise" that can "induct" such event). 3. Run your "a few days in long" test with eCos tracing enabled (to increase the trace buffers will be a good idea) cdl_option CYGPKG_INFRA_DEBUG {user_value 1}; cdl_option CYGDBG_USE_TRACING {user_value 1}; 4. Well, that occurs. You have a report, you see a chain and you think, It isn't possible... To ignore such interrupts is a very _bad_ practice. But, in the some exceptional cases, you can clever (or stupid?) handle that event without of stop of the application. Certainly, if there won't be a whole storm of such events there. Sergei -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss