AVR (Arduino) Linux Debug?

[RoGeorge]

Looking for a hardware debugger + IDE for ATmega and ATtiny on Linux.

Don't want to buy extra hardware, already have these:
    - PICkit 2 from Microchip
    - an Atmel Xplained nano ATtiny104 board (my understanding is it has some onboard Atmel debugWire w an ATmega32, it is seen as  usb-ATMEL_mEDBG_CMSIS-DAP_ATML, might be OpenOCD compatible, no idea)
    - spare ATmega chips or Arduino nano/Uno boards to emulate an ISP or a debugWire programmer
    - DIY FT232 based USB to serial (I've read some generic JTAG tools are based on FT232)
    - generic USB to serial (probably CH340, not sure)

1. Can any of these be used in an IDE for debugging?
2. Which one should I use, Eclipse + avr-gcc, or proprietary toolchain?
3. Is proprietary Microchip/Atmel supported on Linux, and do they allow non-proprietary programmers/debuggers?

I don't want software stub debugging, preferably would be a 1 wire debugger, so it won't block the ISP pins at debug.
Currently I am using Linux + VScode + Arduino plugin for VScode + AVR-GCC, but no hardware debugger.

[RoGeorge]

Couldn't find exactly what I was hoping for, but close.



Found an article about a tool pk2cmd that can talk with a PICkit2 in Linux.  The pk2cmd tool apparently is written by Microchip.  The source files can be downloaded for free, old webpages are now gone gone but the sources are still there, in a secret place on Microchip's servers, place Google doesn't know  , or at least doesn't show it in search results:

https://www.mexchip.com/en/2010/07/how-to-use-the-pickit2-programmer-under-linux/
http://ww1.microchip.com/downloads/en/DeviceDoc/pk2cmdv1.20LinuxMacSource.tar.gz

To compile pk2cmd on Linux (mine was Kubuntu 20.04 LTS), unzip the downloaded sources pk2cmdv1.20LinuxMacSource.tar.gz, cd inside the unzipped folder, open a terminal and type:

Code: [Select]

        # prerequisites libusb-dev
        sudo apt install libusb-dev

        # compile and install pk2cmd
        make linux
        sudo make install

        # add to path pk2cmd so it can be run from any folder
        PATH=$PATH:/usr/share/pk2
        export PATH
        #search how to make the PATH changes persistent after a computer reboot

        # plug the PICkit into a USB port and test pk2cmd
        pk2cmd -?v
            # the outpuut should look like this
            #
            # Executable Version:    1.20.00
            # Device File Version:   1.55.00
            # OS Firmware Version:   2.32.00
            #
            #
            # Operation Succeeded
pk2cmd won't directly help with AVR debugging, but in theory another program can use pk2cmd to control the PICkit's pins just right to talk with AVR chips.  Couldn't find yet such a tool, maybe somebody will write a GDB to pk2cmd.



Another tool I've found is dwdebug.  This is a tool that can turn a USB to serial adapter (like a FTDI or a CH340) into an AVR debugWIRE programmer/debugger.

https://github.com/dcwbrown/dwire-debug   

To compile for Linux, download the zip from github, unzip, then cd into the unzipped folder.

The sources try to include the headers for a library that was deprecated long time ago '#include <stropts.h>', so it won't compile.

stropts.h is part of the Posix STREAMS extension, which Linux never supported. (Since 2008, it has also been marked as obsolescent by Posix, so it may be removed in some future standard revision.)

Apparently stropts.h is not needed for Linux at all, so in the unzipped dwire-debug-master open file ./src/system/SystemServices.c, remove the line 34 #include <stropts.h>, then save.  Now it should compile.

Code: [Select]

        # prerequisites libusb-dev
        sudo apt install libusb-dev

        # compile and install dwdebug
        make
        sudo make install

        # plug the USB to serial adapter (FTDI or CH340) into a USB port and test dwdebug
        # RTFM (it will need a diode) and a connection to a chip with the debug wire fuse enabled
        #   [url]https://github.com/dcwbrown/dwire-debug/blob/master/Manual.md[/url]
        dwdebug

Not a GUI debugger yet, but a great tool, thank you!  Much closer to the goal now.

[cv007]

Or you could spend $15 for a SNAP programmer/debugger. Install MPLABX. Download the arduino setup zip file, extract the compiler. Point MPLABX to the compiler bin folder as another toolchain. Code, program, debug. Pic10/12/16/24/32, avr0/1 and 'old' avr, and sam. Single ide, all programmer/debuggers work- snap, pickit, xplained/nano boards. Install as many toolchains as you want, in various versions.

The avr0/1 mcu's are better in many ways, so unless you want/need to stick to the old/original avr, you may want to take a look at them.

[oliviasmithh900]

Yeah don't go into so much trouble for such a basic thing, why you are fighting with the winds, just go with the flow .... use windows & Arduino setup

[Nominal Animal]

Yeah don't go into so much trouble for such a basic thing, why you are fighting with the winds, just go with the flow .... use windows & Arduino setup

Why stop there?  It's much easier to just eat glue and be happy than fight all this difficult technology stuff.  Linux, yecch, right?

[Ian.M]

Found an article about a tool pk2cmd that can talk with a PICkit2 in Linux.  The pk2cmd tool apparently is written by Microchip.  The source files can be downloaded for free, old webpages are now gone gone but the sources are still there, in a secret place on Microchip's servers, place Google doesn't know  , or at least doesn't show it in search results:

https://www.mexchip.com/en/2010/07/how-to-use-the-pickit2-programmer-under-linux/
http://ww1.microchip.com/downloads/en/DeviceDoc/pk2cmdv1.20LinuxMacSource.tar.gz

I saved all the PICkit 2 links when they vanished back at the beginning of 2014 in a post on the Microchip forum: https://www.microchip.com/forums/FindPost/775368

Google knows about them - Try: https://www.google.com/search?q=pickit2+pages+missing

[cv007]

My previous answer may have been twisted a little, so I'll add some more.

MPLABX runs in linux just fine, and has for many years. I use linux and have done so for many years, but makes makes no difference if you run Windows or some linux distro- MPLABX works the same on either, and you can get an avr-gcc compiler from anywhere you want for any os and are not tied to XC8-avr. The arduino setup file is a simple way to get a 7.3.0 avr compiler, but I have no use for arduino other than a source for a compiler (using some version that gets used by many and is easy to find is what I am after, plus it supports c++17 which has some things that I like).

The original post title seems to have changed, but advice still the same- if you want to run a debugger, use an ide that makes it easy to use (shows registers, register bits, etc.). I don't find myself using the debugger that much, but it is handy sometimes. I also use an external code editor most of the time, so MPLABX becomes a project manager where it is simple to create new projects, can switch to any project (pic/avr/sam) and you do not need to worry about programmer/debuggers (I have 2 SNAP's, various xplained/nanos, pickit3, and they all will work without fussing around)- write code, press compile button, press program button, test, repeat.

I'm not against command line. For nRF52, I use only command line, since Nordic seems to be the rare one that gives you a ton of examples all with makefiles (and no registration required for anything they provide, a big plus in my book). My first debugger was the led on the nRF52 usb dongle blinking error codes from the ble stack. I now have a dev kit which has a segger jlink so I use rtt to 'print' debug info via swd. You also get to use segger embedded studio (licensed for Nordic products), and is probably a smarter way to go for better debugging, but have not needed it yet.

[RoGeorge]

I've tried MPLAB X IDE, out of curiosity:
    - still works offline, invites for cloud/registration, but not mandatory   
    - bloated with Facebook, Twitter, etc. icons 
    - has between 2-7 GB installed   
    - has a shopping basket in the compiler/debugger menu bar 
    - their compiler XC8 needs a separate install (not included with the IDE), has a free and a pay version
    - it spreads all over the disk, in about 10 different locations   
    - has an uninstaller but forget crumbs all over the disk, including the udev rules   
    - has Windows/Linux/Mac versions 

Easy to install and use, a decent looking IDE if you can live with its bloatware.

However
    - v4 v5.25 (or v5.35?) was the last version that can still use the PICkit2 to program an MCU from the IDE
    - starting with v5 (v5 is the first supporting Atmel MCUs, too, now at ver MPLAB X IDE v5.45) PICkit2 support was removed, minimal is PICkit3
    - either v4 or v5, the standalone programming tool does not support PICkit2, so only programming from the IDE
    - I've tried to debug with v4 IDE, original PICkit + its original demo board for PIC16F690, and it doesn't work ( <--- shouldn't work because PIC16F690 never had debug capabilities), can program but can not debug
    - the Microchip IDE I remember using and working properly was called MPLAB IDE (without the X), and it was for windows only

Too big, and certainly not a tool that would trust it to be usable 5 years from now.  Even the installers from the last year were having the text white on white, and older versions like v2 refuses to install even with java 8m want java 6.


- the good news is that 'dwdebug' tool (the one based on the reversed engineered debugWIRE protocol), not only can debug in text mod, but it can act like a gdb server for the gcc's gdb debugger.  I've tested step by step execution and registry read from gdb-avr, and it worked.

Code: [Select]

dwdebug device ttyUSB0
    Connected to ATtiny13 on /dev/ttyUSB0 at 76043 baud.
    0210: f7f1  brne  020e (-1)             > u
    0212: 9701  sbiw  r25:r24, $01
    0214: f7d1  brne  020a (-5)
    0216: 91ff  pop   r31
    0218: 91ef  pop   r30
    021a: 9508  ret   
    021c: 9a36  sbi   $6, 6
    021e: 9936  sbic  $6, 6
    0220: cffe  rjmp  021e (-1)             > gdbserver
    Didn't receive 0x55 on reconnection, got 80.
    Clock speed may have changed, trying to re-sync.
    ..............Target ready, waiting for GDB connection.

    Info : avrchip: hardware has something
    Use 'target remote :4444'
    Connection accepted.
    Got: qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+
    Got: vMustReplyEmpty
    Got: Hg0
    Got: qTStatus
    Got: ?
    Got: qfThreadInfo
    Got: qL1160000000000000000
    Got: Hc-1
    Got: qC
    Got: qAttached
    Got: g
    Got: qL1160000000000000000
    Error reading command. Error code: 0!
    0000: c009  rjmp  0014 (+10)            > q

    A device is connected. Please use one of these quit commands:

    qr - Quit leaving device running. Executes a go command before exiting.
    qs - Quit leaving the device stopped.
    qi - Quit in In-System Programming mode. Use this if you have SCK, MISO and MOSI connected
        and want to use SPI programming software such as AVRDUDE.

    0000: c009  rjmp  0014 (+10)            > qr

These are the registers shown from gdb, after connecting the avr-gdb debugger to the debug server created with dwdebug:

Code: [Select]

avr-gdb
    GNU gdb (GDB) 8.1.0.20180409-git
    Copyright (C) 2018 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "--host=x86_64-linux-gnu --target=avr".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.
    For help, type "help".
    Type "apropos word" to search for commands related to "word".
    (gdb) target remote :4444
    Remote debugging using :4444
    warning: No executable has been specified and target does not support
    determining executable automatically.  Try using the "file" command.
    0x00000000 in ?? ()
    (gdb) info registers
    r0             0x1      1
    r1             0x8c     140
    r2             0x36     54
    r3             0x47     71
    r4             0xae     174
    r5             0x0      0
    r6             0x0      0
    r7             0x87     135
    r8             0xa2     162
    r9             0xc1     193
    r10            0x14     20
    r11            0x0      0
    r12            0x33     51
    r13            0xd5     213
    r14            0x43     67
    r15            0x7b     123
    r16            0x9c     156
    r17            0x2      2
    r18            0xb9     185
    r19            0x0      0
    r20            0xdc     220
    r21            0x0      0
    r22            0xa8     168
    r23            0xc5     197
    r24            0x83     131
    r25            0x0      0
    r26            0x76     118
    r27            0x0      0
    r28            0x9e     158
    r29            0xf0     240
    r30            0x32     50
    r31            0x2      2
    SREG           0x0      0
    SP             0x1f9f   0x801f9f
    PC2            0x0      0
    pc             0x0      0x0
    (gdb) disconnect
    Ending remote debugging.
    (gdb) quit

IIRC, Eclipse has a GUI for gdb, so it should work to debug AVR targets in GUI mode using a single wire.  Must try that, too!   



Just in case I will get derail from it and forget what I learned so far:
- AVR microcontrollers (like the ATmega328 from Arduino, or ATmega8, or ATtiny13, etc.) can be programmed in many ways

    1. - parallel programming, with lots of wires, good mostly when the MCU was bricked by bad fuses programming

    2. - high voltage programming, with +12V on the reset pin, good for MCU with low pin count, where the Reet pin was programmed to become a normal I/O pin

    3. - ISP programming, the one that uses MOSI/MISO/SCLK/RESET pins, also the mode available on most boards including Arduino UNO and Nano, usually has a 6 pin connector called ICSP already populated on most boards

    4. - debugWIRE, uses only the reset pin as a half-duplex serial port to talk with the MCU.  The serial port speed on the debugWIRE (for AVRs) is the MCU clock/128.  Since the MCU clock can vary, the host needs a comm port that can be set at an arbitrary speed (note the ttyUSB0 baud rate was 76043  in the example above).  At handshake, the debugWIRE host tries various speeds until it receives the expected 0x55 reliably.

     From here, half duplex serial at that weird speed it is (unless the MCU clock changes its speed while running - rare but possible).  Memory can be read or poked, in AVR the registry and the ports are also mapped as memory, etc.  The MCU has dedicated hardware to talk on the debugWIRE, it does not use the AVR core.

     There are dedicated hardware breakpoints in the MCU, meaning a separate register to memorize the breakpoint address, and a comparator that continuosly keep an eye on the program counter.  When they match, it stops and memory+flags can be read or written.  Another way to set a breckpoint is to replace an instruction with the instruction "break".

    5. - another mode to program is using a bootloader, like the Arduino does.  The MCU can write its own flash, so a small program called bootloader receives somehow (e.g. through a serial port) the program to be written in flash.



- given the above programming modes, debugging can be made many ways, too:
    - using the SCPI mode
    - using the debugWIRE mode
    - using a software stub (a program needs to be added in our own program at compile time, like a little spyware/bootloader kind of, this will consume some flash space and needs to be manually added before compiling)
    - and there is the horrible sprint debugging, meaning no debugger, just serial print or blinking pins as a signal



DebugWIRE seems the most appealing because it has dedicated hardware breakpoints registers, and because it uses only the Reset pin, so all the other pins can be used in the final product.

- By default, the debugWIRE mode is disabled, to enable it assert (using ICSP) the DWEN fuse bit and cycle the power of the MCU
- While doing this, the program and memory protect fuse bits must be deasserted
- At next power up, the MCU will be in debug wire mode and it will remain in debugWIRE even after power cycling (and the ICSP mode will remain disabled)

- now debug, inspect variables, change flags, inspect the stack, run step by step or with breakpoints, remove power, etc. do whatever to debug through the debugWIRE

- To get back to the normal ICSP mode, assert (using debugWIRE) the SPIEN bit
- SPIEN asserted enables back the SPI mode (and disable the debugWIRE)
- SPIEN is volatile, so DO NOT power down the MCU, connect the SCPI programmer and de-assert the DWEN fuse.  DWEN fuse is not volatile, so now it's all back to normal, and can cycle the power down or do whatever



- in practice, tested only from the command line so far:
    - ATtiny13 as target MCU
    - PICkit2 controlled by avrdude as ISP AVR programmer (PICkit2 was the only one I found around, and it can be used as an ISP programmer for AVR even if it was made for PIC, but any other AVR ISP programmer will work)
    - CH340 generic USB to (TTL) serial adapter as debugWIRE programmer/debugger controlled by dwdebug

- normal dataflow would be
    1. Eclipse IDE debugging window ->
    2. avr-gdb debugger client ->
    3. LAN (localhost) ->
    4. dwdebug gdb server ->
    5. CH340 USB to serial adapter ->
    6. debugWIRE pin (the Reset pin of the ATtiny13)

Briefly tested so far between points 2. to 6. and working.
For ATtiny13 the DWEN fuse is bit 3 of the hfuse byte (there is a high, a low and an extend fuse byte for fuse bits), usually hfuse is 0xff, program it as 0xf7 to assert the DWEN.

Code: [Select]

    # assert DWEN to put the ATtiny13 in debugWIRE mode (hfuse from default 0xff to 0xf7)
    ./avrdude -p t13 -c pickit2 -C ./../etc/avrdude.conf -U hfuse:w:0xf7:m

        avrdude: AVR device initialized and ready to accept instructions

        Reading | ################################################## | 100% 0.01s

        avrdude: Device signature = 0x1e9007 (probably t13)
        avrdude: reading input file "0xf7"
        avrdude: writing hfuse (1 bytes):

        Writing | ################################################## | 100% 0.02s

        avrdude: 1 bytes of hfuse written
        avrdude: verifying hfuse memory against 0xf7:
        avrdude: load data hfuse data from input file 0xf7:
        avrdude: input file 0xf7 contains 1 bytes
        avrdude: reading on-chip hfuse data:

        Reading | ################################################## | 100% 0.00s

        avrdude: verifying ...
        avrdude: 1 bytes of hfuse verified

        avrdude: safemode: Fuses OK (E:FF, H:F7, L:6A)

        avrdude done.  Thank you.

If this will works from a GUI, too, will put some pics and connection diagrams
Sorry for the WOT.   

[Ian.M]

I doubt anyone could convert you to being a MPLAB X enthusiast, and I'd question their sanity if they tried and yours if they succeed, but let me correct a few factual errors:

MPLAB X 5.25 still has working PICkit 2 support.  I *think* v5.35, the last version that still includes MPASM does also, but as I haven't personally tried it, cant confirm.  I haven't looked at newer releases.

The Low Pin Count Demo Board with a PIC16F690 installed was never debug capable with the PICkit 2 or any Microchip programmer/debugger, as the PIC in question doesn't have any on-chip debug silicon, nor will you find *any* 'classic' Midrange PIC with debug silicon in a 8, 14, or 20 pin (LPC) package.  The only debug option was to buy a debug header for the PIC in question, that totally replaced it with a debug capable version of its die, on a transposer board with a header to fit the PIC socket and an ICSP/ICD connector.  They were device specific, weren't cheap, had different errata to the original PIC, and weren't exactly robust (either mechanically or electrically) and the -ICD or -ICE debug bondout package PICs they used were never available separately so any mishaps required header replacement.

A significant proportion of Enhanced Midrange PICs that fit the LPC demo board have on-chip debug support, but as they were launched in the era when Microchip was phasing out the PICkit 2, and its support list was frozen, they never got added so you require a PICkit 3 or newer to debug them.

The *ONLY* chip the PICkit 2 can debug (without replacing the PIC with a debug header) on the LPC board is the PIC18F14K22.

[RoGeorge]

MPLAB X 5.25 still has working PICkit 2 support.  I *think* v5.35, the last version that still includes MPASM does also, but as I haven't personally tried it, cant confirm.  I haven't looked at newer releases.

The Low Pin Count Demo Board with a PIC16F690 installed was never debug capable with the PICkit 2 or any Microchip programmer/debugger, as the PIC in question doesn't have any on-chip debug silicon, nor will you find *any* 'classic' Midrange PIC with debug silicon in a 8, 14, or 20 pin (LPC) package.
...
The *ONLY* chip the PICkit 2 can debug (without replacing the PIC with a debug header) on the LPC board is the PIC18F14K22.

Very useful info, thank you.  Though, I stopped using 8 bit PICs long time ago because mostly because of the memory page swapping, I still have a few 8 bits PIC chips waiting for projects.  I'll keep an install of a MPLAB X IDE v5.25 then, just in case I'll need to program any of them.

Just curious, why MPLAB X IPE (from IDE either v4.20 or v5.45), doesn't list pickit2 as a programmer?
The pickit2 is inserted, but the drop down menu in IPE is empty.

Code: [Select]

lsusb | grep -i pickit2
Bus 003 Device 031: ID 04d8:0033 Microchip Technology, Inc. PICkit2

[Ian.M]

IPE has never had PICkit 2 support.   If you are on Windows use the standalone PICkit 2 GUI application, or on Linux & macOS, use PK2CMD.

[RoGeorge]

    It works, it works!!!   



Eclipse IDE  ->  avr-gdb  ->  dwdebug gdb server  ->  CH340G USB to serial adapter  ->  1 debug wire  ->  ATtiny13 Reset pin 1   

[RoGeorge]

Debugging with the above setup was kind-of working, but not fully working, and not without manual intervention.
1. - disassembling was not working at all from Eclipse, with error "Unable to retrieve disassembly data from backend."
2. - starting/stoping the dbg-server (the external tool dwdebug) is not automated, has to be done manually
3. - putting the microcontroller in debug-wire mode by writing the proper fuse then powering it down has to be done outside Eclipse for now.  Same restoring the MCU fuses to normal ISP mode.  The good side of this is that it has to be done only once, and not at each code change, because newly compiled programs are programmed through debug-wire at the start of each debug session.

To improvise a working debug setup was one thing, to fix the rest is were the most of the effort really is.



Fixed so far:
1. - turned out the culprit for the disassemble error is not Eclipse, but GDB, and not really GDB, but the architecture of the AVR processors (Harvard, with code and data memory in distinct areas, therefore gdb was confused not knowing if it should disassemble from the data address nnn, or from the code address nnn).

Funny thing, this is a problem reported since 2010, with a known workaround patch, but for whatever reason the patch was not yet added to avr-gdb.   

Kind of outrageous if you think of the countless hours spent by everybody else trying to find how to fix this, no idea how this surrealistic situation still persists after 10 years.

Anyway, applied the patch manually, built avr-gdb from sources, and now disassembling finally works.



2. - a few scripts could do the automated start/stop of the gdb server, but when done manually it's just a press of a CTRL+C, an up arrow and an Enter, while a script will need to detect a lot of settings and treat countless corner cases to automate this properly.  Didn't wrote any scripts, too time consuming and a nightmare to maintain across multiple OSs.  A readme text explaining how to manually start/stop the gdb server should be enough for now.

3. - automating the DWEN fuse writing and power cycling the CPU would not be possible without manual intervention to cut the power, unless I'll do my own programming header able to turn off/on the MCU's power.  While easy to do, at this point will mean to design yet another AVR programmer. 

For now, avrdude with PICkit2 to program the AVR fuses (because this is what I happen to have, any other AVR programmer can be used to write the fuses) is enough, then a generic USB to serial adapter (CH340G + a diode) can be used as a one wire AVR debugger.

In theory PICkit2 can act as a generic USB to serial adapter too, so no need for a second (USB to serial) device, yet the PICkit2 is rare to find nowadays.

Also in theory, a CH340G can be turned into an ISP programmer, so no need for PICkit2 at all.  Maybe I'll try this setup later, only because it can turn a generic (CH340G) USB to serial adapter into a fully automated programming/debugging tool.



Links to the Eclipse error fix, the avr-gcc build script (includes avr-gdb) and the gdb patch:
https://www.mikrocontroller.net/topic/360831
https://r5zzq45g7w7fzq2alxlppe6hsa--sourceware-org.translate.goog/bugzilla/show_bug.cgi?id=13519
https://r5zzq45g7w7fzq2alxlppe6hsa--sourceware-org.translate.goog/bugzilla/attachment.cgi?id=8330  <--- patch

Code: [Select]

--- gdb-7.7.1.orig/gdb/avr-tdep.c 2014-05-05 23:51:24.000000000 +0200
+++ gdb-7.7.1/gdb/avr-tdep.c 2015-05-24 18:31:50.426950878 +0200
@@ -332,7 +332,10 @@
 {
   ULONGEST addr = unpack_long (type, buf);
 
-  return avr_make_saddr (addr);
+  if (TYPE_DATA_SPACE (type))
+    return avr_make_saddr (addr);
+  else
+    return avr_make_iaddr (addr);
 }
 
 static CORE_ADDRThis patch is for a former GDB version, I've used the same fix for gdb-8.1.1 (the default version used in the AVR-GCC build scripts)
https://github.com/igormiktor/build-avr-gcc  <--- avr-gcc build scripts (includes avr-gdb build, I've built only the avr-gdb and avr-run, then copy them to the Eclipse's avr-gcc toolchain, where the rest of the avr-gcc tools were from various other versions)

[RoGeorge]

Rebuilt avr-gdb using the latest sources.  Turned out the gdb-avr v10.1 doesn't have the "Unable to retrieve disassembly data from backend." error any more.   

Will build all the avr-gcc toolchain from the latest released sources, not just the debugger.

The schematic for the AVR debug-wire programmer/debugger:

Code: [Select]

From any generic (i.e. CH340G)    Rx  o----------------+-------o  Reset pin of the AVR MCU to be debugged
arbitrary baudrate speed capable              D1       |
USB to serial (TTL) adapter       Tx  o-------|<-------+
                                            1N4148


[robca]

Not sure how helpful this is going to be, but Platformio supports Linux and has pretty decent debugger support in general. Supporting HW debug on the AVR seems to still be a dark art, though https://community.platformio.org/t/debugging-without-arduino-hardware/16588