avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Klaus Rudolph
Subject: Re: [avr-gcc-list] inline debugging stk200/stk500 and gdb 5.x
Date: Mon, 01 Jul 2002 18:01:55 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]