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

[Jason Kyle]

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