Flag for missed interrupt?

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.

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.

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.

Vladimir Vassilevsky DSP and Mixed Signal Consultant

ul

by

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

------------------------------------------------------

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

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.

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.

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.

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 
      .      @       .

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

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

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

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

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

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

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

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

Very true.

Rick

E.g. too many printk in linux kernel.

Leo Havmøller.

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.

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

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