1

My AVR programming method is usually as follows:

  1. compile the source code with avr-gcc:
avr-gcc -mmcu=<mirocontroller_id> <source_file>.c -o a.out
  1. Convert the compiled code into hex with objcopy:
objcopy -O ihex a.out a.hex
  1. Write the hex to the flash of the microcontroller with avrdude:
avrdude -c <programmer_id> -p <microcontroller_id> flash:w:a.hex

This works great. Its fast, reliable, and very flexible. Now I want to add onto this toolchain with debugging functionality. I have heard of something called avr-gdb, but I don't know a whole lot about it. Documentation is difficult to find, and there is little information out there on it. I would love to be able to set breakpoints, and read the state of watched variables in the microcontrollers memory, as well as being able to see a hex dump of the memory.

Kalcifer
  • 235
  • 1
  • 12
  • `avr-gdb` is the AVR targeted version of the classic `gdb` debugger; see https://www.systutorials.com/docs/linux/man/1-avr-gdb/ and https://linux.die.net/man/1/avr-gdb (usual terse linux docs) -- there are also gdb tutorials that go into greater detail. It's command-line based rather than GUI based, though I think eclipse CDT does work with gdb if you need a visual debugger (seems like you're comfortable with command line though). I have used gdb with other microcontrollers but not avr, it's on my bucket list... See also https://stackoverflow.com/questions/tagged/avr-gcc?tab=Votes – MarkU May 07 '21 at 07:51
  • 1
    @MarkU How would you go about actually connecting to the target to start debugging? `avr-gdb -> target /dev/hidraw11` or something similar? – Kalcifer May 07 '21 at 08:00
  • https://www.avrfreaks.net/comment/2211186#comment-2211186 suggests something like arm-none-eabi-gdb -iex "target extended-remote localhost:3333"... – MarkU May 07 '21 at 09:30
  • Not all AVR MCUs have internal debugging hardware, only a few of the ATMega parts have JTAG, and some of them have the TPI interface, which can be used for very limited debugging. Can you confirm that your microcontroller has a JTAG peripheral inside? – Luke Gary May 07 '21 at 22:36
  • @LukeGary the mcu I was using has a debugWire interface, but im not entirely sure how to get that to work. I changed the fuse bit to allow communication over debug wire on one of the microcontrollers i had and it ended up just bricking the unit. Couldn’t program it after. I remember a warning being thrown that only atmel studios debugger could modify it or something but that doesn’t make a whole lot of sense. – Kalcifer May 08 '21 at 00:00
  • 2
    Although debugWIRE is supported on the ATmega328p microcontroller itself, the typical "Arduino UNO" type of reset circuitry gets in the way... ATmega328p datasheet section 24. debugWIRE On-chip Debug System -- Physical Interface says this: "• Pull-up resistors on the dW/(RESET) line must not be smaller than 10kOhm. The pull-up resistor is not required for debugWIRE functionality. • Connecting the RESET pin directly to VCC will not work. • Capacitors connected to the RESET pin must be disconnected when using debugWire. • All external reset sources must be disconnected." – MarkU May 09 '21 at 01:36
  • GDB commonly works over a communication channel, and it expects a "gdbstub" in the target. You can direct GDB to use a serial connection. -- But since I don't have any experience with this method on AVR, I can't help further. – the busybee May 10 '21 at 10:31
  • You can use Bloom (https://bloom.oscillate.io) for this. Bloom interfaces with the debug tool in order to gain access to the target. It exposes an interface to the target via a GDB RSP server. So it serves as a "gdbstub". You don't have to use the GDB CLI - any IDE with GDB RSP support will work well with Bloom. It supports debugWire, PDI, UPDI & JTAG, Disclaimer: I am the author of Bloom. – navnav Sep 27 '21 at 23:00

0 Answers0