[ECOS] spurious interrupts

[ECOS] spurious interrupts

[Daniel Schmidt]

Hello all, 
 
I reveice spurious interrupts when using my custom hardware (pxa255, 64MB 
ram,16MB flash). 
 
I've ported the arm/xscale/mpc50 to work with my board. The Board is 
working fine, when using my own vector.S without ecos; I've also done 
memchecking, every think seams to be working properly. 
 
the following configuration is not working ( ecosconfig new myboard 
kernel ): 
	ecos HAL -> HAL interrupt handling -> Use separate stack for 
interrupts = ON 
	Infrastructure -> Asserts & Tracing = ON 
 
everythink seams to be right, when UseSeparateStackForInterrupts=OFF 
 
any suggestions? 
 
Thanks  
Daniel 
 

-- 
+++ GMX DSL-Tarife 3 Monate gratis* +++ Nur bis 25.7.2004 +++
Bis 24.000 MB oder 300 Freistunden inkl. http://www.gmx.net/de/go/dsl


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] spurious interrupts

[Nick Garnett]

"Daniel Schmidt" <Daniel.Schmidt3@gmx.de> writes:

> Hello all, 
>  
> I reveice spurious interrupts when using my custom hardware (pxa255, 64MB 
> ram,16MB flash). 
>  
> I've ported the arm/xscale/mpc50 to work with my board. The Board is 
> working fine, when using my own vector.S without ecos; I've also done 
> memchecking, every think seams to be working properly. 
>  
> the following configuration is not working ( ecosconfig new myboard 
> kernel ): 
> 	ecos HAL -> HAL interrupt handling -> Use separate stack for 
> interrupts = ON 
> 	Infrastructure -> Asserts & Tracing = ON 
>  
> everythink seams to be right, when UseSeparateStackForInterrupts=OFF 
>  
> any suggestions? 

Those options should not effect whether a particular device is
generating unexpected interrupts. The first thing you need to do is
work out where these spurious interrupts are coming from by inspecting
the interrupt controller.

And why have you got your own vector.S? This file is generic to all
ARMs, it should never need changing. If you have been messing around
with the code in this file then you are on your own, there's nothing
we can do to help you.

-- 
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

Re: [ECOS] spurious interrupts

[Daniel Schmidt]

Hello Nick, 
  
> And why have you got your own vector.S? This file is generic to all 
> ARMs 
For my first starts; I wrote a standalong application (without ecos), 
there I used my own vector.S; and of course I did no changes in ecos 
vector.S. 
 
> Those options should not effect whether a particular device is 
> generating unexpected interrupts. The first thing you need to do is 
> work out where these spurious interrupts are coming from by inspecting 
> the interrupt controller. 
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.  
 
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. 
 
Thanks 
Daniel 

-- 
+++ GMX DSL-Tarife 3 Monate gratis* +++ Nur bis 25.7.2004 +++
Bis 24.000 MB oder 300 Freistunden inkl. http://www.gmx.net/de/go/dsl


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] spurious interrupts

[Nick Garnett]

"Daniel Schmidt" <Daniel.Schmidt3@gmx.de> 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