# Enable interrupt but no ISR

I would like to know what happens if an Interrupt is enabled(ex:Arbitration Lost Interrupt in CAN module of NXP's LPC1778),but no ISR has been defined for the interrupt.

When such an interrupt occurs,i know that the respective interrupt flag will get set, but since i haven't defined any ISR,there wont be any interrupt vector offset address stored for control transfer for such an interrupt and so the control will pass back to the main routine,and i can reset the interrupt flag by polling it in the main routine (this is what im thinking).Will there be any latency when the CPU is figuring out that there's no ISR to jump to?

Any solutions on what might happen can really help me.

Thanks.

Update:

I enabled CAN Interrupt on my uC,but didnt define an ISR. When I performed an internal loopback test,the code entered into an infinite loop. Here is the disassembly code of the infinite loop being executed on LPC1778:

B       .
ENDP


So ya, if you are using interrupts, use the ISR.

• You don't need to enable the interrupt to be able to poll for flags in your main function. If the condition which sets the flag occurs, that flag will get set whether or not you have enabled the associated interrupt. – brhans Mar 28 '16 at 12:42
• Ur saying that a Bus Arbitration Lost interrupt flag will get set even if i dont enable the "interrupt on Bus Arbitration lost"(though there is no status register that can indicate the Bus Arbitration lost except the Interrupt status register)? – AlphaGoku Mar 28 '16 at 13:07
• Yes. In every MCU I have worked with, the interrupt flags are set whenever the condition which should set them occurs. Enabling the interrupt causes the MCU to vector to the handler when the associated flag is set and disabling the interrupt causes it to ignore the flag and not vector to the handler even though the flag is set. Dis/en-abling the interrupt only affects the jump-to-interrupt-handler behavior, not the flag-setting behavior. – brhans Mar 28 '16 at 13:27
• Wow.Thats something i didnt know. Thanks a lot. So every driver must periodically also check for the interrupt status registers and reset them even though interrupts haven't been enabled :) – AlphaGoku Mar 28 '16 at 13:31
• @AkshayImmanuelD only if it matters. If the interrupt is always disabled, and nothing else cares about the flag, then whether it's set or cleared is immaterial. – hobbs Mar 28 '16 at 20:09

If there is no ISR defined, the location for the jump instruction in the interrupt vector will either be null, it may be a jump to an exception routine, it may jump to the beginning of the program, or it may contain a "return from interrupt" (e.g. RTI) instruction.

Here is a disassembly of an interrupt table for an ATMega 16 processor showing three unused interrupts vectored to a routine which handles such cases (it may just go into an infinite loop), and one legitimate vector.

  28:   0c 94 47 00     jmp 0x8e    ; 0x8e <__bad_interrupt>
2c:   0c 94 5c 00     jmp 0xb8    ; 0xb8 <__vector_11>   // <-- ISR
30:   0c 94 47 00     jmp 0x8e    ; 0x8e <__bad_interrupt>
34:   0c 94 47 00     jmp 0x8e    ; 0x8e <__bad_interrupt>


Which of the methods described earlier of handling a missing ISR will depend both on the architecture of the microcontroller and the compiler. In the case of an RTI or equivalent instruction, it will immediately return to the application. However if the interrupt is level-triggered rather than edge-triggered, then this will probably cause the interrupt to be triggered again, so you end up in an infinite loop.

I think it may depend on the architecture of the chip whether internal interrupts (e.g. a character being received by a UART) is considered level-triggered or edge-triggered. External interrupts can usually be configured as one or the other.

There is also one other case, sometimes several interrupts are grouped together and use the same vector. This was particularly true for older processors which might have had just a couple of interrupts. In that case, the interrupt cause was determined by polling the status of interrupt registers, which is sort of like what you propose.

But it is bad practice in any case to have interrupts in a system and no ISR defined. Don't do it.

• ...., or it can be undefined. – Wouter van Ooijen Mar 28 '16 at 8:53
• @WoutervanOoijen that's what I meant by the interrupt vector being null. – tcrosley Mar 28 '16 at 8:55
• The status registers cannot indicate a few errors like the one i have mentioned above. But such errors do have an interrupt. Hence i thought of enabling the interrupt just to identify the error and not use any ISR. While simulating the LPC1778 using Keil,i didn get any exception so i guess the uC must be using the RTI as u mentioned – AlphaGoku Mar 28 '16 at 9:22
• Something to be aware of - if you enable an interrupt, but your handler doesn't clear the flag (or there is no handler and the default behavior is a simple return) then you 'll most likely find that your MCU will end up forever stuck in an interrupt loop. – brhans Mar 28 '16 at 13:50
• The PIO interrupts on the ATSAM3X8E can be edge-triggered, but the interrupt condition once set won’t be cleared until you read the ISR (interrupt status register) in the interrupt handler - resulting in the loop @brhans mentioned. – Simon Wright Mar 28 '16 at 18:35

It depends on your MCU, compiler and rest of the code.

From my experience:

1. AVR - by default if you do not specify an ISR, then the interrupt vector in flash will be 0x0000, which means that your application will jump into reset whenever this interrupt happens.

If you really need the interrupt, but do not need the handler (eg. use ADC low-noise power-down mode and use the interrupt only to wake up the MCU) you should use the EMPTY_INTERRUPT macro

2. NXP Kinetis (ARM) - all vectors by default point to a default handler that has a breakpoint, the CPU will simply stop and tell it to your debugger.