From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13153 invoked by alias); 6 Apr 2006 06:49:43 -0000 Received: (qmail 13145 invoked by uid 22791); 6 Apr 2006 06:49:43 -0000 X-Spam-Check-By: sourceware.org Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Apr 2006 06:49:40 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1FROFs-00073z-00; Thu, 06 Apr 2006 08:46:08 +0200 Date: Thu, 06 Apr 2006 06:49:00 -0000 To: Joe Porthouse Cc: 'eCos Discussion' Message-ID: <20060406064608.GF12221@lunn.ch> Mail-Followup-To: Joe Porthouse , 'eCos Discussion' References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060126 From: Andrew Lunn X-IsSubscribed: yes 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 Subject: Re: [ECOS] DSR stops running after heavy interrupts. X-SW-Source: 2006-04/txt/msg00063.txt.bz2 On Wed, Apr 05, 2006 at 05:09:41PM -0400, Joe Porthouse wrote: > In a nutshell: > The real time clock DSR stops getting called after several minutes > of heavy UART ISR traffic. I have been running into this on and off for a > while. Lowering the serial ISR priority seems to help some, but not > eliminate the problem. > > Background: > Application is on a custom xScale PXA255 board without redboot. > When problem occurs the Real Time tick clock simply stops updating. All > other aspects of the program seem to work correctly. The real time ISR is > still getting called as well as other ISRs, but the real time clock DSR is > no longer called. > > In the Vectors.S file I can step through the execution and see what > is happening. On return from the ISR the return code is examined to > determine if a DSR call should be added to the DSL list. This check is done > here: > > // The return value from the handler (in r0) will indicate whether a > > // DSR is to be posted. Pass this together with a pointer to the > // interrupt object we have just used to the interrupt tidy up > > cmp v1,#CYGNUM_HAL_INTERRUPT_NONE > beq 17f > > When the problem occurs the branch (beq) is occurring that skips > adding the DSR to the list and ends the ISR. I can see that R0 is correctly > 0x03 but the branch still occurs. The problem may be in how this is getting > compiled. In my JTAG tool I see the above code as: > > 00008C5C e3740001 CMN R4,#00000001 > 00008C60 0a000003 BEQ 00008c74 > > Obviously there is some assembler substitution going on. I'm not > sure why if the value is in r0, why v1 is being checked (not familiar with > the "v" register notation). Also not sure why the resulting code refers to > R4. R4 has a different value then R1 at this point in the execution. > > Any ideas on this? The fast that this works for a while and then breaks suggests it is something unusual going on. When the problem occurs take a look at the actually contents of memory which contains these instructions. Has it been corrupted? Be careful with your debugger here. If you just ask it to disassemble the code it might show you what is in the elf file, not what is in memory. Do a hex dump and compare the machine code bytes. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss