Received: by 10.180.107.167 with SMTP id hd7mr1348457wib.0.1351391094586;
        Sat, 27 Oct 2012 19:24:54 -0700 (PDT)
Path: q13ni70614wii.0!nntp.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.85.MISMATCH!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!news.panservice.it!feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: rickman <gnu...@gmail.com>
Newsgroups: comp.arch.embedded
Subject: Re: Flag for missed interrupt?
Date: Sat, 20 Oct 2012 19:17:34 -0400
Organization: A noiseless patient Spider
Lines: 78
Message-ID: <k5vbep$dlq$1@dont-email.me>
References: <M7qdnUwSuZA5WB_NnZ2dnUVZ5uSdnZ2d@giganews.com> <7oh5881ukb9njhrn9gdtgoggm0cdu9960v@4ax.com> <y_ydncaxJO1ZUB_NnZ2dnUVZ5t2dnZ2d@giganews.com> <k5uus2$ge$1@dont-email.me> <k5v8gs$p2v$1@dont-email.me> <k5vas5$5jt$1@dont-email.me>
Mime-Version: 1.0
Injection-Date: Sat, 20 Oct 2012 23:17:45 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="575a8d3a503cd2ab981bf514a483fac2";
	logging-data="14010"; mail-complaints-to="ab...@eternal-september.org";	posting-account="U2FsdGVkX1/nXf3tf896XknZzSWueyRn"
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
In-Reply-To: <k5vas5$5jt$1@dont-email.me>
Cancel-Lock: sha1:no6Aae0olR/P4UkiaqqLIAiujLU=
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 10/20/2012 7:07 PM, hamilton wrote:
> On 10/20/2012 4:27 PM, rickman wrote:
>> On 10/20/2012 3:42 PM, hamilton wrote:
>>> On 10/20/2012 10:13 AM, Vladimir Vassilevsky wrote:
>>>>
>>>> I need to know the fact that particular interrupt request was missed at
>>>> least once. Knowing how many times this request was missed is less
>>>> important.
>>>
>>> I for one is a little confused about this statement.
>>>
>>> If the interrupt service routine is the only place the interrupt flag is
>>> cleared, then how can you not see the flag elsewhere ?
>>>
>>> If an interrupt flag can be cleared in two places, there is a bigger
>>> problem.
>>>
>>> Looking at interrupt bits should not clear them.
>>>
>>> Maybe a little better description is in order.
>>>
>>> I am also assuming that these are hardware interrupts.
>>>
>>> hamilton
>>
>> He is talking about an interrupt overrun error flag. If an interrupt if
>> not serviced before the interrupt is set again, data may have been lost.
>> Like an ADC conversion with no FIFO, etc. UARTs typically have this
>> sort of flag.
>
> Yes, this is not the problem.
>
> A lost hardware interrupt is because the code is way too busy to get
> back to it.
>
> If the software turns off the Global Interrupt for insistence and does
> not turn it back on in time, it can lose interrupts.
>
> This is not the interrupting devices fault.
>
> If the Global Interrupt flag is ON, then interrupts will flow.
>
> Maybe the processor is too small, not fast enough, or there are too many
> interrupts going on for that processor technology.
>
> Maybe one of the interrupt service routines is doing to much or is not
> fast enough to get the Global Interrupt turned back on.
>
>
> Bottom line, this is a software problem !
>
> Back to my question, what else is going on with this processor ??
>
> hamilton
>
> PS: Yes, I know about Overrun flags on UARTs. Slow down the Baud Rate
> fixes that.

You aren't getting what the OP is asking.  He is not asking about the 
cause of the problem.  He is very capable of figuring that out on his 
own.  He is asking why there is not the debug capability that lets he 
know for sure that this is the problem he is seeing!

He is debugging a problem and suspects an interrupt overrun, but is not 
certain.  So he would like an error flag that would tell him this is so.

I don't know anything about his setup, but using a couple of I/O lines 
might let him scope the problem.  One I/O line would be connected to the 
interrupt via hardware if possible (some MCUs will let you bring this 
signal out) and the other I/O line will be toggled in the interrupt 
routine.  If you see the former set without the latter toggling then you 
know you missed an interrupt.  But then I do FPGAs a lot more often than 
MCUs; this is an easy thing to do in an FPGA.  I'm not sure how many 
MCUs will let you bring the interrupt signal out to a pin.  But then the 
interrupt may be from an external device in which case he would be in 
fat city.

Rick