AVR (Arduino) Linux Debug? - Page 1
Forum section: electronics / general

author: RoGeorge
author_rank: Super Contributor
timestamp: March 07, 2021, 06:13:15 pm
content: 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: March 08, 2021, 11:00:50 am
content: Couldn't find exactly what I was hoping for, but close.Found an article about a toolpk2cmdthat 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.gzTo 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:# prerequisites libusb-devsudo apt install libusb-dev# compile and install pk2cmdmake linuxsudo make install# add to path pk2cmd so it can be run from any folderPATH=$PATH:/usr/share/pk2export PATH#search how to make the PATH changes persistent after a computer reboot# plug the PICkit into a USB port and test pk2cmdpk2cmd -?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 Succeededpk2cmd 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 isdwdebug. 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-debugTo 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.QuoteApparently 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:# prerequisites libusb-devsudo apt install libusb-dev# compile and install dwdebugmakesudo 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# https://github.com/dcwbrown/dwire-debug/blob/master/Manual.mddwdebugNot a GUI debugger yet, but a great tool, thank you! Much closer to the goal now.

author: cv007
author_rank: Frequent Contributor
timestamp: March 08, 2021, 01:35:56 pm
content: 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.

author: oliviasmithh900
author_rank: Contributor
timestamp: March 08, 2021, 10:56:39 pm
content: 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

author: Nominal Animal
author_rank: Super Contributor
timestamp: March 09, 2021, 11:10:46 am
content: Quote from: oliviasmithh900 on March 08, 2021, 10:56:39 pmWhy stop there? It's much easier to just eat glue and be happy than fight all this difficult technology stuff. Linux, yecch, right?

author: Ian.M
author_rank: Super Contributor
timestamp: March 09, 2021, 01:07:12 pm
content: Quote from: RoGeorge on March 08, 2021, 11:00:50 amI 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/775368Google knows about them - Try:https://www.google.com/search?q=pickit2+pages+missing

author: cv007
author_rank: Frequent Contributor
timestamp: March 09, 2021, 01:13:45 pm
content: 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: March 10, 2021, 03:42:08 am
content: 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 versionsEasy to install and use, a decent looking IDE if you can live with its bloatware.However-v4v5.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 onlyToo 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:dwdebug device ttyUSB0Connected to ATtiny13 on /dev/ttyUSB0 at 76043 baud.0210: f7f1 brne 020e (-1) > u0212: 9701 sbiw r25:r24, $010214: f7d1 brne 020a (-5)0216: 91ff pop r310218: 91ef pop r30021a: 9508 ret021c: 9a36 sbi $6, 6021e: 9936 sbic $6, 60220: cffe rjmp 021e (-1) > gdbserverDidn'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 somethingUse 'target remote :4444'Connection accepted.Got: qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+Got: vMustReplyEmptyGot: Hg0Got: qTStatusGot: ?Got: qfThreadInfoGot: qL1160000000000000000Got: Hc-1Got: qCGot: qAttachedGot: gGot: qL1160000000000000000Error reading command. Error code: 0!0000: c009 rjmp 0014 (+10) > qA 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 connectedand want to use SPI programming software such as AVRDUDE.0000: c009 rjmp 0014 (+10) > qrThese are the registers shown from gdb, after connecting the avr-gdb debugger to the debug server created with dwdebug:Code:avr-gdbGNU gdb (GDB) 8.1.0.20180409-gitCopyright (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 :4444Remote debugging using :4444warning: No executable has been specified and target does not supportdetermining executable automatically. Try using the "file" command.0x00000000 in ?? ()(gdb) info registersr0 0x1 1r1 0x8c 140r2 0x36 54r3 0x47 71r4 0xae 174r5 0x0 0r6 0x0 0r7 0x87 135r8 0xa2 162r9 0xc1 193r10 0x14 20r11 0x0 0r12 0x33 51r13 0xd5 213r14 0x43 67r15 0x7b 123r16 0x9c 156r17 0x2 2r18 0xb9 185r19 0x0 0r20 0xdc 220r21 0x0 0r22 0xa8 168r23 0xc5 197r24 0x83 131r25 0x0 0r26 0x76 118r27 0x0 0r28 0x9e 158r29 0xf0 240r30 0x32 50r31 0x2 2SREG 0x0 0SP 0x1f9f 0x801f9fPC2 0x0 0pc 0x0 0x0(gdb) disconnectEnding remote debugging.(gdb) quitIIRC, 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 ways1. - parallel programming, with lots of wires, good mostly when the MCU was bricked by bad fuses programming2. - 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 pin3. - 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 boards4. - 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 76043in 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 signalDebugWIRE 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 be1. 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:# 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:mavrdude: AVR device initialized and ready to accept instructionsReading | ################################################## | 100% 0.01savrdude: Device signature = 0x1e9007 (probably t13)avrdude: reading input file "0xf7"avrdude: writing hfuse (1 bytes):Writing | ################################################## | 100% 0.02savrdude: 1 bytes of hfuse writtenavrdude: verifying hfuse memory against 0xf7:avrdude: load data hfuse data from input file 0xf7:avrdude: input file 0xf7 contains 1 bytesavrdude: reading on-chip hfuse data:Reading | ################################################## | 100% 0.00savrdude: verifying ...avrdude: 1 bytes of hfuse verifiedavrdude: 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 diagramsSorry for the WOT.

author: Ian.M
author_rank: Super Contributor
timestamp: March 10, 2021, 10:11:24 am
content: 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: March 10, 2021, 12:42:46 pm
content: Quote from: Ian.M on March 10, 2021, 10:11:24 amVery 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:lsusb | grep -i pickit2Bus 003 Device 031: ID 04d8:0033 Microchip Technology, Inc. PICkit2

author: Ian.M
author_rank: Super Contributor
timestamp: March 10, 2021, 01:07:09 pm
content: 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: March 13, 2021, 04:52:41 am
content: It works, it works!!!Eclipse IDE -> avr-gdb -> dwdebug gdb server -> CH340G USB to serial adapter -> 1 debug wire -> ATtiny13 Reset pin 1

author: RoGeorge
author_rank: Super Contributor
timestamp: March 15, 2021, 03:17:29 pm
content: 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 manually3. - 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/360831https://r5zzq45g7w7fzq2alxlppe6hsa--sourceware-org.translate.goog/bugzilla/show_bug.cgi?id=13519https://r5zzq45g7w7fzq2alxlppe6hsa--sourceware-org.translate.goog/bugzilla/attachment.cgi?id=8330<--- patchCode:--- gdb-7.7.1.orig/gdb/avr-tdep.c2014-05-05 23:51:24.000000000 +0200+++ gdb-7.7.1/gdb/avr-tdep.c2015-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)

author: RoGeorge
author_rank: Super Contributor
timestamp: March 15, 2021, 06:41:22 pm
content: 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:From any generic (i.e. CH340G) Rx o----------------+-------o Reset pin of the AVR MCU to be debuggedarbitrary baudrate speed capable D1 |USB to serial (TTL) adapter Tx o-------|<-------+1N4148

author: robca
author_rank: Frequent Contributor
timestamp: March 15, 2021, 09:21:30 pm
content: 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, thoughhttps://community.platformio.org/t/debugging-without-arduino-hardware/16588

author: RoGeorge
author_rank: Super Contributor
timestamp: July 15, 2024, 12:39:40 pm
content: Some other topic reminded me of this thread, still using that setupMeanwhile:- found out that the diode in series with the Tx can be as well a 1k resistor instead of a diode- forgot how to use the setup, so I'll let some notes about how to debugWIRE with it:Code:- inside the VM- open Eclipse Embedded- Project -> Close Project# create a new project- File -> New -> Project... (do NOT select C/C++ Project)- select either 'C Project' or 'C++ Project' (do NOT select 'C/C++ Project') -> Next- AVR Cross Target Application -> Empty Project -> AVR-GCC Toolchain- type a project name -> Next- select both Debug and Release- to DOUBLE CHECK click Advanced settings...- it MUST show 'Resources' first, then 'AVR'. MUST have 'AVR' listed, or else it's the wrong type of project and it WON'T work- click AVR -> AVRdude- in the Programmer tab, from the drop-down box select pickit2- click 'Apply and Close'- click Next- select MCU Type: ATtiny13- select MCU Frequency (Hz): 9600000- click Finish# write the C code- right click on the newly created project name -> New -> Source File- type the name: main.c- Template: Default C source template- type the code:#include <avr/io.h>// #include <util/delay.h>#defineDELAY200Uint main(void){volatile register int i_var;DDRB |= _BV(PB1);//PB1 as Outputvolatile unsigned int wait_cnt = DELAY;while(1){i_var = wait_cnt;while(i_var--);// i = i+2;PORTB |= _BV(PB1);//PB1 High// _delay_ms(1);//wait 1 millisecondsi_var = wait_cnt;while(i_var--);// i=i+3;PORTB &= ~_BV(PB1);//PB1 Low// _delay_ms(1);//wait 1 millisecondsi_var = i_var+5;}}- don't bother with warnings, they'll vanish after save- save# build- click the Hammer icon (Build debug for project yyy)# debug- in the VM, start the dbg server, open a terminal and typekubuntu@kubuntu2004:~$ dwdebug gdbserver device ttyUSB0Connected to ATtiny13 on /dev/ttyUSB0 at 9495 baud.Target ready, waiting for GDB connection.Info : avrchip: hardware has somethingUse 'target remote :4444'- click the Debug icon- double click 'GDB Hardware Debugging (or drop down from the debugging icon and click 'Debug Configurations...'- click yyy (current proj name)- in the "C/C++ Application:" text box click 'Browse...' and select the corresponding .elf file, e.g.:/home/kubuntu/eclipse-workspace/ATtiny13_dw_AC_2024-07-15_v2/Debug/ATtiny13_dw_AC_2024-07-15_v2.elf- click the second tab, 'Debugger', in the already opened window 'Debug Configurations...'- in the GDB command browse for/usr/local/avr-10.1/bin/avr-gdb- in the 'GDB Connection String' typelocalhost:4444- click Apply, then click Debug(the last compiled .elf code will be written into MCU through debugWIRE, no need for pickit2)# to make sure all was loaded and can execute OK- double click a C line to put a breakpoint, run to it- !!! if no variables are listed in the Variables, then make sure in Project Properties the "Debbuging" is set to use "dwarf-2 (Experimenta)" Debugging Info Format- ??? NOPE sometimes still doesn't show the variables, but print variable name in the dbg window works ??? use "stabs+ (stabs + gdb extensions)"- use "stabs+ (stabs + gdb externsions)" seems to be working where dwarf-2 didn't, do NOT confuse stabs+ with "stabs (avr-gdb / Insight)" or else no debug symbols for variables# after stopping the debug, in the terminal window exit from dwdebug with "qr" (quit and let the MCU run)0052: 0000 nop > qrkubuntu@kubuntu2004:~$# for next debug session with Eclipse, the dwdebug server must be started again withkubuntu@kubuntu2004:~$ dwdebug gdbserver device ttyUSB0# or, for a manual debug from the command line, start dwdebug in interactive modekubuntu@kubuntu2004:~$ dwdebug device ttyUSB0- to switch from debugWIRE (CH340) back to the ISP mode (pickit2), in a terminal in VM, exit from dwdebug into ISP mode using "qi"kubuntu@kubuntu2004:~$ dwdebug device ttyUSB0Connected to ATtiny13 on /dev/ttyUSB0 at 9495 baud.0010: c050 rjmp 00b2 (+81) > qi# now, do NOT cut the MCU power, connect the pickit2 header end deassert the DWEN fuse using avrdude# kubuntu@kubuntu2004:~$ avrdude -p t13 -c pickit2 -U hfuse:w:0xff:m# power down the MCU, and now the MCU is in ISP mode