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

[Iztok Zupet]

On Monday 01 July 2002 18:01, Klaus Rudolph wrote:
> Iztok Zupet wrote:
> > 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.
>
> OK, maybe we should enable both methods. How should single step work?
> Have we write a
> break for each step? If not, there must a mechanism to interrupt the
> target after one
> instruction. And if so, we have this method I prefer allready
> implemented.
> This is not an aspect against the rewriting things, this is an
> additional option. :-)
> So we can debug slowly the old parts and "real time" newer ones with
> rewriting
> the flash.
>
> You wrote that your are using avrmon up to now. Which gdb and patches
> you work with?
> This stuff available with gdb 5.2? Using old 4.18 + patch?
>
> Bye
>       Klaus
> avr-gcc-list at http://avr1.org

 That sounds a kind of solution, although the Atmel private JTAG opcodes seem 
to do just that (a kind of breakpoint register must be in there).

 So far i use the original Denis'es avrmon - mon pair,  private patched to 
work with Insight 5.0, which is again patched for AVR and AVR-mon target.
Works with the same cable as UISP in dapa mode.

 Thought also of extending pAvr programmer SW to support avrmon-mon 
communication over serial cable.

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