PlatformIO Community

VSCode PIO debugger for AVR

Hello,

I use dwdebug https://github.com/dcwbrown/dwire-debug which works fine with a minimal wiring through a simple CH340 USB Serial adapter and a very simple hack wiring (see github for info).

Can run, breakpoint, disassemble, set and read ram, flash, eeprom etc… very powerful thanks to the amazing work from David C W Brown.

For convenience, I link my Arduino Nano with a raspberry pi, which is on the same network as my main windows 7 x64 workstation.

I read several messages that stated there had no gdb server for AVR. It happens that dwdebug can work as a gdb server, therefore my PI is somewhat equivalent to a blackmagic Ice.

I did not test yet transforming a raspberry PI ZERO in such a way it could mimic a blackmagic Ice, but given the price and availability of such device, I think the idea is quite pleasant.

Before opening the hood further on RPI, I would like to know what exactly miss on the platformio vscode piece of technology to make this work.

What do you suggest as the simple way to make this happens, i.e. having a similar interaction on VSCode with an AVR as we have on th ARM platform, including disassembly and one breakpoint , of course with DebugWire specific limitations?

Many thanks in advance

Many thanks.

1 Like

Very, very interesting. I’ll try that myself and see whether I’ll get a work avr gdb debug server.

PlaltformIO code wise, when e.g. comparing STM32 and AVR platforms, you see that implementation of debug tools adds the reference to the binary that is started to get a gdb-server up and running. See here and the current code here (_add_default_debug_tools), together with debug information for the specific boards (see first link). Once the appropiate code for AVR has been added the pio debug command should be able to launch a GDB server for it and everything else should work out of the box. I’ll try and see what I can do.

I think the extension just talks to GDB which talks to the underlying GDB server, so all these specifics should be handled automatically.

1 Like

Very clear.

I think the basic things to do are
1-launching the ‘dwdebug gdbserver’ command that launch the debugger, connects it to the default serial USB and launch the gdbserver on port 4444
2-run a windows local avr-gdb that will connect to the RPI on port 4444.

That should be enough.
I have to figure out how to install avr-gdb on my windows machine. I am currently compiling it on the RPI to test on localhost on remote terminal.

I know you can also run remote gdb through vscode see:

Used that already, works decently although I experienced some vscode bugs preventing a connection, apparently solved.

Investigate how this could help in further automating the stuff…

Just use PIO and compile any AtmelAVR sketch, like blinky for an Uno. The downloaded compiler toolchain contains avr-gdb already. It’s under a path like C:\Users\<user>\.platformio\packages\toolchain-atmelavr\bin\avr-gdb.

2 Likes

Hi,

It works!

Just added as you advised
debug_tool=custom ,
debug_server=the debug_server executable and
debug_init_cmds = target remote myRpi:4444

To test this, I had a simple blink project, and I uploaded manually the firmware.elf file to the PI using scp then flashed it using dwdebug out of gdbserver.

BUT there are at least 2 identified issues:
1-Breakpoints are somewhat wild, dwdebug is designed to handle only one, nobody told PIO this…
2-Disassembly is messy, preliminary investigations show me a possible byte inversion somewhere…

Not taking in consideration some compile flags, and the fact dwdebug is not able to handle the specific gdb avr command, say “info io_registers” command.

Many thanks for your advice, and again a big hurrah for David C W Brown.
nevertheless, I think I am on the right track. Once I am able to debug flawlessly code this way, I will attack the upload part of the story. In the mean time, I have also to greatly enhance my gdb skills, therefore the confinment period is some kind of blessed time and this project finally will help me supporting not to see my children and grandchildren.

1 Like

Do you have any progress on this?

My 2 cents about this.
I took another approach and successfully configured VSCode to work and debug a simulated AVR microcontroller.
The simulator used is simavr, a project which has been developed for a long time and is pretty usable and also supports GDB (very important). Also, it not only emulates the execution of the code but can emulate most of the peripherals, interruptions, and even create graphs of the registers.

Here some of the tweaks necessary to make it work with Platformio:

The microcontroller’s code itself doesn’t need any modification to work with simavr, but using some of the macros can help to get data out of the simulation and improve the debugging experience.

Hi,
I’ve been thinking about the stated problems and possible solutions.

Maybe the following gdb configurations would be enough:
set remote hardware-watchpoint-limit 1
set remote hardware-breakpoint-limit 1

As I understood that would tell gdb that the hardware itself can’t use more than a hardware breakpoint/watchpoint at a time.

I got a similar if not the same problem when testing the other two tools: simavr and avr-debugger. The final fix was just accepted less than a week ago, so it will take some time until the compiled binaries arrive.

Meanwhile, I got a workaround by casting the address like this:

disassemble (void (*)())0x000008ca, (void (*)())0x000008da

You can even create a custom definition, both for gdb or typedef for your firmware, so you don’t have to type that ugly cast every time:

Then just use the following on the gdb terminal.

di 0x000008ca 0x000008da

Or if you used the typedef definition

disas (faddr)0x000008ca, (faddr)0x000008da

I haven’t tested this dwire-debug tool yet, but I think it would make a great addition to the repertory. :wink:

1 Like