I'm trying to understand how interrupt works but after reading for a long time I'm getting very confused.

Let's say I have a c program and it has a main function and interrupt service routine. As I think the CPU gives control to the main function until the interrupt flag is set. As soon as the interrupt flag is set, cpu gives its control to the interrupt service routine.

I don't understand how the CPU takes control back to a main function where it left control. Why is it that the CPU takes control from where it was left?

 

The same way a function returns control to its caller. Actually, it is a little more complicated since it must save all context information, but generally, it is completely handled in hardware except in the simplest if micros.

 

I'm trying to understand how interrupt works but after reading for a long time I'm getting very confused.

Let's say I have a c program and it has a main function and interrupt service routine. As I think the CPU gives control to the main function until the interrupt flag is set. As soon as the interrupt flag is set, cpu gives its control to the interrupt service routine.

I don't understand how the CPU takes control back to a main function where it left control. Why is it that the CPU takes control from where it was left?

It's not that the CPU takes control back, but rather the ISR gives control back. The details depend on the specific hardware, but between the hardware and the ISR, all information needed to continue executing the program from the point of interruption must be stored somewhere. On some hardware, the CPU takes care of all (or nearly all) of this in response to the interrupt. On other hardware, the CPU saves the minimum, such as the address to return to, and the ISR is responsible for saving any registers or other information that it might mess up. When the ISR is finished, the ISR restores whatever information is it responsible for and then returns from the subroutine. When that return command is executed, the CPU restores the information that it was responsible for, including the instruction address for the next instruction, and program execution continues.

 

The same way a function returns control to its caller. Actually, it is a little more complicated since it must save all context information, but generally, it is completely handled in hardware except in the simplest if micros.

Is my thinking correct that as long as interrupt flag is not set then CPU will execute the source code written in main function and as soon as interrupt flag is set CPU suspend its current activities in main function, and execute a function called interrupt service routine (ISR) to handle the event.

 

No, the main function will generally call other functions, which call still more functions.

 

It's not that the CPU takes control back, but rather the ISR gives control back.

Does it mean that whenever the interrupt flag is set the main function returns control of the CPU to the ISR function and when the interrupt flag is reset the ISR function returns control of the CPU to the main function

 

Is my thinking correct that as long as interrupt flag is not set then CPU will execute the source code written in main function and as soon as interrupt flag is set CPU suspend its current activities in main function, and execute a function called interrupt service routine (ISR) to handle the event.

Usually there is an interrupt flag that gets set due to some condition and a interrupt enable register (bit) that lets the interrupt function execute. If the interrupt enable register for X interrupt is not set then the flag is set but nothing else happens for interurpt code execution. This is useful when you need to software poll the interrupt flag or use the flag as a trigger for some type of hardware module like DMA.

 

No, the main function will generally call other functions, which call still more functions.

I agree but in the current situation, I have taken the example of only two functions, one main function and the other Interrupt service routine function.

 

The processor is executing its main function.
When an interrupt occurs, this is what happens (for an ARM processor):
The processor stores R0, R1, R2, R3, R12, the status register and the current address on the stack and starts executing the interrupt service routine.
When the interrupt service routine finishes (the processor reaches a BX LR or POP {PC} instruction) the processor retrieves R0, R1, R2, R3, R12, the status register and the current address from the stack and starts executing code again from where it left off, as if the interrupt never happened.
In order for this to work properly, registers R4-R11 must remain unchanged at the end of the ISR, so if the ISR needs to use these registers, it must save them on the stack and retrieve them before returning control to the main routine.

 

Basically what everyone else has said is correct. It just needs some clarification.
The CPU is in control all the time. Its job is to execute instructions, one at a time.

Firstly, the hardware
There are multiple HW flags involved.
A device has an interrupt flag which is set when it needs to be serviced. This only happens if the interrupt enable is set for that interrupt flag. In other words the programmer can choose which interrupts to enable and which interrupts never get seen. A single device can have multiple flags each with its corresponding interrupt enable.

On top of that, there is one master interrupt enable flag which is normally off when the program begins execution from power on. This allows the program to start executing any initialization procedures and not be interrupted before it is ready.

Now on to the SW side of things
Let us assume that there is one device that can cause an interrupt. Its interrupt flag is enabled and the master interrupt flag is set. Furthermore, let us assume that the device interrupt handler, ISR (Interrupt Service Routine) is properly written and installed. The starting address of the ISR is placed by the linker into an interrupt vector table where all ISR addresses are located. This table also contains the program start vector that finds where your program begins.

The CPU merrily chugs along executing one instruction at a time. Each instruction may required several steps, e.g. fetch, decode, execute. The CPU has an instruction address register, (IAR), (also called program counter PC), i.e. a hardware register that has the address of the next instruction to be fetched and executed.

An interrupt occurs. This is a HW mechanism that flags the CPU to respond to the interrupt.

The CPU must complete the current instruction. PC contains the address of the next instruction. This must be saved somewhere. In most CPU systems today, the contents of the PC is pushed onto a stack. Furthermore, many CPU systems will push the current contents of important registers on the stack. The master interrupt flag is turned off to prevent further interrupts.

The HW knows which device is requesting service. The CPU goes to the interrupt vector table and fetches the starting address of the ISR. This address is placed into the PC. From here on the CPU continues with code execution as if nothing had happened except it is executing code in the ISR.

One difference is the stack now contains new information. The ISR code can do what it pleases. There is no difference between code written for the main loop or code written for the ISR, except of course the master interrupt is turned off. (Systems that allow interrupt priority schemes will allow an interrupt with higher priority to cause another interrupt, but we will not get into that.)

It is the responsibility of the ISR to make sure that any common resources begin used (e.g. HW registers) are saved and restored before exiting from the ISR if this is not done automatically by the CPU.

Now we come to the end of the ISR and need to get back to where the CPU left off. In a normal end of subroutine an RTS or RET (return from subroutine) instruction is executed. This pulls information off the stack including the return address.
Similarly, an ISR ends with an RTI or RETI (return from interrupt) and this instruction is executed. This does the same thing as RTS or RET and has one additional HW feature. The master interrupt is re-enabled (delayed by one instruction cycle).

In other words, the return address (and all other saved data) is pulled from the stack and pushed into the PC. The CPU resumes execution from where it was interrupted. This is equivalent to a JMP instruction. This instruction must be completed before the master interrupt flag is re-enabled otherwise the correct return address on a pending interrupt would be lost.

Note that the stack gets restored, in other words, the current stack pointer goes back to what it was before the interrupt was called as if nothing had happened.

 

The simplest picture is that an interrupt is the equivalent of a 'call' instruction to invoke a subroutine, except done in hardware and triggered by an event external to the program flow.

 

There is a similar process on the software side for capable processors called traps that are useful for OS functionality. They are 'interrupts' (some processors can make them into interrupts with a trap handler) that happen in a user process exception like divide by zero, breakpoints or trap-to-OS for a privileged system call in an OS or protected memory processor.

 

And, just to confuse you more, an interrupt routine can be interrupted as well. Many processors have different priorities and an interrupt can be interrupted by a higher priority interrupt.

 

And, just to confuse you more, an interrupt routine can be interrupted as well. Many processors have different priorities and an interrupt can be interrupted by a higher priority interrupt.

And for further confusion, depending on the processor, some interrupts can be masked and some can't, but then there might be a mask whose sole purpose is to mask the non-maskable interrupts. Once you learn the rationale behind all of these things, it makes sense. But at first you can definitely spend some time wondering just what the designers were smoking.

 

And, just to confuse you more, an interrupt routine can be interrupted as well. Many processors have different priorities and an interrupt can be interrupted by a higher priority interrupt.

Yes, even on a lowly PIC18 8-bit controller there are High/Low priorities with some advanced models have vectored interrupt addresses that can be assigned separately to each ISR code routine to reduce interrupt latency.
https://ww1.microchip.com/downloads/en/AppNotes/90003162A.pdf

 

You can take a look at this video too: