This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: spurious interrupt occuring for no apparent reason


I have in fact checked to make sure that it is registering it correctly.
It is, that's why it occurs so rarely.  If it wasn't registering
properly, it would occur all the time would it not?

This won't actually affect my end program anyhow will it?  After all,
once Assertions are disabled, my program should run normally as
predicted, no?  If so, maybe this should be changed to a CYG_TRACEX
instead of a CYG_ASSERT?

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[mailto:ecos-discuss-owner@sources.redhat.com] On Behalf Of Dan Conti
Sent: Monday, August 27, 2001 2:19 PM
To: eCos Discussion
Subject: RE: [ECOS] spurious interrupt occuring for no apparent reason


When you get a spurious interrupt, it's because the interrupt is
unmasked on the processor, but you haven't registered a handler for the
interrupt in eCos. If the cs8900 driver is unmasking that interrupt you
might want to make sure that it is properly registering an interrupt
handler first.

Yes, theoretically that should never occur, hence the assertion.

-Dan

> -----Original Message-----
> From: Trenton D. Adams [mailto:tadams@theone.dnsalias.com]
> Sent: Monday, August 27, 2001 11:44 AM
> To: 'eCos Discussion'
> Subject: [ECOS] spurious interrupt occuring for no apparent reason
> 
> 
> I'm running on and edb7111-2 rev b board.  Every once in 
> awhile (once in
> a blue moon), I get a spurious interrupt occuring.
> 
> TRACE: <5>[202]hal_arch_default_isr() Interrupt: 8
> ASSERT FAIL: <5>[204]hal_arch_default_isr() Spurious Interrupt!!!
> 
> My program does not enabled EINT3 (int 8) in any way shape or 
> form.  The
> edb7111-2 ethernet driver for the CS-8900 does enable this interrupt
> though.  But all it appears to do is IGNORE it.  By this I mean simply
> ack it and then re-enable it.  So, this EINT3 problem should
> theoretically never occur, should it?
> 
> Trenton D. Adams
> Extreme Engineering
> #17, 6025 - 12 St. SE
> Calgary, Alberta, Canada
> T2H 2K1
> 
> Phone: 403 640 9494 ext-208
> Fax: 403 640 9599
> 
> http://www.extremeeng.com
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]