From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32402 invoked by alias); 6 Apr 2006 21:09:02 -0000 Received: (qmail 32386 invoked by uid 22791); 6 Apr 2006 21:09:01 -0000 X-Spam-Check-By: sourceware.org Received: from mail.toptech.com (HELO toptech.com) (207.13.72.10) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Apr 2006 21:08:55 +0000 DKIM-Signature: a=rsa-sha1; c=simple; d=toptech.com; s=MDaemon; t=1144357733; x=1145567333; q=dns; h=DomainKey-Signature: Received:Reply-To:From:To:Subject:Date:Organization:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To:Thread-Index: Message-ID; b=GL3gTCQRxMKaBw5GhoP45g8L9lAqwi0+ATNtR+Y89aur40/HohB yP3ASwampa5cwlojlwvt0uBUYHWrbpAVHjA5Gy8wSChWYr5cYJikkBqR36BcDcix tZsfAsFrILkKP+cKhKLE5KLfYQloVOJJBZlllrVO5KM0STn3Fr4UpGr4= Received: from jporthousexp2 by toptech.com (MDaemon PRO v9.0.0) with ESMTP id md50000003714.msg for ; Thu, 06 Apr 2006 17:08:53 -0400 Reply-To: From: "Joe Porthouse" To: Date: Thu, 06 Apr 2006 21:09:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <002101c65958$a9ad5160$8262fea9@nullnullsix> X-HashCash: 1:20:060406:ecos-discuss@ecos.sourceware.org::rHDBaYchmu8+v32g:000000000000000000000000000000ycZ X-Spam-Processed: mail.toptech.com, Thu, 06 Apr 2006 17:08:53 -0400 (not processed: message from valid local sender) X-MDRemoteIP: 172.16.65.158 X-Return-Path: jporthouse@toptech.com X-MDaemon-Deliver-To: ecos-discuss@ecos.sourceware.org Message-ID: X-MDAV-Processed: mail.toptech.com, Thu, 06 Apr 2006 17:08:53 -0400 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/msg00076.txt.bz2 Stefan, thanks. I'm glad to know I'm not the only one experiencing this problem. I have made a little more progress. I still can't explain the issues with the code listed in my first message with the code checking the return value from the ISR, but I believe it is somehow working correctly. I still believe there may be a problem with R4 being checked instead of R0. I did verify that the memory was the same as my code window, as well as the flash image. This is what I did find. DSR calls are being added to the table... thousands of them... just not getting serviced. The all calls that lead to "call_pending_DSRs" seem to originate from the unlock_inner() routine getting called. This routine stops getting called when the problem occurs. (you can see the logic below) inline void Cyg_Scheduler::unlock() { // This is an inline wrapper for the real scheduler unlock function in // Cyg_Scheduler::unlock_inner(). // Only do anything if the lock is about to go zero, otherwise we simply // decrement and return. As with lock() we do not need any special code // to decrement the lock counter. CYG_INSTRUMENT_SCHED(UNLOCK,get_sched_lock(),0); HAL_REORDER_BARRIER(); cyg_ucount32 __lock = get_sched_lock() - 1; if( __lock == 0 ) unlock_inner(0); else set_sched_lock(__lock); HAL_REORDER_BARRIER(); } Upon examination the __lock value is "6" when unlock() is called at the end of the ISR, thus unlock_inner never gets called. If I get the variable location in the get_sched_lock() back to 1, my DSR calls resume. Mmmmmmm.... So somehow locks are being done without unlocks. I am at a loss to figure out how this is occurring since I do not make lock calls in any of my code. Could interrupt preemption somehow be occurring? Does the hal_disable/enable interrupt calls mess with the lock? Any good ideas on how to track this down? Joe Porthouse -----Original Message----- From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Stefan Sommerfeld Sent: Thursday, April 06, 2006 5:01 AM To: ecos-discuss@ecos.sourceware.org Subject: Re: [ECOS] DSR stops running after heavy interrupts. Hi, >> 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. I had that experience too, not just with the uart (i'm using a PXA270). Currently using my FIFO DSRs it works better, but please do more research on that topic to fix this once and forever. Bye... -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss