From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17248 invoked by alias); 2 Jul 2003 10:10:35 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 17234 invoked from network); 2 Jul 2003 10:10:34 -0000 Received: from unknown (HELO jensun147.jennic.com) (213.143.5.74) by sources.redhat.com with SMTP; 2 Jul 2003 10:10:34 -0000 Received: from JENPC112 (jenpc112.jennic.com [99.99.98.112]) by jensun147.jennic.com (8.9.3+Sun/8.9.3) with SMTP id LAA24394; Wed, 2 Jul 2003 11:05:13 +0100 (BST) From: "Robert Cragie" To: "Partha Palit" Cc: "ECOS" , "SID" Subject: RE: [ECOS] generating interrupts in ARM-PID (SID simulator) Date: Wed, 02 Jul 2003 10:10:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <20030701205014.61802.qmail@web12908.mail.yahoo.com> Importance: Normal X-SW-Source: 2003-q3/txt/msg00002.txt.bz2 > As recommened by Robert, I tried using the interrupt > 11.It seemed to work, but it showed up as spurious > interrupt which is not handled by the ARM Hal. I guess > this is becuase ARM recognizes level triggered > interrupts as pointed out by Robert. A spurious interrupt is simply one which is not handled by the software interrupt handling mechanism. It is nothing to do with level or edge-triggered interrupts. All processors essentially work on level-triggered interrupts. An edge-triggered interrupt is where an edge is simply latched to assert a level, and then cleared in a defined way to negate a level, usually by writing to some register. So if you are getting a spurious interrupt, you are at least seeing the interrupt, which is progress. Put a breakpoint on hal_IRQ_handler and see what it's doing. I would guess you are not installing the interrupt handler properly or the numbers are not corresponding or something - did you try the sample source code I included? You could also look at the Interrupt Controller registers on the PID simulator to give you a clue as to what's going on, e.g. reading IRQStatus will tell you active interrupts (i.e. where there is an interrupt and it is also enabled) and reading IRQRawStatus will tell you actual interrupts (i.e. where there is an interrupt even if it is disabled) (note I am assuming the SID model matches this exactly): Address Read Write 0x0A000000 IRQStatus Reserved 0x0A000004 IRQRawStatus Reserved 0x0A000008 IRQEnable IRQEnableSet 0x0A00000C Reserved IRQEnableClear 0x0A000010 Reserved IRQSoft(Programmed IRQ Interrupt) 0x0A000100 FIQStatus Reserved 0x0A000104 FIQRawStatus Reserved 0x0A000108 FIQEnable FIQEnableSet 0x0A00010C Reserved FIQEnableClear 0x0A000110 Reserved Reserved 0x0A000114 FIQSource FIQSource Note that these will normally be manipulated by the HAL when interrupts are enabled/disabled/handled etc. and should not be tampered with unless you are specifically trying to debug something. > -->Q: Could anyone kindly tell how to generate pulses > of definite time period using sid-sched? I guess a > timer can be used, but in the SID configuration file I > see that the timers have inputs from the cpu itself. > Is there anything simpler? Over to Frank and the SID guys, where you seem to have got a comprehensive answer. Robert Cragie, Design Engineer _______________________________________________________________ Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK http://www.jennic.com Tel: +44 (0) 114 281 2655 _______________________________________________________________