RE: [avr-gcc-list] Looking for a spurious interrupt

[Theodore A. Roth]

On Fri, 3 Sep 2004, Bernard Fouché wrote:

> Hi René.
>
> I've thought of that, but it will generate one handler per signal and at the
> moment I'm very tight in memory and, if possible, I would prefer to read a
> particular register, if ever such a register presenting this information
> exist. Otherwise I'll do something like you describe.

If you are able to use on-chip debugging (jtag or debug-wire), you could
modify the gcrt1.S so that each of the unused vectors simples jumps back
onto it self (using a "rjmp .-2"  asm statement or somthing like that).
Then you just let your code run in the debugger and interrupt it when it
seems to have locked up. At that point, the PC should tell you what
vector fired.

Every time I have ever seen this problem in my projects, it's been due
to either a bad function pointer, or the one of the stacks in a
multi-tasking system has overflowed (which eventually shows up as a bad
return from the other task's clobbered stack). This problem also
manifests itself as spurious resets.

In my projects, I'm not tight on flash, so I've gone with handlers for
every interrupt. Each handler prints an error message with the source
file name and source code line number to the serial port and then goes
into an infinite loop.  Since we are always using the serial port, I
know instantly when the message comes up that I need to start hunting
down some memory corruption.

Be creative. Like the perl guys like to say, "There's more than one way
to do it." In the worst case, you might have to just revert to code
inspection, but that's hard and so easy to over look some minor detail.

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden