RE: [ECOS] spurious interrupt occuring for no apparent reason

["Trenton D. Adams" <tadams at theone dot dnsalias dot com>]

Something very odd is happening then.  From what I understand, EINT3 has
to occur all the time because I'm sending/receiving data all the time.
So, the fact that I would be receiving an interrupt only rarely is
EXTREMELY unlikely because my program seems to work fine.

This spurious interrupt has only occurred twice in the entire time I've
been using this board.  It seems that it might be a synchronization
problem somewhere within eCos.  Possibility, considering what I've said
so far?

-----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:46 PM
To: eCos Discussion
Subject: RE: [ECOS] spurious interrupt occuring for no apparent reason


> -----Original Message-----
> From: Trenton D. Adams [mailto:tadams@theone.dnsalias.com]
> Subject: RE: [ECOS] 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?

If it was actually registering an interrupt handler for that vector,
then you wouldn't be seeing a message from hal_arch_default_isr() on
that vector. In terms of occurring rarely, it's not like the proper
handler is sometimes registered and sometimes not, so that it occurs
rarely just means you're rarely getting interrupts.
 
> 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?

No, it really should be an assertion. A hardware interrupt is unmasked
but there is no software handler installed for it (hence it hits the
default). Normally if you hit this condition it means you're unmasking
the wrong interrupt, in which case your program probably wont do
anything useful in any case. Additionally, unmasking the wrong interrupt
is generally naughty, hence the assertion. Traceing is useful for
following the path of execution in kernel code, not for checking error
conditions or misconfiguration.

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