Flag for missed interrupt?

[Vladimir Vassilevsky]

While developing embedded systems, many times I thought it would be useful
to have an additional flag for every interrupt. This flag should be set by
hardware if interrupt request was set again before the interrupt was
serviced; i.e. an event is missed.
Do you know of any CPU or interrupt controller that already has this
functionality?

Vladimir Vassilevsky
DSP and Mixed Signal Consultant
www.abvolt.com

[Robert Wessel]

On Sat, 20 Oct 2012 10:39:22 -0500, "Vladimir Vassilevsky"
<nos...@nowhere.com> wrote:

>While developing embedded systems, many times I thought it would be useful
>to have an additional flag for every interrupt. This flag should be set by
>hardware if interrupt request was set again before the interrupt was
>serviced; i.e. an event is missed.
>Do you know of any CPU or interrupt controller that already has this
>functionality?

What if you miss two interrupts?

And most devices keep their status anyway - if two interrupt-worthy
events occur, they both remain pending at the device, even if only one
interrupt is signaled to the CPU. And it seems like fixing the
hardware to not lose status or the interrupt handlers to not lose
interrupts would be a better solution in any event.

[Vladimir Vassilevsky]

"Robert Wessel" <robert...@yahoo.com> wrote in message
news:7oh5881ukb9njhrn9...@4ax.com...

> On Sat, 20 Oct 2012 10:39:22 -0500, "Vladimir Vassilevsky"
> <nos...@nowhere.com> wrote:
>
>>While developing embedded systems, many times I thought it would be useful
>>to have an additional flag for every interrupt. This flag should be set by
>>hardware if interrupt request was set again before the interrupt was
>>serviced; i.e. an event is missed.
>>Do you know of any CPU or interrupt controller that already has this
>>functionality?
>
> What if you miss two interrupts?

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.

> And most devices keep their status anyway - if two interrupt-worthy
> events occur, they both remain pending at the device, even if only one
> interrupt is signaled to the CPU. And it seems like fixing the
> hardware to not lose status or the interrupt handlers to not lose
> interrupts would be a better solution in any event.

Before fixing the problem one needs to know that the problem exists. It is
no trivial task to verify that every interrupt gets serviced on time in
every possible scennario. Additional flags would resolve that.

[dp]

If he misses two or more he will know one or more events have been
missed, this can be useful in certain situations.
But this is the job of the peripheral - to know it has not been served
in time, the CPU needs only access to a bit which says so (many if not
most peripherals I know actually do so).
Since the "normal" way for the IRQ lines to the CPU is to be wire-
ORable
there simply is nothing like missing an interrupt, one can be just too
late to serve it. Which, again, is up to the peripheral to be detected
and noted.

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[hamilton]

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

[upsid...@downunder.com]

On Sat, 20 Oct 2012 10:49:44 -0500, Robert Wessel
<robert...@yahoo.com> wrote:

>On Sat, 20 Oct 2012 10:39:22 -0500, "Vladimir Vassilevsky"
><nos...@nowhere.com> wrote:
>
>>While developing embedded systems, many times I thought it would be useful
>>to have an additional flag for every interrupt. This flag should be set by
>>hardware if interrupt request was set again before the interrupt was
>>serviced; i.e. an event is missed.
>>Do you know of any CPU or interrupt controller that already has this
>>functionality?

Why would the interrupt be missed in the first place ?

Are you trying to figure out if two or more interrupts occur, while
your interrupt handler for some other interrupt is still running ?

In that case, I really suggest rethinking your architecture and
minimize the time spent in some specific interrupt service routine.

[Frank Miles]

Two workarounds:
1- If the original interrupt is caused by a logic level transition, you
might be able to feed the signal to a counter, and check that the count
value at the end of the interrupt processing hadn't increased beyond what
it was at the start. This might be aided in some processors by a
hardware mediated count save, ideally one that had an explicit enable
mechanism.

2- If the problem were associated with an interrupt handler that took too
long - chain two interrupts together, with a fast high priority handler
that simply counted once, then chained to the handler that did the real
work IF it wasn't already in process. A new event during the second/
chained interrupt handler would cause the higher priority counter to tick
once more. Obviously this requires a processor capable of interrupting
an interrupt handler.

Clearly the first method has a shorter interval where it can't detect
multiple interrupting events, but you haven't been very explicit about
the nature of your events nor their processing.

[Niklas Holsti]

On 12-10-20 18:39 , Vladimir Vassilevsky wrote:
> While developing embedded systems, many times I thought it would be useful
> to have an additional flag for every interrupt. This flag should be set by
> hardware if interrupt request was set again before the interrupt was
> serviced; i.e. an event is missed.

I agree that this ability would often be useful.

But sometimes what is wanted is an "interrupt handling time expired"
flag that is set if the interrupt has not been handled in time, even if
there is not yet a new interrupt request. Some interrupts should be
handled in a time shorter than the interrupt interval.

> Do you know of any CPU or interrupt controller that already has this
> functionality?

Only (as others have replied) through some error flag that is raised in
the peripheral itself, for example an "overrun" in a serial input line.

Perhaps one reason for the absence of this feature is that many
peripherals are unable to generate a new interrupt request before the
earlier interrupt request has been handled and cleared. Implementing
this "missed interrupt" feature only in the CPU or in the interrupt
controller would therefore not catch all problems with delayed interrupt
handling. Rather, it should be implemented (also) in the HW that
generates the interrupt request. And indeed there already exist such
"interrupt not handled in time" flags, but only in some peripherals and
implemented in different ways.

Ideally, as you suggest, this should be a feature of the "interrupt
system" of the processor, which means that all peripherals should supply
not only an interrupt-request signal but also an "interrupt handling
time expired" signal.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

[rickman]

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.

I would expect this to be in the I/O device rather than in the interrupt
structure of a CPU. But then he may be talking about an MCU with
internal I/O devices where all of it is on chip.

Rick

[rickman]

On 10/20/2012 4:20 PM, upsid...@downunder.com wrote:
> On Sat, 20 Oct 2012 10:49:44 -0500, Robert Wessel
> <robert...@yahoo.com> wrote:
>
>> On Sat, 20 Oct 2012 10:39:22 -0500, "Vladimir Vassilevsky"
>> <nos...@nowhere.com> wrote:
>>
>>> While developing embedded systems, many times I thought it would be useful
>>> to have an additional flag for every interrupt. This flag should be set by
>>> hardware if interrupt request was set again before the interrupt was
>>> serviced; i.e. an event is missed.
>>> Do you know of any CPU or interrupt controller that already has this
>>> functionality?
>
> Why would the interrupt be missed in the first place ?

He is talking about fixing a problem. If he knew why it was happening
he wouldn't be asking about this here. An interrupt overflow flag is a
useful debugging feature.

Rick

[hamilton]

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.

[rickman]

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

[hamilton]

On 10/20/2012 5:17 PM, rickman wrote:

> He is asking why there is not the debug capability that lets he
> know for sure that this is the problem he is seeing!
>

Hmmm, A software guy asking the hardware people why their processors are
not good enough.

We both know its a software problem.

OK, I have used IO pins and a logic analyzer to troubleshoot problems
like this.

But asking the hardware people to add cost that can be resolved with
software.......

I still don't get it, but that's OK.


hamilton

[rickman]

How would you resolve this with software? If the software is screwing
up and not responding to an interrupt in time, how would you use
software to detect that? Maybe we don't have all the details. If this
I/O device has no capability to buffer data, I would expect a slow
interrupt response to lose data in a hard to detect way.

I guess I don't see that as "adding cost" but rather a value added
feature. Aren't debugging features pretty common? Heck, I understand
there are tons of registers in desktop processors just to assist in
tweaking performance. If I were designing the hardware for this, as
long as it was in a chip being designed or in an FPGA, I would give him
this feature with no push back. If it meant adding chips to a board,
well then I would come back into the 21st century and put the PLD on the
board to begin with.

Rick

[hamilton]

On 10/20/2012 6:07 PM, rickman wrote:
> On 10/20/2012 7:40 PM, hamilton wrote:
>> On 10/20/2012 5:17 PM, rickman wrote:
>>
>>> He is asking why there is not the debug capability that lets he
>>> know for sure that this is the problem he is seeing!
>>>
>>
>> Hmmm, A software guy asking the hardware people why their processors are
>> not good enough.
>>
>> We both know its a software problem.
>>
>> OK, I have used IO pins and a logic analyzer to troubleshoot problems
>> like this.
>>
>> But asking the hardware people to add cost that can be resolved with
>> software.......
>>
>> I still don't get it, but that's OK.
>
> How would you resolve this with software? If the software is screwing
> up and not responding to an interrupt in time, how would you use
> software to detect that?

> Maybe we don't have all the details.

OK, I'm glad we agree on this issue.

> If this
> I/O device has no capability to buffer data, I would expect a slow
> interrupt response to lose data in a hard to detect way.
>
> I guess I don't see that as "adding cost" but rather a value added
> feature.

LOL, that's a nice way of stating it !

> Aren't debugging features pretty common? Heck, I understand
> there are tons of registers in desktop processors just to assist in
> tweaking performance. If I were designing the hardware for this, as
> long as it was in a chip being designed or in an FPGA, I would give him
> this feature with no push back. If it meant adding chips to a board,
> well then I would come back into the 21st century and put the PLD on the
> board to begin with.

A two channel storage scope would be enough for most troubleshooting
problems.

But, a full blown OS based system may require a larger logic analyzer.

As is the usual answer, "it depends"

H

>
> Rick

[rickman]

Very true.

Rick

[Leo Havmøller]

> Why would the interrupt be missed in the first place ?

E.g. too many printk in linux kernel.

Leo Havmøller.

[Niklas Holsti]

It is similar to overflow and carry flags -- these are hardware features
that provide functions that could be "resolved" with software, but which
are much more effective in hardware. An even better analog is a trap for
division by zero, or for other arithmetic errors.

Processor designers provide hardware to detect and react to such
arithmetic errors; why not provide hardware also to react to timing
errors, or at least to make them easier to detect by software?

The hardware for an "interrupt not handled in time" flag in the
CPU/interrupt controller is about as complex as a carry flag. The
implementation on the peripheral side needs a little more logic, but not
much.

[Bill Leary]

"Vladimir Vassilevsky" wrote in message
news:M7qdnUwSuZA5WB_N...@giganews.com...

> While developing embedded systems, many times
> I thought it would be useful to have an additional
> flag for every interrupt. This flag should be set by
> hardware if interrupt request was set again before
> the interrupt was serviced; i.e. an event is missed.
> Do you know of any CPU or interrupt controller that
> already has this functionality?

I remember seeing this on one of the old ('80's era) minicomputers. The
machine used edge, rather than level, triggered interrupts. If a second
edge was seen before the pending interrupt was handled an interrupt overrun
flag was turned on.

From later messages it seems you're trying to debug a possible interrupt
overrun. These things are very dependent on the setup, so it's difficult to
give suggestions. But I'm going to anyway. :)

Maybe this will give you an idea you can apply to your situation.

Note that all I was trying to do was prove it was overrunning. Fixing the
problem, if it was there, would come later.

On interrupt handler entry interrupts were disabled by hardware. And the
interrupting device was constructed such that I could be sure I would not
get another interrupt for a certain number of microseconds. This number of
microseconds, in theory, being long enough that the overall interrupt
handler should never have overrun. I set up a global variable initialized
it to zero on reset. On handler entry, the global variable was examined.
If it was non-zero, an LED was lit and the machine put into a dead loop.
If it was zero, it was incremented, interrupts enabled, and the handler
proceeded normally. Note that originally, interrupts were disabled for the
duration of the handler. When the handler exits, interrupts are disabled,
the global variable decremented, interrupts enabled, and the handler exits.

The handler had a number of paths it could take depending on the data it
retrieved. It was believed, incorrectly, that the data it was possible to
get would never cause execution of more than two of these paths. It turned
out that there were cases where it would actually execute pretty much all of
them. This was due to a documentation error. Some bits, which triggered
some paths, rather than being zero, as the documentation claimed, were
actually intended to be ignored when other bits were or were not set.
Fixing the documentation, and adjusting the code to match, eliminated the
overrun.

- Bill