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

[Iztok Zupet]

On Monday 01 July 2002 12:31, Jason Kyle wrote:
> At 11:12 1/07/2002 +0200, you wrote:
> >Hi all,
> >
> >we have discussed the missing jtag support from atmel the last days. So I
> >search
> >for an alternativ way. I have an older version of avr-mon (0.6) which is
> > not usable with actual gdb versions and needs an incompatible patch to
> > work. (incompatible to simulavr). Also there is no support for rs232
> > debugging on stk500
> >or? Ok, the 6 pin header for seriall programming might be used, or?
> >
> >Is there an idea to bring the avr-mon code into a actual state here?
> >I´m not able to do that, because I do know nothing about the
> >gdb low level functionality. So there is no way for gdb patches and such
> >things.
> >But it seems to be not such a big problem to make the inline code
> >workable on an UART or?
> >
> >OK, i will have a look in the avr code now. If somebody can help to get
> >gdb working with it? It should be use the same interface like the simulavr
> >or?
>
> Use the gdb serial debugging protocol.
>
> >Help strictly welcome. :-)
>
> A while ago I briefly discussed an alternative to jtag debugging with Ted,
> the basic idea was to use any megaAVR with self programming and a boot
> block (m163 and later) and write code for the boot block that acted as a
> gdb remote (serial port on uC to start with, maybe SPI later).  When you
> set a break point with gdb you would use SPM/page to do essentially the
> same thing as 'normal' gdb debugging in a RAM execution space.  One
> drawback if of course the use of AVR resources, and another is the min 1000
> page re-writes guaranteed.  Note that the JTAGICE allows setting of break
> points etc in program memory with the same 1000 re-writes issue.
>
> If this idea can actually work then it is possible to do zero cost
> debugging.
>
> Cheers,
>
> Jason Kyle
>
> avr-gcc-list at http://avr1.org

 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.

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