Go Down

Topic: Advantage of Arduino (Read 9433 times) previous topic - next topic

bperrybap


Is there a gdb stub for AVR?  I assume it would fit in the larger AVRs...
(I wish Atmel documented the chip-level debug features, though.  There's a lot that a debugging stub running on the AVR just can't do on an embedded processor like the AVR.  (no dynamically settable breakpoints...))


The current debug method on the AVR is to use kind of helper filter program. (AVaRICE)
It intercepts the gdbmon messages and translates them to to what the other end needs.
Currently the "other end" is not a gdb stub inside the AVR but rather an Atmel h/w debugger device.
However, I am certain that it is possible to do it using a gdb stub
including single stepping and dynamically settable breakpoints when using a gdb stub running on the AVR.
The stub does have to modify flash to set a breakpoint, but that is possible.
(The AVR JTAG ICE and dragon devices modify flash when setting break points, but they use the internal OCD support to do it)
It is also possible to force a break using hardware by assigning it to pin interrupt and having that
ISR call the gdbmon debugger entry point. Then you can simply wire up a button to that pin
and push a button to drop in to the debugger.

Single stepping does not need to modify the flash.

There have been a few other attempts including some that actually work. While
all the functionality is there between the several that I've seen, none of them offered
everything, including single stepping, and breakpoints. i.e. one might do one but not the the other
and vice versa.

I've toyed with creating a "gdbmon" type stub that lives in the users code or perhaps even in a bootloader
or a combination of both that supports everything.
gdbmon stubs don't really do much.
They return registers, and have some very minimal register/memory access/modify
capabilities. The tricky part is handling the Harvard address spaces. Luckily how to deal with that has already been worked out
in the AVR version of gdb.
Code size and RAM isn't the real obstacle for most AVRs; however, pins on some devices like the 8 pin ATTiny parts is a real issue.
I believe a gdbmon stub would be very small (less than a few hundred bytes) as long is it works with a little bit
of host based software similar to the Atmel interface.
It would allow the serial port to be used for full source level debugging and single stepping.
To make it work requires stealing a pin interrupt,
or perhaps int0 and opening up the flash for modification if the flash modification code is not living in the boot block.
The pin interrupt is used to essentially s/w trap in to the debugger since
the AVR has no trap capability.
It also would potentially require a custom version of gdb because the current avr-gdb modifies flash with a BREAK
instruction which only works with atmels internal OCD. To make this work requires a slightly different opcode sequence.
I've even considered detecting the BREAK instruction flash modification sequence and patching it on the fly
with the opcode I need so that the stock gdb could be used. The catch here is that in order to not modify gdb
you can only use a single opcode. This can be done if you steal a pin change interrupt and trigger it
in s/w with a single opcode instruction.

All of this is very doable and not that difficult.

I just haven't gotten serious about doing it yet since I currently can use the Dragon.
Eventually I'll get to it. I think it will be a fun little project.

--- bill

Go Up