AVRDUDESS 2.19 and AVRDUDE 8.1: Part Selection, Signature Checks and Flash Verification

What AVRDUDESS is

AVRDUDESS is a graphical front-end for avrdude, the command-line programmer that talks to nearly every AVR programmer in existence. avrdude itself is reliable but unforgiving: one wrong switch and it either does nothing or writes the wrong fuse. AVRDUDESS puts the chip list, the programmer list, the memory operations and the fuse bits into a window, shows you the exact avrdude command it is about to run, and keeps the log visible so you can see what actually happened.

It does not replace avrdude and it is not a separate flashing engine — it drives the copy installed on your machine. That is the useful part: everything you learn here transfers directly to a script or a Makefile, because the command is right there in the output pane.

Before you open it

1. Install avrdude and confirm it runs from a terminal: avrdude -?. On Windows, the AVRDUDESS download bundles it. On Linux it is in the distribution repositories (apt install avrdude, dnf install avrdude). On macOS, Homebrew has it.
2. Get driver support for your programmer. USBasp needs libusb and, on Windows, a WinUSB/libusb driver bound to the device. An Arduino used as ISP needs no driver at all, which is why it is the least painful first programmer.
3. Know your target part number. “ATmega328P” and “ATmega328” are different signatures; avrdude refuses to proceed on a mismatch unless told to ignore it, and that refusal is a feature.

Connecting the programmer

In the Programmer box pick the entry that matches your hardware — usbasp, arduino (the classic STK500-v1 protocol used by the ArduinoISP sketch), avrispmkII, jtag2isp, and so on. Then press Detect. If the part comes back as “Unknown” or the log shows a signature read of 0x000000, the wiring is the problem far more often than the software:

• MISO, MOSI, SCK and RESET crossed or shifted by one pin on the 6-pin header.
• Target not powered, or powered from a different supply than the programmer’s reference.
• An ISP clock too fast for the target. A chip running from its internal 1 MHz oscillator cannot be programmed at 8 MHz SPI reliably — drop the programmer’s clock (USBasp has a slow-mode jumper; other programmers expose a -B bit-clock setting).
• Something else driving the SPI bus, or a capacitor on the RESET line large enough to slow the edge.

Reading before writing

Two habits separate a smooth session from a bricked chip:

1. Read the flash and the fuses first and save them. If you later need to know what the factory calibration or fuse setting was, you will have it. On ATtiny and ATmega parts the internal oscillator calibration byte lives in a signature row that avrdude can read but not restore from a normal backup, so note it before you touch anything.
2. Check the current fuse bytes against a calculator before writing new ones. A wrong CKSEL value can leave the chip needing a high-voltage programmer to recover. AVRDUDESS has a fuse calculator that decodes the bits into readable settings — use it read-only first.

Flashing

Select the .hex file, set the memory type (flash, EEPROM), and press Go. The log ends with “avrdude done. Thank you.” on success, and with a verify error and a byte/address report on failure. A typical command line for the same operation looks like this:

avrdude -c usbasp -p m328p -U flash:w:firmware.hex:i

and, with an Arduino as the programmer on a serial port:

avrdude -c arduino -P /dev/ttyUSB0 -b 115200 -p m328p -U flash:w:firmware.hex:i

Note the :i suffix — it tells avrdude the file is Intel hex rather than raw binary. For a raw .bin file the suffix is :r, and the address range has to be given explicitly.

Fuses, in the order that does not brick things

Write the low fuse, then the high fuse, then the extended fuse, and do not change the lock bits unless you mean to. Two rules worth taping to the bench:

• Never disable SPIEN on a part you program over ISP. It removes your own access; recovery needs a parallel or high-voltage programmer.
• Change the clock source before you disconnect and then reconnect at the new speed. A chip switched to an external crystal with no crystal fitted will not answer over ISP at all.

When it refuses to work

• Initialization failed, rc=-1 — the programmer could not enter programming mode. Wiring, target power, or ISP clock too fast.
• Expected signature for ATmega328P is 1E 95 0F — you selected the wrong part, or the target is a different variant (328 vs 328P differ).
• Verification error, mismatch at byte … — a wiring problem that only shows at speed, a target supply sagging during write, or flash written while the lock bits forbid it.
• Device signature = 0x000000 — nothing is talking. Check that the target’s RESET is not held by another circuit and that ground is common.

Why bother with the GUI when the CLI works

Because the GUI remembers. It keeps the last programmer, port and part selected, generates the command for you, and shows the fuse bits as text instead of hex. When you are flashing one board a month, that is the difference between a two-minute job and a twenty-minute re-learning session. When you are flashing the same board a hundred times, take the command it generated and put it in a script — that is the whole point of having the command visible.

References

• avrdude documentation (part of the AVRDUDE project) — programmer list, -U memory specification syntax, -B bit clock, fuse and lock bit handling.
• AVRDUDESS project page — supported programmers, bundled avrdude on Windows, fuse calculator behaviour.
• Microchip, ATmega328P datasheet — fuse bit definitions, CKSEL encoding, SPIEN and lock bit semantics, signature bytes.

Command syntax and fuse behaviour above follow avrdude and the datasheet. No specific board or programmer model is claimed to have been tested here.