Re: [avr-gcc-list] inline debugging stk200/stk500 and gdb 5.x

[Iztok Zupet]

On Monday 01 July 2002 15:58, Klaus Rudolph wrote:
> >  The idea of putting basic GDB "stubs" into boot block is not at all bad.
> > Anyhow it can communicate with GDB over the serial line (I suggest the
> > second
> > one, if the ATmegaXXX has it), or in a avr-mon like fashion over any 3
> > user
> > configurable pins.
> >
> >  As for "min 1000 page rewrites guaranted": during a SW development
> > cycle,
> >
> > code gets frequently changed and thus the AVR flash frequently
> > reprogrammed.
> > Aditional few brakpoint writes during one code debug cycle doesn't mean
> > very
> > much, because the debug ability decreases the overall reprograming cycle
> > count by half.
>
> I think there is no need to make a rewrite to code sections at all. Please
> have a look
> at avrmon sources. He uses overflow0 interrupt to go to central debug
> routine.
> This needs lot of time, ok. After each instruction he comes back to the
> debug routine
> check for 8 software breakpoints and continue then. This is also be usable
> in a
> avr-stub.c I think. This software is also able to make single step,
> register modifications and so on.
>
> Whats to do:
> in gdbserver.c from simulavr we can take some avr related stuff for the
> stub I hope.
> in avrmon/monitor.c we find the method to make single step and software
> breakpoints
> and the m68k-stub.c from gdb could be the startpoint for writing the
> avr-stub.c
> I invested one our up to now, but I haven't understand all that stuff until
> yet.
> But there might be some people which are better gdb programmers than I.
> Someone who will spend some time there?
>
> Reweriting code is not my favorite way. For devices like at90s8515 this way
> is not
> usable at all, and not all want spend much money for a stk500 or atmega's
> or both.
> Can you agree with the avrmon method? (Using timer0 for debug/single-step)
>
> Bye
>    Klaus

 I've been using avrmon up to now. It does'nt allow you to debug in real time 
(program executes slowly), nor to debug SIGNAL handlers (not interruptable 
there). Writing the breakpoint instrution into flash would enable all that.

iz
avr-gcc-list at http://avr1.org