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

[Bernard Fouché]

Thanks everyone for your suggestions. The project I'm working on is a custom
design and it appears that a device on the PCB, when activated, produces a
power
drop that pertubates the atmega! That was found this afternoon.

So that's a hardware glitch and no software problem...

-----Message d'origine-----
De : Theodore A. Roth [mailto:address@hidden
Envoyé : vendredi 3 septembre 2004 17:52
À : Bernard Fouché
Cc : AVR GCC List
Objet : RE: [avr-gcc-list] Looking for a spurious interrupt


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