From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Trenton D. Adams" To: "'Dan Conti'" , "'eCos Discussion'" Subject: RE: [ECOS] spurious interrupt occuring for no apparent reason Date: Mon, 27 Aug 2001 13:28:00 -0000 Message-id: <001c01c12f36$b34e30f0$090110ac@TRENT> References: X-SW-Source: 2001-08/msg00860.html 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 > >