Handling multiple interrupts in a design

[biju4u90]

Hi,
Usually, an interrupt is generated by the hardware in a design and the processor reads the interrupt when a negative edge is detected at the interrupt line (assuming active low interrupt line). After the firmware reads the interrupt line and execute the ISR, it will clear the interrupt status register so that the interrupt line becomes '1' again.
Suppose I am having a system that has an active low interrupt line and multiple interrupts, say 10 interrupts. When any of these 10 interrupts is generated, the interrupt line goes low. Firmware executes the ISR and read the interrupt status register to know which interrupt among the 10 has occured. Assume that the hardware generates an interrupt and the interrupt line is low and firmware begins servicing the interrupt. Before the firmware completes servicing this interrupt, suppose a new interrupt is generated by the hardware. Since servicing the previous interrupt is not complete, the interrupt line will still be low. Since the system detects interrupt only when a negative edge is detected in the interrupt line, the new interrupt will be missed. How does a system handle this situation?

 

[KlausST]

Hi,

the usual way is that the incoming interrupts are latched idividually.
The ISR just RESETs the one interrupt_flag for the according job.

Use level triggered interrupt on microcontroller input, all latched interrupts (sources) should be NOR-ed to the common interrupt line to the microcontroller.

Keep in mind: The ISR should be as short as possible in time. Often it is useful to just safe all involved data and set a flag. Then the processing could be doen in main loop while other interrupts could be processed.

Klaus

 

[std_match]

This is the danger with combined interrupts going to an edge-sensitive interrupt line.
The interrupt routine must be a loop where all interrupt sources are checked/polled/handled.
When the complete loop has executed once without finding an interrupt, it is safe to exit the interrupt routine.

my_isr(){
  do{
    interrupt_found = 0;

    // check all interrupt sources and set interrupt_found = 1 if an interrupt is found and processed

  }while(interrupt_found);
}

 

[FvM]

The question is somehow hypothetical without referring to an actual processor family and interrupt controller hardware.

Short answer, the problem can be well solved for any processor platform and has been solved by designers a thousand times.

 

[c_mitra]

Since the system detects interrupt only when a negative edge is detected in the interrupt line, the new interrupt will be missed. How does a system handle this situation?

What actually happens during an interrupt?

1. The interrupt is acknowledged.

2. Hardware interrupt is disabled.

3. Interrupt source is queried.

4. Interrupt service routine is entered

5. Hardware interrupt is enabled.

6. Hardware lines are pulse driven; enable and disable interrupts are software driven.

7. Interrupts are assigned priorities; a high priority interrupt (while doing the ISR) cannot be interrupted by a low priority interrupt.

8. Interrupt is not serviced unless the interrupt is acknowledged; you can keep on interrupting. (till you get an acknowledgement)

9. Your ISRs are expected to be short.

10. Usually the timer interrupt has highest priority.

 

[std_match]

There is some confusion in this thread. The questions seems to be about several interrupt sources gated together, and then connected to a single edge-triggered interrupt input on the processor.
In this situation the interrupt routine must make sure that all interrupt sources have been inactive simultaneously before exiting. See post #3.
Otherwise there will never be an edge on the interrupt line again, and the interrupt routine will never be called again.

If the interrupt routine is correct, it is OK if the interrupt is active again before the routine exits. A new edge has then been registered, and the interrupt routine will be called again immediately.

 

[FvM]

I don't see a reason why one would use edge triggered interrupt in this situation. But as said, the question should be discussed referring to specific hardware.

 

[c_mitra]

Some clarifications:

If you expect one interrupt coming while another being serviced, you need to nest the interrupts and assign priorities.

Only a small part of this can be done within the microprocessor: e.g., timer interrupts are given high priority always. On the PC, there is one external interrupt controller chip (I am not sure about the newer models) that perform this nesting and assign priorities.

If you simply gate several interrupt sources, you will not be able to identify the source and hence will not be able to decide whether to service it or not.

You will also need to know which ISR will respond in any given interrupt.

However, this is very much hardware dependent.

 

[KlausST]

Hi,

If you simply gate several interrupt sources, you will not be able to identify the source

I think it should be clear that one need to read/know the source of the interrupt. Otherwise you can't run the corresponding code.
But it's not necessary to run nested. Often one may process them one after the other.
Often I run only the most urgent commands in interrupt context .... and the rest in main loop.
... one of many possible solutions...

Klaus

 

[Aussie Susan]

e.g., timer interrupts are given high priority always.

Not always - it depends on the MCU. For example, Microchip PIC18 and lower families have one and perhaps 2 interrupt levels. Where there is a single interrupt, then all interrupt sources have the same 'priority'. When you have 2 levels, then you can assign each interrupt source a priority which means the timer can be assigned a low priority of you want it to be that way.
Without knowing the actual device the OP is considering then this whole discussion is somewhat moot.
Susan

 

[biju4u90]

Hi all,
Thank you all for the responses.

This was not a hypothetical question and the question was based on a bluetooth system I work on. I don't know which microprocessor family is being used in the system, but the ISR is executed based on negative edge of the interrupt line.

In our scenario, multiple interrupts can come together or in close proximity so that new interrupt will be generated when the FW is in middle of the ISR. We handle the scenario as follows:
1. The system has an interrupt mask register which FW can write into it. Only those interrupts that are unmasked will be reported to the FW by the HW.
2. Whenever HW generates an interrupt, before begin the ISR, FW masks all the interrupts by writing into the interrupt mask register. This will prevent reporting new interrupts when FW is in between the ISR.
3. FW will enter the ISR, read the interrupt status register to know which interrupt was occured, services the interrupt and clear the corresponding bit in the interrupt status register.
4. The interrupts are unmasked by writing into the interrupt mask register.

The above steps solve the problem of missing edges in the main interrupt line if new interrupt is generated during ISR execution. But this will create a new problem that, the interrupts generated during the execution of ISR will be missed.
To solve this issue, HW will hold the new interrupts by registering them. The generated interrupts will pull the main interrupt line low only when the interrupt mask register unmasks the interrupt. In short, HW will inform the occurrence of new interrupt only after FW exits the ISR. Since ISR execution takes small time and delaying of interrupts for such small time is not an issue in our system, this solution works perfectly fine.

 

[Aussie Susan]

Question: how can you write code for a microprocessor when you don't know what it is?
Regardless, one thing you could do in the ISR is along the lines of the following pseudo-code:

while(interrupt is set)
{
    clear interrupt;  // Do this right at the start
    process interrupt;
    // Allow for the fact that the interrupt could have been re-triggered by looping back...
}

In other words, stay within the ISR while there is a trigger. The only time you will miss a trigger is if the processing of the interrupt takes long enough for 2 triggers to occur.
Susan

 

[KlausST]

Hi,

Masking out interrupts enables the system to miss interrupts, thus you should not do this.

As already explained, keep the ISR as small as possible, just safe the data and do the processing outside the ISR to enable new interrupts to be detected.

No need to miss interrupts, if you do it right...only if the same interrupt (source) is raised within a couple of microseconds....

Klaus

 

[Aussie Susan]

(addendum to Post #12)
Please don't take my comment about the use of the 'while' statement as being counter to the need to make the ISR short as Klaus states. The 'process interrupt' might need to capture some state information for later processing (pointer into a buffer of a starting position or whatever) but that is all.
Susan

 

[biju4u90]

Question: how can you write code for a microprocessor when you don't know what it is?

I am a hardware engineer (RTL design) and I don't write microprocessor codes. Yea, I should be knowing what microprocessor is being used in my system. But to design RTL, knowledge on the microprocessor family is not a mandatory infomation.

- - - Updated - - -

Regardless, one thing you could do in the ISR is along the lines of the following pseudo-code:

while(interrupt is set)
{
    clear interrupt;  // Do this right at the start
    process interrupt;
    // Allow for the fact that the interrupt could have been re-triggered by looping back...
}

Yes, you are correct on this. I contacted the FW team. When an interrupt is received, FW copies and clear the interrupt. Then only the interrupt processing is done. But as I mentioned before, FW masks all interrupts as the first step when an interrupt is received. This ensures that new interrupt reception does not happen before the main interrupt line is set back high.

- - - Updated - - -

Masking out interrupts enables the system to miss interrupts, thus you should not do this.

HW delays the interrupts that are generated when the mask is enabled. Mask is released when the current interrupt is being served and thus avoids missing of interrupts.

 

[KlausST]

Hi,

This ensures that new interrupt reception does not happen before the main interrupt line is set back high.

But this exactly I see as the problem.
If it's masked out you don't recognize the interrupt, thus you may miss it.

Just safe the state of the interrupt latches and then clear them...this takes only a couple of instructions and after that you are able to recognize the next interrupt.

Fir sure there is a timing limit. You can't detect two interrupt pulses of the same source within a couple of instructions (before you are able to clear the latch).
But you may be able to detect (let's say) 4 pulses of the same interrupt within 100us ... while the processing takes 1ms each.
This will work for a limited count of interrupts, thus I said "4" ... It doesn't mean you can process interrups continously raised every 25us.

Klaus

 

[c_mitra]

If it's masked out you don't recognize the interrupt, thus you may miss it.

Many modern microprocessors today provide a NMI that can be often used for system interrupts that must always be serviced: hardware faults, power brown out etc etc.

For more routine interrupts (e.g., external devices), you raise the interrupt and then wait for the int acknowledge response. If you do not get the intA response in some time, you can again issue the same interrupt. Once you receive the INTA signal, you send some identification over the data bus. This information will determine the ISR to be used for the particular interrupt.

As usual, these extra work does take some time and during this time another interrupt cannot be (and must not be serviced) and interrupts are hardware disabled. It is the duty of the programmer to enable the interrupt in software once the ISR has been properly serviced.

Non-maskable interrupts are a different beast altogether.