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?
3
-
\$\begingroup\$ The PRR register only stops the clock to disabled modules. That should take care of all of the modules you listed. What is this BADISR_vect? \$\endgroup\$– Matt YoungCommented Nov 3, 2013 at 16:33
-
1\$\begingroup\$ Why not temporarily add all the ISRs? \$\endgroup\$– Ignacio Vazquez-AbramsCommented Nov 3, 2013 at 16:33
-
\$\begingroup\$ I tried adding all ISR with a unique identifier (using the vector number) that can be displayed if an unwanted interrupt occurs but I could not re-create the problem i.e. the issue is not reproducible. The units work fine after re-setting them \$\endgroup\$– BaforealeCommented Nov 3, 2013 at 18:40
Add a comment
|
1 Answer
\$\begingroup\$
\$\endgroup\$
7
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.
-
\$\begingroup\$ I'm not using any function pointers in my code and there is a small percentage on my 3000 units that exhibits this behavior. I'm hoping that this is not a firmware issue because of this small percentage \$\endgroup\$ Commented Nov 3, 2013 at 18:32
-
\$\begingroup\$ If I were you I'd hope that it is a firmware issue. But anyway, ATM I don't have any other explanation. \$\endgroup\$– DzardaCommented Nov 3, 2013 at 18:36
-
\$\begingroup\$ Also, the issue is not reproducible and the units work fine after resetting them \$\endgroup\$ Commented Nov 3, 2013 at 18:41
-
\$\begingroup\$ The only way I can think of, regarding an easy fix, would be using debugging. Have you got a debugger device that you can try it with? I'd set up code breakpoints at the interrupt vectors and when it happens, I would see what was executing before that based on the stack values... Wait a second... You can dump the stack trace in BADISR, and then try to decode what was going on before that! \$\endgroup\$– DzardaCommented Nov 3, 2013 at 18:52
-
\$\begingroup\$ I tried debugging using Atmel studio 6.0 and set-up a breakpoint like you suggested but I could not re-create the problem. \$\endgroup\$ Commented Nov 3, 2013 at 19:16