avr-libc
avr-libc copied to clipboard
avrdudes
[task #7546] Rework the default interrupt handler
Sat 22 Dec 2007 09:34:53 PM CET
Right now, the default interrupt handler eventually ends up in restarting the application at address 0, so the user- visible effect is almost similar to a reset, which has turned out to cause minor surprises occasionally.
Other ideas have been discussed about the default ISR. Just using a RETI is not really better: some interrupts are not auto-clearing so they would end up in an infinite loop, and in all other cases a missing ISR is a programming error most of the time which would go completely unnoticed for a long time then.
The best idea so far came once from Peter Dannegger. He suggested to CALL/RCALL the default handler from within the vector table, rather than JMP/RJMP to it. That way, the default handler can then pop the return address into a register where it can be examined with a debugger (or inside the default handler itself if it's a custom handler). That way, programmers will get an idea what interrupt triggered.
Finally, the default handler should best run into an infinite loop with interrupts disabled. abort() has been suggested a possible implementation for that which is already there.
The difficulty of this idea is that the current scheme to fill the vector table with JMP/RJMP instructions to locations that are eventually inserted by the linker won't work anymore. A new scheme would be needed where by default, a CALL/RCALL is placed into the slot, and is then replaced by a jump instructions for all vectors that are actually defined by the application.
This issue was migrated from https://savannah.nongnu.org/task/?7546
Eric Weddington
Good ideas still here. Any more thoughts on moving this forward?
The difficulty of this idea is that the current scheme to fill the vector table with JMP/RJMP instructions to locations that are eventually inserted by the linker won't work anymore.
This should be possible, for example by means of a new pseudo instruction.
The problem with that solution is that we don't know which Binutils version is used with crt*.o because the crt's may come as part of a device pack, which bypasses all efforts by configure etc.
Currently, crt*.o works with all versions of Binutils and the compiler, so using such pseudo instruction would break that; and I don't see any backwards compatible way to implement it.
...maybe like so: The linker transforms JMP to CALL in, say, relaxation, but only when a specific symbol is defined. That way one has control over the feature without the requirement of a new command line option.
