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

[Klaus Rudolph]

> 
>  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


 

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

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