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]
Other format: [Raw text]

Re: spurious interrupts on scanf


hi!

there is no source, that is the problem...
at the moment the interrupt occures (the bad one) there is zero read out of the interrupt register....
thats why I thought, there is an interrupt but disappears when it is read out (because there is some latency on the bus -> DMA)



level triggered interrupts... that's it! mine are level triggered but the uart, i don't now... i will have to check...
thanks a lot



christian müller


Andrew Lunn wrote:

On Wed, Oct 13, 2004 at 09:22:15PM +0200, Christian Mueller wrote:


Hello again,

thanks a lot for quick answer...
You were right, it was not the scanf...
But some interesting thing, someone might find quite odd...
I will describe it a little bit longer, so everyone gets me right.
I am doing DMA (it is a VGA output of a picture I've got in memory), it fetches 300kb 60 times a second into a fifo.
working fine.
If I have it disabled, no spurious interrups occour, but if it is running, I get them quite often (I have written an IRQ handler that works on an
additional IRQ, firering when there can no interrupt source be identified.
Note: there is no hardware interrupt from me! Nothing from the PLD or so ...
I am not quite sure, but this is a scenario I could imagine:
The UART interrupts (the only ones unmasked that could be responsible) are self-resetting, so if there is much traffic on the bus,
the processor might miss them....
anything for my understanding to add?
For practical use I will keep the IRD handler (empty) so nothing will bother me, but it leaves some ungood feeling...



Spurious interrupts can be of two types:


1) There is an interrupt, but when you check the interrupt controller
  there is no active source.

2) There is an interrupt and the controller knows the source, but no
  interrupt handler has been registered with eCos for that source.

2) is much easier to get a handle on. Take a look at
hal_arch_default_isr and see what the vector is. See if you can track
this back to the interrupt controller and find the source.


If this leads you nowhere you then need to check your level triggered
interrupts.

Andrew





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


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