Is there a simple way of determining which module causes an interrupt on an ATmega169PA? I have 3,000 units executing the same code and there were 10 units that executed my ISR(BADISR_vect) handler causing these units to stop and display a bad interrupt error code. I'm trying to figure out which interrupt vector is being used or which module is generating the bad interrupt. I disabled the modules by writing a "1" in it's corresponding bit in the PRR except for the LCD, UART and Timer2. Both UART and Timer 2 have their own interrupt handlers and the LCD's interrupt enable bit is "0". The other module's interrupt enable bit is "0" by default. Is it possible that a disabled module can generate an interrupt?
Atmega169PA interrupt source
atmegaavrinterrupts
Related Solutions
In general, the distribution of CPU time between ISR code and non-ISR code is very application-dependent.
If most of the work is being done in non-ISR code, then yes, you generally want to keep the ISRs as short as possible (but no shorter, to paraphrase a famous quote).
However, I have seen (and built) hard real-time DSP applications in which 90% of the work is done in the ISR, and the non-ISR code is only handling tasks that are not time-critical such as configuration, status and user interface.
Either approach is perfectly valid in deeply-embedded systems.
Since you have not assigned NVIC priority group, it is left with a default value of 2. This means that you have 2 bits for preemption priority and 2 bits for sub-priority. That allows you to use priority levels from 0 to 3 (2^n). Allowed priority levels for each group are illustrated in the following table:
As you can see, Group 4 has to be used in order to set preemption priority levels 0-15.
You may leave the group unassigned for UART interrupt (since it will be assigned to group 2 by default).
For more information and examples you can refer to this article.
Related Topic
- Electronic – PIC24F UART Rx Interrupt not firing
- Electronic – PIC32, XC32, timer interrupt vector not entered
- Electronic – STM32: UART Interrupt is triggering without any flags getting set
- Electronic – Enable interrupt but no ISR
- Electronic – Unexplained interrupt behavior in AVR ATMEGA324P Timer Counter ISR
- Electronic – Is this the correct truth table to determine whether or not to execute an interrupt in a RISC V system
Best Answer
I think I have seen this issue before. Since the Interrupt Vectors are at the beginning of the chip's code section, there is a chance that you will accidentally jump somewhere to this region. Since all the vectors are implicitly set to jump to BADISR, pretty much everytime you jump there, BADISR will be executed.
Are you working with function pointers? Perhaps an array of function pointers? Make sure you are not using uninitialized fields, and not exceeding boundaries.