Masking/Disabling/Missing interrupts

I know this is implementation specific but to make it a little less ambiguous let's deal with an XScale or any ARM core for that matter. Under what conditions would you _miss_ interrupts? Let's say I have a UART that only generates one interrupt to the interrupt controller but the source of this interrupt within the UART can be due to various reasons. For example, maybe there is a FIFO overflow or maybe there is some sort of error condition, etc which each can cause the one interrupt line to the interrupt controller to be asserted.

1)First, if interrupts are disabled in the UART and some condition that can generate an interrupt arises, such as an empty FIFO, and I then enable interrupts in the UART sometime later, will an interrupt be generated then at this time if the FIFO is still empty?

2) If the FIFO overflows and I get an interrupt and I am in the interrupt service routine, and interrupts are globally disabled by the processor, if while I am in the ISR another condition in the UART causes an interrupt, will this cause me to reenter the ISR once I return after servicing the FIFO overflow? Does this have anything to do with where in the ISR I clear the status flag in the UART register that indicates a FIFO overflow, i.e. clearing at the start of the ISR or right before I return? I have always heard to clear the flag at the start of the ISR, but I am not sure the exact reason.

3) With regards to missing interrupts, would this only happen if for example I have a timer set to interrupt me every 1 ms but I am in an ISR for a UART, for example, that takes longer than 1 ms to execute?

Thanks.

Reply to
joshc
Loading thread data ...

Maybe. It depends on how the UART is designed, both types exist.

Maybe. It depends on the details of your ISR and to some extent on the hardware.

Yes, Certainly. If you clear the interrupt flag after new interrupts have arrived they may be lost. Which is the reason some peripherals with multiple interrupt sources have methods for clearing them individually rather than as a whole. Having said that, I only have vague recollections of systems using the latter method. It's quite possible my recollection is flawed.

That's generally recommended so that if another interrupt source occurs while you are servicing the one you are dealing with it will be flagged.

How about another maybe :)

It will depend on on whether the timer interrupt has to be reloaded, in which case you won't lose the interrupt just time. More properly to your question if you recieve multiple interrupts of the same source before you service them you will generally only see the one unless you have some sort of queueing mechanism in the peripheral.

Robert

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Robert Adsett

Thanks for the reply. The "maybes" are frustrating because I have worked with various different processor architectures (PowerPC, ARM, various 16/8-bit architectures), but I have yet to see any of the reference manuals for the processors mention anything about losing interrupts if the interrupt flag is not cleared or whether or not they queue interrupts.

Reply to
joshc

Hmm, I've never had much problem determing that from the documentation. Sometimes it's not more than a sentence but it's there. As a general rule, if it doesn't mention some sort of queueing of the interrupt source it's not done. It's not a common item.

Determining whether an interrupt will be lost usually is a matter of judging side effect of status reading and acknowledgement operations and watching for race conditions. The interrupt flag and status bits are generally quite simple logic, there is usually no method of indicating multiple occurences so if more than one occurs you will only see the one. It gets more complicated with FIFOs and multiple interrupt source peripherals but the documentation will be in the peripherals as to how they behave. Sometimes all you get is a simple flag and a simple acknowledge that acknowledges all outstanding interrupt sources leaving it up to the user to check all possibile sources. Sometimes you have separate acknowledge flags for each source in a peripheral and the interrupt will remain active as long as one unacknowledged source remains.

Also there is the question of edge sensitive vs level sensitive interrupts. Internal peripherla to interrupt controller interrupt lines are usually but not always level sensitive. If they are edge sensitive then if the interrupt flag is set you won't get any more interrupts until it is cleared which can lead to missed interrupts if you are nor careful to check, and in some cases re-check, anything that can set the interrupt before leaving an ISR.

What you won't see is a single blanket statement covering all cases, simply because some of the behaviour resets with the peripherals and some with the interrupt controller.

Further complicating matters in the case of the ARM family is that there are multiple types of interrupt controllers used. And you may have to acknowledge/clear the interrupt not only in the peripheral but in the interrupt controller as well.

There's also the question of nested interrupts. In most cases you do not want to re-enable interrupts until you've cleared/acknowledged the current interrupt. I hope the reasons are obvious.

Robert

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Robert Adsett

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.