| [Top] | +[Contents] | +[Index] | +[ ? ] | +
| [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
AVRDUDE - AVR Downloader Uploader - is a program for downloading and +uploading the on-chip memories of Atmel’s AVR microcontrollers. It can +program the Flash, EEPROM, and where supported by the programmer, lock +bits, fuses that hold the microcontroller’s configuration and other +memories that the part might have. +
+ + + + +AVRDUDE can be used via the command line to read or write chip memories +(eeprom, flash, fuses, lock bits) and read memories such as signature or +calibration bytes; the same can be achieved via an interactive terminal +mode. Using AVRDUDE from the command line works well for programming the +entire memory of the chip from the contents of a file, while interactive mode +is useful for exploring memory contents, modifying individual bytes of +eeprom, programming fuse/lock bits, etc. +
+ + + + +Programming a microcontroller either requires a physical programmer that
+sits between the target chip and the PC running AVRDUDE, or a bootloader
+program on the target chip that is then directly connected to the PC to be
+served by AVRDUDE. Currently, AVRDUDE knows about 373 parts
+and 184 programmers, though not every programmer can
+deal with every part. One noteworthy programmer is dryrun, which
+allows one to explore the AVRDUDE command-line and terminal without
+needing to have, or connect, a real physical programmer. Similarly,
+dryboot allows exploring how to communicate with a bootloader
+without connecting an AVR part.
+
AVRDUDE supports the following basic programmer types: Atmel’s STK500, +Atmel’s AVRISP and AVRISP mkII devices, +Atmel’s STK600, +Atmel’s JTAG ICE (the original one, mkII, and 3), appnote +avr910, appnote avr109 (including the AVR Butterfly), +serial bit-bang adapters, +and the PPI (parallel port interface). PPI represents a class +of simple programmers where the programming lines are directly +connected to the PC parallel port. Several pin configurations exist +for several variations of the PPI programmers, and AVRDUDE can be +configured to work with them by either specifying the appropriate +programmer on the command line or by creating a new entry in its +configuration file. All that’s usually required for a new entry is to +tell AVRDUDE which pins to use for each programming function. +
+A number of equally simple bit-bang programming adapters that connect +to a serial port are supported as well, among them the popular +Ponyprog serial adapter, and the DASA and DASA3 adapters that used to +be supported by uisp(1). Note that these adapters are meant to be +attached to a physical serial port. Connecting to a serial port +emulated on top of USB is likely to not work at all, or to work +abysmally slow. +
+If you happen to have a Linux system with at least 4 hardware GPIOs +available (like almost all embedded Linux boards) you can do without any +additional hardware - just connect them to the SDO, SDI, RESET and SCK +pins of the AVR’s SPI interface and use the linuxgpio programmer +type. Older boards might use the labels MOSI for SDO and MISO for SDI. It bitbangs +the lines using the Linux sysfs GPIO interface. Of course, care should +be taken about voltage level compatibility. Also, although not strictly +required, it is strongly advisable to protect the GPIO pins from +overcurrent situations in some way. The simplest would be to just put +some resistors in series or better yet use a 3-state buffer driver like +the 74HC244. Have a look at +https://kolev.info/blog/2013/01/06/avrdude-linuxgpio/ for a more +detailed tutorial about using this programmer type. +
+Under a Linux installation with direct access to the SPI bus and GPIO
+pins, such as would be found on a Raspberry Pi, the “linuxspi”
+programmer type can be used to directly connect to and program a chip
+using the built in interfaces on the computer. The requirements to use
+this type are that an SPI interface is exposed along with one GPIO
+pin. The GPIO serves as the reset output since the Linux SPI drivers
+do not hold chip select down when a transfer is not occuring and thus
+it cannot be used as the reset pin. A readily available level
+translator should be used between the SPI bus/reset GPIO and the chip
+to avoid potentially damaging the computer’s SPI controller in the
+event that the chip is running at 5 V and the SPI runs at 3.3 V. The
+GPIO chosen for reset can be configured in the avrdude configuration
+file using the reset entry under the linuxspi programmer, or
+directly in the port specification. An external pull-up resistor
+should be connected between the AVR’s reset pin and Vcc. If Vcc is not
+the same as the SPI voltage, this should be done on the AVR side of
+the level translator to protect the hardware from damage.
+
On a Raspberry Pi, header J8 provides access to the SPI and GPIO +lines. +
+Typically, pins 19, 21, and 23 are SPI SDO, SDI, and SCK, while +pins 24 and 26 would serve as CE outputs. So, close to these pins +is pin 22 as GPIO25 which can be used as /RESET, and pin 25 can +be used as GND. +
+A typical programming cable would then look like: +
+J8 pin | ISP pin | Name | |
|---|---|---|---|
21 | 1 | SDI | |
- | 2 | Vcc - leave open | |
23 | 3 | SCK | |
19 | 4 | SDO | |
22 | 5 | /RESET | |
25 | 6 | GND |
The -P port option defaults to
+/dev/spidev0.0:/dev/gpiochip0 for this programmer. And, mind the
+3.3 V voltage level of the Raspberry Pi!
+
The STK500, JTAG ICE, avr910, and avr109/butterfly use the serial port to communicate with the PC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+The STK600, JTAG ICE mkII/3, AVRISP mkII, USBasp, avrftdi (and derivatives), and USBtinyISP
+programmers communicate through the USB, using libusb as a
+platform abstraction layer.
+The avrftdi adds support for the FT2232C/D, FT2232H, and FT4232H devices. These all use
+the MPSSE mode, which has a specific pin mapping. Bit 0 (the lsb of the byte in the config
+file) is SCK. Bit 1 is SDO, and Bit 2 is SDI. Bit 3 usually reset. The 2232C/D parts
+are only supported on interface A, but the H parts can be either A or B (specified by the
+usbdev config parameter).
+The STK500, STK600, JTAG ICE, and avr910 contain on-board logic to control the programming of the target
+device.
+
+
+The avr109 bootloader implements a protocol similar to avr910, but is
+actually implemented in the boot area of the target’s flash, as
+opposed to being an external device.
+The fundamental difference between the two types lies in the
+protocol used to control the programmer. The avr910 protocol is very
+simplistic and can easily be used as the basis for a simple, home made
+programmer since the firmware is available online. On the other hand,
+the STK500 protocol is more robust and complicated and the firmware is
+not openly available.
+The JTAG ICE also uses a serial communication protocol which is similar
+to the STK500 firmware version 2 one. However, as the JTAG ICE is
+intended to allow on-chip debugging as well as memory programming, the
+protocol is more sophisticated.
+(The JTAG ICE mkII protocol can also be run on top of USB.)
+Only the memory programming functionality of the JTAG ICE is supported
+by AVRDUDE.
+
+
+
+
+
+
+
+
+
+For the JTAG ICE mkII/3, JTAG, debugWIRE and ISP mode are supported, provided
+it has a firmware revision of at least 4.14 (decimal).
+See below for the limitations of debugWIRE.
+For ATxmega devices, the JTAG ICE mkII/3 is supported in PDI mode (Xmega
+parts), provided it has a revision 1 hardware and firmware version of at
+least 5.37 (decimal).
+
The Atmel-ICE (ARM/AVR) is supported (JTAG, PDI, debugWIRE, ISP, UPDI). +
+ + +Atmel’s XplainedPro boards, using EDBG protocol (CMSIS-DAP compliant), are +supported by the “jtag3” programmer type. +
+ + +Atmel’s XplainedMini boards, using mEDBG protocol, are also +supported by the “jtag3” programmer type. +
+ + + +The AVR Dragon is supported in all modes (ISP, JTAG, PDI, HVSP, PP, debugWIRE).
+When used in JTAG and debugWIRE mode, the AVR Dragon behaves similar to a
+JTAG ICE mkII, so all device-specific comments for that device
+will apply as well.
+When used in ISP and PDI mode, the AVR Dragon behaves similar to an
+AVRISP mkII (or JTAG ICE mkII in ISP mode), so all device-specific
+comments will apply there.
+In particular, the Dragon starts out with a rather fast ISP clock
+frequency, so the -B bitclock
+option might be required to achieve a stable ISP communication.
+For ATxmega devices, the AVR Dragon is supported in PDI mode, provided it
+has a firmware version of at least 6.11 (decimal).
+
Wiring boards (e.g. Arduino Mega 2560 Rev3) are supported, utilizing
+STK500 V2.x protocol, but a simple DTR/RTS toggle to set the boards
+into programming mode. The programmer type is “wiring”. Note that
+the -D option will likely be required in this case, because the
+bootloader will rewrite the program memory, but no true chip erase can
+be performed.
+
Serial bootloaders that run a skeleton of the STK500 1.x protocol are supported via +their own programmer type specification “arduino”. This programmer works for +the Arduino Uno Rev3 or any AVR that runs the Optiboot bootloader. +The number of connection retry attempts can be specified as an +extended parameter. See the section on +extended parameters +below for details. +
+ + + +Urprotocol is a leaner version of the STK500 1.x protocol that is designed
+to be backwards compatible with STK500 v1.x; it allows bootloaders to be
+much smaller, e.g., as implemented in the urboot project
+https://github.com/stefanrueger/urboot. The programmer type “urclock”
+caters for these urboot bootloaders. Owing to its backward compatibility,
+bootloaders that can be served by the arduino programmer can normally also
+be served by the urclock programmer. This may require specifying the size
+of (to AVRDUDE) unknown bootloaders in bytes using the -x
+bootsize=<n> option, which is necessary for the urclock programmer to
+enable it to protect the bootloader from being overwritten. If an unknown
+bootloader has EEPROM read/write capability then the option -x eepromrw
+informs avrdude -c urclock of that capability.
+
The BusPirate is a versatile tool that can also be used as an AVR programmer. +A single BusPirate can be connected to up to 3 independent AVRs. See +the section on +extended parameters +below for details. +
+ +The USBasp ISP, USBtinyISP and CH341A adapters are also supported, provided
+AVRDUDE has been compiled with libusb support.
+They former two feature simple firmware-only USB implementations, running on
+an ATmega8 (or ATmega88), or ATtiny2313, respectively.
+CH341A programmers connect directly to the AVR target. Their SPI bit clock
+is approximately 1.7 MHz and cannot be changed. As a consequence, the
+AVR target must have a CPU frequency of 6.8 MHz or more: factory-set
+AVR parts, which typically run on an internal oscillator between 1 MHz and
+1.6 MHz, cannot be programmed using -c ch341a.
+
The Atmel DFU bootloader is supported in both, FLIP protocol version 1 +(AT90USB* and ATmega*U* devices), as well as version 2 (Xmega devices). +See below for some hints about FLIP version 1 protocol behaviour. +
+ + + + + + + + +The MPLAB(R) PICkit 4/5/Basic and MPLAB(R) SNAP are supported in JTAG, TPI, ISP, PDI and UPDI mode.
+
+The Curiosity Nano board is supported in UPDI mode. It is dubbed “PICkit on
+Board”, thus the name pkobn_updi.
+
SerialUPDI programmer implementation is based on Microchip’s +pymcuprog (https://github.com/microchip-pic-avr-tools/pymcuprog) +utility, but it also contains some performance improvements included in +Spence Konde’s DxCore Arduino core (https://github.com/SpenceKonde/DxCore). +In a nutshell, this programmer consists of simple USB-to-UART adapter, diode +and couple of resistors. It uses serial connection to provide UPDI interface. +See section SerialUPDI Programmer for more details and known issues. +
+The jtag2updi programmer is supported, +and can program AVRs with a UPDI interface. +Jtag2updi is just a firmware that can be loaded onto an AVR, +which enables it to interface with avrdude using the jtagice mkii protocol +via a serial link (https://github.com/ElTangas/jtag2updi). +
+ + +The Micronucleus bootloader is supported for both protocol version V1 and
+V2. As the bootloader does not support reading from flash memory, use the
+-V option to prevent AVRDUDE from verifying the flash memory. See
+the section on extended parameters below for Micronucleus specific
+options.
+
The Teensy bootloader is supported for all AVR boards.
+As the bootloader does not support reading from flash memory,
+use the -V option to prevent AVRDUDE from verifying the flash memory.
+See the section on extended parameters
+below for Teensy specific options.
+
List of Programmers holds a full listing of known programmers. +
+| 1.1 History and Credits | + |
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Enter terminal, display part parameters, modify EEPROM, perform a chip erase and quit: +
+ +
|
Program the fuse bits of an ATmega328P with a fuse calculator +
First display the factory defaults, then consult an external fuse +calculator, select the ATmega328P part, find above settings, note the +ensuinig new values for the three fuses and reprogram: +
+
|
Program the fuse bits of an ATmega328P with the config command +
+
|
Show and change registers +
+
|
Show register file of a classic part +
+
|
The following example demonstrates negative address and length
+bytes, and the fill form of the write command using an
+ellipis ... where the last data item provided is used to fill up the
+indicated memory range.
+
|
Disassembe the flash contents of an ATtiny13A, write
+the output to file blink.S, compile to ‘blink.elf‘ and verify that
+the flash contents of the ATtiny13A is the same as the one given by the
+compiled blink.elf. Then cat the disassembled blink.S
+to stdout.
+
|
Mixing terminal commands and -U memory operations: the
+example below burns a bootloader, uses a terminal line to write
+application data to flash, loads the application, configures the brownout
+detection level to 2.7 V and, finally, stores the full flash as new hex
+file. Note the use of different quotation marks in bash to pass the
+terminal command lines as single entity to AVRDUDE.
+
|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
AVRDUDE reads a configuration file upon startup which describes all of +the parts and programmers that it knows about. The advantage of this is +that if you have a chip that is not currently supported by AVRDUDE, you +can add it to the configuration file without waiting for a new release +of AVRDUDE. Likewise, if you have a parallel port programmer that is +not supported, chances are that you can copy an +existing programmer definition and, with only a few changes, make your +programmer work. +
+AVRDUDE first looks for a system wide configuration file in a platform
+dependent location. On Unix, this is usually
+/usr/local/etc/avrdude.confSee section Unix, whilst on Windows it is usually in the
+same location as the executable file. The full name of this file can be
+specified using the ‘-C’ command line option. After parsing the system wide
+configuration file, AVRDUDE looks for a per-user configuration
+file to augment or override the system wide defaults. On Unix, the
+per-user file is ${XDG_CONFIG_HOME}/avrdude/avrdude.rc, whereas
+if ${XDG_CONFIG_HOME} is either not set or empty,
+${HOME}/.config/ is used instead. If that does not exist
+.avrduderc within the user’s home directory is used. On Windows,
+this file is the avrdude.rc file located in the same directory as
+the executable.
+
| 4.1 AVRDUDE Defaults | + | |
| 4.2 Programmer Definitions | + | |
| 4.3 Serial Adapter Definitions | + | |
| 4.4 Part Definitions | + | |
| 4.5 Other Notes | + |
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
avrdude_conf_version = "build-time-version";Automatically set during the build process. +
+default_parallel = "default-parallel-device";Assign the default parallel port device. Can be overridden using the +‘-P’ option. +
+default_serial = "default-serial-device";Assign the default serial port device. Can be overridden using the +‘-P’ option. +
+default_linuxgpio = "default-linuxgpio-device";Assign the default gpiochip for linuxgpio’s libgpiod mode, +e.g. "gpiochip0". Ignored for linuxgpio’s sysfs mode. Can be overridden +using the ‘-P’ option. +
+default_programmer = "default-programmer-id";Assign the default programmer id. Can be overridden using the ‘-c’ +option. +
+default_baudrate = "default-baudrate";Assign the default baudrate value that will be used if the programmer doesn’t
+provide its specific baudrate entry. Can be overridden using the ‘-b’
+option.
+
default_bitclock = "default-bitclock";Assign the default bitclock value. Can be overridden using the ‘-B’ +option. +
+allow_subshells = no;Whether or not AVRDUDE’s interactive terminal is allowed to use subshell
+! commands. This defaults to no for security reasons, e.g., in the
+rare case avrdude -t is set up with attached hardware to provide a
+web service, remote ssh or a login on a PC instead of a shell, say, for
+demo or training purposes. In almost all other cases this can be
+overridden in the per-user avrddude.rc or .avrduderc
+configuration file with yes.
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
The format of the programmer definition is as follows: +
+programmer
+ parent <id> # optional parent
+ id = <id1> [, <id2> ... ]; # <idN> are quoted strings
+ desc = <description>; # quoted string
+ type = <type>; # programmer type, quoted string
+ # list known types with -c ?type
+ prog_modes = PM_<i/f> {| PM_<i/f>} # interfaces, e.g., PM_SPM|PM_PDI (1)
+ is_serialadapter = <yes|no> # programmer is also a serialadapter
+ extra_features = HAS_<fea> {| HAS_<fea>} # extra features, e.g., HAS_SUFFER (2)
+ connection_type = parallel | serial | usb | spi
+ baudrate = <num>; # baudrate for avr910-programmer
+ vcc = <pin1> [, <pin2> ... ]; # pin number(s) (3)
+ buff = <pin1> [, <pin2> ... ]; # pin number(s)
+ reset = <pin>; # pin number
+ sck = <pin>; # pin number
+ sdo|pico = <pin>; # pin number
+ sdi|poci = <pin>; # pin number
+ tck = <pin>; # pin number
+ tdi = <pin>; # pin number
+ tdo = <pin>; # pin number
+ tms = <pin>; # pin number
+ errled = <pin>; # pin number
+ rdyled = <pin>; # pin number
+ pgmled = <pin>; # pin number
+ vfyled = <pin>; # pin number
+ usbvid = <hexnum>; # USB vendor ID
+ usbpid = <hexnum> [, <hexnum> ...]; # USB product ID (4)
+ usbdev = <interface>; # USB interface or other device info
+ usbvendor = <vendorname>; # USB Vendor Name
+ usbproduct = <productname>; # USB Product Name
+ usbsn = <serialno>; # USB Serial Number
+ hvupdi_support = <num> [, <num>, ... ]; # HV support for enabling UPDI
+;
+ |
If a parent is specified, all settings of it (except its ids) are used for the new +programmer. These values can be changed by new setting them for the new programmer. +
+Notes +
+PM_SPM: Bootloaders, self-programming with SPM opcodes or NVM Controllers
+
+
+PM_TPI: Tiny Programming Interface (t4, t5, t9, t10, t20, t40, t102, t104)
+
+
+PM_ISP: SPI programming for In-System Programming (almost all classic parts)
+
+
+PM_PDI: Program and Debug Interface (xmega parts)
+
+
+PM_UPDI: Unified Program and Debug Interface
+
+
+PM_HVSP: High Voltage Serial Programming (some classic parts)
+
+
+PM_HVPP: High Voltage Parallel Programming (most non-HVSP classic parts)
+
+
+PM_debugWIRE: Simpler alternative to JTAG (a subset of HVPP/HVSP parts)
+
+
+PM_JTAG: Joint Test Action Group standard (some classic parts)
+
+
+PM_JTAGmkI: Subset of PM_JTAG, older parts, Atmel ICE mkI
+
+
+PM_XMEGAJTAG: JTAG, some XMEGA parts
+
+
+PM_AVR32JTAG: JTAG for 32-bit AVRs
+
+
+PM_aWire: AVR32 parts
+HAS_SUFFER: Only present on Xplained Mini/Nano programmers;
+ the Super User Fantastic Feature Enable Register allows the user to modify
+ the behavior of the mEDBG programmer/debugger chip, see the Xplained Mini/Nano
+ documentation for more information
+
+
+HAS_VTARG_SWITCH: Programer has a programmable target power switch
+
+
+HAS_VTARG_READ: Programmer can read the target voltage
+
+
+HAS_VTARG_ADJ: Programmer has an adjustable target power source that can
+ be controlled with Avrdude
+
+
+HAS_FOSC_ADJ: Programmer has a programable frequency generator that
+ can clock an AVR directly through its XTAL1 pin
+
+
+HAS_VAREF_ADJ: Programmer has an adjustable analog reference voltage that
+ can be controlled with Avrdude
+~<num>; to invert
+the polarity of all pins in a list use ~(<num1> [, <num2> ... ])
+
+The following programmer types are currently implemented: +
+arduino | Arduino programmer for bootloading |
avr910 | Serial programmer using protocol from appnote AVR910 |
avrftdi | Interface to the MPSSE Engine of FTDI chips using libftdi |
avrftdi_jtag | libftdi JTAG interface |
buspirate | Bus Pirate’s SPI interface |
buspirate_bb | Bus Pirate’s bitbang interface |
butterfly | Atmel Butterfly evaluation board (AVR109, AVR911) |
butterfly_mk | Mikrokopter.de Butterfly |
ch341a | Chip CH341A: AVR must have min F_CPU of 6.8 MHz |
dryrun | Dryrun programmer for testing avrdude |
dragon_dw | Atmel AVR Dragon in debugWire mode |
dragon_hvsp | Atmel AVR Dragon in HVSP mode |
dragon_isp | Atmel AVR Dragon in ISP mode |
dragon_jtag | Atmel AVR Dragon in JTAG mode |
dragon_pdi | Atmel AVR Dragon in PDI mode |
dragon_pp | Atmel AVR Dragon in PP mode |
flip1 | FLIP USB DFU protocol version 1 (doc7618) |
flip2 | FLIP USB DFU protocol version 2 (AVR4023) |
ftdi_syncbb | FT245R/FT232R synchronous bit-bang programmer |
jtagmki | Atmel JTAG ICE mkI |
jtagmkii | Atmel JTAG ICE mkII |
jtagmkii_avr32 | Atmel JTAG ICE mkII in AVR32 mode |
jtagmkii_dw | Atmel JTAG ICE mkII in debugWire mode |
jtagmkii_isp | Atmel JTAG ICE mkII in ISP mode |
jtagmkii_pdi | Atmel JTAG ICE mkII in PDI mode |
jtagmkii_updi | Atmel JTAG ICE mkII in UPDI mode |
jtagice3 | Atmel JTAGICE3 |
jtagice3_pdi | Atmel JTAGICE3 in PDI mode |
jtagice3_updi | Atmel JTAGICE3 in UPDI mode |
jtagice3_dw | Atmel JTAGICE3 in debugWire mode |
jtagice3_isp | Atmel JTAGICE3 in ISP mode |
jtagice3_tpi | Atmel JTAGICE3 in TPI mode |
linuxgpio | GPIO bitbanging using the Linux libgpiod or sysfs interface (not available) |
linuxspi | SPI using Linux spidev driver (not available) |
micronucleus | Micronucleus Bootloader |
par | Parallel port bitbanging |
pickit2 | Microchip’s PICkit2 Programmer |
pickit5 | Microchip’s PICkit 5 Programmer/Debugger |
serbb | Serial port bitbanging |
serialupdi | Driver for SerialUPDI programmers |
serprog | Program via the Serprog protocol from Flashrom |
stk500 | Atmel STK500 Version 1.x firmware |
stk500generic | Atmel STK500, autodetect firmware version |
stk500v2 | Atmel STK500 Version 2.x firmware |
stk500hvsp | Atmel STK500 V2 in high-voltage serial programming mode |
stk500pp | Atmel STK500 V2 in parallel programming mode |
stk600 | Atmel STK600 |
stk600hvsp | Atmel STK600 in high-voltage serial programming mode |
stk600pp | Atmel STK600 in parallel programming mode |
teensy | Teensy Bootloader |
urclock | Urclock programmer for urboot bootloaders (arduino compatible) |
usbasp | USBasp programmer, see http://www.fischl.de/usbasp/ |
usbtiny | Usbtiny programmer (also as bootloading protocol) |
wiring | Bootloader using the STK500v2 protocol (AVR068) |
xbee | XBee Series 2 Over-The-Air (XBeeBoot) |
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
The format of a serial adapter definition is as follows: +
+serialadapter + parent <id> # optional serialadapter or programmer parent + id = <id1> [, <id2> ... ]; # <idN> are quoted strings + desc = <description>; # quoted string + baudrate = <num>; # optional default baudrate, eg, in .avrduderc + usbvid = <hexnum>; # USB vendor ID + usbpid = <hexnum> [, <hexnum> ...]; # list of USB product IDs + usbsn = <serialno>; # USB Serial Number in per-user .avrduderc +; + |
Technically, a serialadapter is implemented as programmer
+that has only USB parameters defined. It can be used for a -P
+<serialadapter>[:<serial number>] port specification instead of the
+created serial port. Per-user serialadapter definitions in
+~/.avrduderc or avrdude.rc files can add a serial number to
+assign a particular board a specific id and default communication baud rate:
+
serialadapter parent "ft232r" + id = "bike-shed-door"; + usbsn = "0123456789"; + baudrate = 250000; +; + |
This is particularly useful for programming through a bootloader as it
+allows specifying the port as -P bike-shed-door rather than having
+to figure out which serial port name the operating system has assigned to
+the plugged in bike-shed-door board at runtime. Note that each programmer
+that defines usbpid and sets is_serialadapter = yes can also
+be utilised as a serialadapter.
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
part
+ desc = <description>; # quoted string, the long part name, eg, "ATmega328p"
+ id = <id>; # quoted string, normally an abbreviated part name
+ variants = <str1> [, <str2> ...]; # quoted strings, each starts so "<alt-name>: ..."
+ family_id = <id>; # quoted string, e.g., "megaAVR" or "tinyAVR"
+ prog_modes = PM_<i/f> {| PM_<i/f>} # interfaces, e.g., PM_SPM|PM_ISP|PM_HVPP|PM_debugWIRE
+ mcuid = <num>; # unique id in 0..2039 for 8-bit AVRs
+ archnum = <num>; # avr-gcc architecture number; -1 if not 8-bit AVR
+ n_interrupts = <num>; # number of interrupts, used for vector bootloaders
+ n_page_erase = <num>; # if set, number of pages erased during SPM erase
+ n_boot_sections = <num>; # Number of boot sections
+ boot_section_size = <num>; # Size of (smallest) boot section, if any
+ hvupdi_variant = <num>; # numeric: -1 or 0..3; how to enable UPDI with HV
+ stk500_devcode = <num>; # numeric
+ avr910_devcode = <num>; # numeric
+ is_at90s1200 = <yes/no>; # AT90S1200 part
+ signature = <num> <num> <num>; # signature bytes
+ usbpid = <num>; # DFU USB PID
+ chip_erase_delay = <num>; # microseconds
+ reset = dedicated | io;
+ retry_pulse = reset | sck;
+ # STK500 parameters (parallel programming IO lines)
+ pagel = <num>; # page load pin name in hex, e.g., 0xD7
+ bs2 = <num>; # byte select 2 pin name in hex, e.g., 0xA0
+ serial = <yes/no>; # can use serial programming
+ parallel = <yes/no/pseudo>; # can use parallel programming
+ # STK500v2 parameters, to be taken from Atmel's ATDF files
+ timeout = <num>;
+ stabdelay = <num>;
+ cmdexedelay = <num>;
+ synchloops = <num>;
+ bytedelay = <num>;
+ pollvalue = <num>;
+ pollindex = <num>;
+ predelay = <num>;
+ postdelay = <num>;
+ pollmethod = <num>;
+ hvspcmdexedelay = <num>;
+ # STK500v2 HV programming parameters, from ATDFs
+ pp_controlstack = <num>, <num>, ...; # PP only
+ hvsp_controlstack = <num>, <num>, ...; # HVSP only
+ flash_instr = <num>, <num>, <num>;
+ eeprom_instr = <num>, <num>, ...;
+ hventerstabdelay = <num>;
+ progmodedelay = <num>; # PP only
+ latchcycles = <num>;
+ togglevtg = <num>;
+ poweroffdelay = <num>;
+ resetdelayms = <num>;
+ resetdelayus = <num>;
+ hvleavestabdelay = <num>;
+ resetdelay = <num>;
+ synchcycles = <num>; # HVSP only
+ chiperasepulsewidth = <num>; # PP only
+ chiperasepolltimeout = <num>;
+ chiperasetime = <num>; # HVSP only
+ programfusepulsewidth = <num>; # PP only
+ programfusepolltimeout = <num>;
+ programlockpulsewidth = <num>; # PP only
+ programlockpolltimeout = <num>;
+ # debugWIRE and/or JTAG ICE mkII parameters, also from ATDF files
+ allowfullpagebitstream = <yes/no>;
+ enablepageprogramming = <yes/no>;
+ idr = <num>; # IO addr of IDR (OCD) reg
+ rampz = <num>; # IO addr of RAMPZ reg
+ spmcr = <num>; # mem addr of SPMC[S]R reg
+ eecr = <num>; # mem addr of EECR reg
+ eind = <num>; # mem addr of EIND reg
+ mcu_base = <num>; # MCU control block in ATxmega devices
+ nvm_base = <num>; # NVM controller in ATxmega devices
+ ocd_base = <num>; # OCD module in AVR8X/UPDI devices
+ syscfg_base = <num>; # Chip revision ID in AVR8X/UPDI devices
+ ocdrev = <num>; # JTAGICE3 parameter from ATDF files
+ pgm_enable = <instruction format>;
+ chip_erase = <instruction format>;
+ # parameters for bootloaders
+ autobaud_sync = <num>; # autobaud detection byte, default 0x30
+ factory_fcpu = <num>; # F_CPU in Hz on reset and factory-set fuses
+
+ memory <memstr>
+ paged = <yes/no>; # yes/no (flash of classic parts only)
+ offset = <num>; # memory offset
+ size = <num>; # bytes
+ page_size = <num>; # bytes
+ num_pages = <num>; # numeric
+ initval = <num>; # factory setting of fuses and lockbits
+ bitmask = <num>; # bits used (only in fuses and lockbits)
+ n_word_writes = <num>; # TPI only: if set, number of words to write
+ min_write_delay = <num>; # micro-seconds
+ max_write_delay = <num>; # micro-seconds
+ readback = <num> <num>; # pair of byte values
+ readback_p1 = <num>; # byte value (first component)
+ readback_p2 = <num>; # byte value (second component)
+ pwroff_after_write = <yes/no>; # yes/no
+ mode = <num>; # STK500 v2 file parameter from ATDF files
+ delay = <num>; # "
+ blocksize = <num>; # "
+ readsize = <num>; # "
+ read = <instruction format>;
+ write = <instruction format>;
+ read_lo = <instruction format>;
+ read_hi = <instruction format>;
+ write_lo = <instruction format>;
+ write_hi = <instruction format>;
+ loadpage_lo = <instruction format>;
+ loadpage_hi = <instruction format>;
+ writepage = <instruction format>;
+ ;
+;
+ |
If any of the above parameters are not specified, the default value of 0
+is used for numerics (except for mcuid, hvupdi_variant,
+ocdrev, initval and bitmask, all of which default to
+-1, and for autobaud_sync which defaults to 0x30) or the empty
+string "" for string values. If a required parameter is left empty,
+AVRDUDE will complain. Almost all occurrences of numbers (with the
+exception of pin numbers and where they are separated by space, e.g., in
+signature and readback) can also be given as simple expressions involving
+arithemtic and bitwise operators.
+
| 4.4.1 Parent Part | + | |
| 4.4.2 Instruction Format | + |
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Parts can also inherit parameters from previously defined parts using
+the following syntax. In this case specified integer and string values
+override parameter values from the parent part. New memory definitions
+are added to the definitions inherited from the parent. If, however, a
+new memory definition refers to an existing one of the same name for
+that part then, from v7.1, the existing memory definition is extended,
+and components overwritten with new values. Assigning NULL
+removes an inherited SPI instruction format, memory definition, control
+stack, eeprom or flash instruction, e.g., as in memory "efuse" =
+NULL;. The variants parameter is never inherited as it almost
+always would be a mistake to do so: variants defines a string
+list detailing variant names of the part followed by an optional
+colon, the package code and some absolute maximum ratings.
+
Example format for part inheritance: +
+part parent <id> # String identifying parent + id = <id>; # Id string for new part + <any set of other parameters from the list above> + ; + |
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Instruction formats are specified as a comma separated list of string +values containing information (bit specifiers) about each of the 32 bits +of the instruction. Bit specifiers may be one of the following formats: +
+1The bit is always set on input as well as output +
+0The bit is always clear on input as well as output +
+xThe bit is ignored on input and output +
+aThe bit is an address bit, the bit-number matches this bit specifier’s +position within the current instruction byte +
+aNThe bit is the Nth address bit, bit-number = N, i.e., a12
+is address bit 12 on input, a0 is address bit 0.
+
iThe bit is an input data bit; as with a bits an input data bit can
+optionally be followed by a bit number, here between 0 and 7, if the bit
+needs to be moved to a different position in the SPI write command byte
+than it appears in memory.
+
oThe bit is an output data bit; as with i bits an output data bit
+can optionally be followed by a bit number; this is useful in case the
+part’s SPI read command places a particular bit into a different position
+than the write command put it, e.g., ATtiny22L or AT90S8535 lock bits.
+
Each instruction must be composed of 32 bit specifiers. The instruction +specification closely follows the instruction data provided in Atmel’s +data sheets for their parts. For example, the EEPROM read and write +instruction for an AT90S2313 AVR part could be encoded as: +
++read = "1 0 1 0 0 0 0 0 x x x x x x x x", + "x a6 a5 a4 a3 a2 a1 a0 o o o o o o o o"; + +write = "1 1 0 0 0 0 0 0 x x x x x x x x", + "x a6 a5 a4 a3 a2 a1 a0 i i i i i i i i"; + + |
As the address bit numbers in the SPI opcodes are highly systematic, they
+don’t really need to be specified. A compact version of the format
+specification neither uses bit-numbers for address lines nor spaces. If such
+a string is longer than 7 characters, then the characters 0, 1,
+x, a, i and o will be recognised as the
+corresponding bit, whilst any of the characters ., -, _
+or / can act as arbitrary visual separators, which are ignored.
+Examples:
+
+ loadpage_lo = "0100.0000--000x.xxxx--xxaa.aaaa--iiii.iiii"; + + loadpage_lo = "0100.0000", "000x.xxxx", "xxaa.aaaa", "iiii.iiii"; + + |
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
stk500_devcode parameter is the device code used by the STK500
+and is obtained from the software section (avr061.zip) of
+Atmel’s AVR061 application note available from
+http://www.atmel.com/dyn/resources/prod_documents/doc2525.pdf.
+
+flash, eeprom, fuse,
+lfuse (low fuse), hfuse (high fuse), efuse
+(extended fuse), signature, calibration, lock.
+
+pwroff_after_write flag causes AVRDUDE to attempt to power
+the device off and back on after an unsuccessful write to the affected
+memory area if VCC programmer pins are defined. If VCC pins are not
+defined for the programmer, a message indicating that the device needs a
+power-cycle is printed out. This flag was added to work around a
+problem with the at90s4433/2333’s; see the at90s4433 errata at:
+
+https://www.microchip.com/content/dam/mchp/documents/OTH/ProductDocuments/DataSheets/doc1042.pdf +
+The bootloader implements the “chip erase” function by erasing the +flash pages of the application section. +
+Reading fuse and lock bits is fully supported. +
+| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Autogenerated files are virtual read-only files that do
+not exist externally but that are provided by AVRDUDE instead. They have
+the form prefix:parameters and can be used to write the
+contents of memory. The prefix tells AVRDUDE which sort of file to
+generate while the part after the colon is usually an underscore-separated
+list of parameters that determines the contents of the autogenerated file.
+
Currently, the only autogenerated files are urboot bootloaders from the
+https://github.com/stefanrueger/urboot project. They take the form
+urboot:features. Bootloader features are specified using an
+underscore-separated list in arbitrary order, eg,
+urboot:autobaud_2s. For a complete list of possible features see
+below. The following example writes a suitable autobaud bootloader to the
+flash of an ATmega328P target:
+
|
Autogenerated bootloaders can be used in the terminal as well: +
+
|
Note that using urboot:... in -U options has the desired
+side effect of also setting all necessary fuse configurations for the
+bootloader to work correctly. This does not happen when using the
+terminal write command, where the necessary fuse configurations
+need to be requested manually.
+
The terminal mode is great for exploring possible bootloaders +interactively: +
+
|
The list feature does not generate the bootloader code but instead
+interactively lists possible selections. In above example, the last column
+is cut off for space reasons. Using successively ee (provide a
+bootloader with EEPROM r/w capability), ce (add chip erase
+emulation code to the generated bootloader) and u4 (generate code
+skipping all redundant flash page writes and page erases to wear out the
+flash memory less and speed up the bootloading process) will then
+iteratively reduce the available selection:
+
|
In all lists the starred bootloaders are those that are the most
+feature-rich given the available used flash space, which — out of necessity —
+must be a multiple of flash pages or minimal boot section. These can be
+selected with the best feature. The show feature displays
+the properties of the bootloader that would be written without actually
+writing it; removing show will then write the bootloader to flash
+and, using -U, also set the necessary fuses:
+
|
Like the urboot project AVRDUDE currently only provides bootloaders for classic parts. +The following table lists possible features. +
+2s | WDT timeout: 250ms, 500ms, 1s (default), 2s, 4s or 8s (*0) |
autobaud | Bootloader adapts to host baud rate within MCU capability (*1) |
uart<n> | Hardware UART number, eg, uart0 (default), uart1, ... |
alt<n> | Alternative UART I/O lines (*2) |
9.6kbaud | Or other reasonable baud rates; also accepting baud unit |
16MHz | Or other CPU frequencies; also accepting kHz and Hz units |
[xa-q] | Optional F_CPU prefix designator, eg, i9.2MHz (*3)
+ - x: external oscillator (default)
+ - i: internal oscillator
+ - [a-h]: internal oscillator that is 10% (a) to 1.25% (h) slow
+ - [j-q]: internal oscillator that is 1.25% (j) to 10% (q) fast |
swio | Software I/O, must specify rx and tx pins |
rx[a-h][0-7] | MCU receive pin for swio, eg, rxb0 |
tx[a-h][0-7] | MCU transfer pin for swio, eg, txb1 |
lednop | If no LED is specified generate template bootloader |
no-led/noled | Drop blinking code unless a LED is specified |
led[+-][a-h][0-7] | Generate code for activity LED with polarity +/-, eg, led+b5 |
dual | Dual boot; must specify CS pin for external SPI flash (*4) |
cs[a-h][0-7] | Chip select pin for dual boot, eg, csd5 |
hw | Generate bootloader with hardware boot section (*5) |
v<n> | Optional vector for vector bootloader, eg, v25 or vspmready |
ee | Generate bootloader with EEPROM r/w support |
ce | Generate bootloader that can emulate a chip erase |
pr | Generate vector bootloader with reset vector protection (*6) |
u1 | Generate bootloader that skips redundant flash page writes (*7,8) |
u2 | ... and skips redundant flash page erases during emulated CE (*7,8) |
u3 | ... and skips not needed flash page erases during page write (*7,8) |
u4 | ... and skips empty flash page writes after page erase (*8) |
serialno=abc123 | Put serial number, eg, abc123, in top of unused bootloader flash |
fill=urboot\x20 | Fill otherwise unused bootloader flash repeatedly with argument |
save=myfile.hex | Save bootloader to file with chosen name (*9) |
save | Save bootloader to file with canonical file name (*9) |
tags=myfile.tag | Save symbols to tag file with chosen name (*9) |
tags | Save symbols to tag file with canonical file name (*9) |
configs | Show needed fuse configuration but do not write to memories |
show | Show bootloader features but do not write to flash |
list | List possible bootloader configurations but do not write to flash |
best | Select smallest feature-rich bootloader (first in list) and, if
+ the baud rate error is too high for UART, switch to swio |
help | Show this help message and return |
Notes. Features can also be specified like in elements of a canonical file name. +For details on urboot bootloaders and their features see https://github.com/stefanrueger/urboot. +
| *0 | Some parts do not provide 4 s or 8 s watchdog timeout |
| *1 | autobaud only works with UART I/O where the RX port pin is bit-addressable |
| *2 | From classic parts, only ATtiny441/841 have alternate UART signals |
| *3 | There is a subtle difference between external oscillators (x), which are
+ reasonably accurate, and internal oscillators (a...h, i,
+ j...q), which tend to be inaccurate for classic parts. The former can
+ afford higher baud rate errors up to 2.2% while for the latter AVRDUDE warns at the
+ lower threshold of 0.7% baud rate error. Cassic UARTs have integer baud rate
+ divisors, which can lead to high baud rate quantisation errors. Used with the feature
+ best AVRDUDE can automagically replace UART I/O code with swio
+ I/O code when the former exhibits too high baud rate errors. For that, AVRDUDE better
+ knows the type of oscillator (x or i) that drives a board. For lowest
+ baud rate errors on an individual board that runs on internal oscillators it is best
+ to measure F_CPU and use the measured value with the i prefix. Alternatively,
+ one can use the nominal internal F_CPU (say 8 MHz) and use prefix letters that
+ make the bootloader work: depending on the letter AVRDUDE subtracts from or adds to
+ the nominal F_CPU multiples of 1.25%. |
| *4 | Dual boot is not supported for parts that lack standard SPI communication |
| *5 | Not all parts provide hardware bootloader support; hw renders pr meaningless |
| *6 | Reset vector protection is only available if flash size is a power of 2 (not ATmega406) |
| *7 | u1...u3 is only advisory, ie, can result in any of u1...u4 |
| *8 | u1...u4 is not available for parts with the 4-page-erase quirk |
| *9 | The file is still written to disk in connection with configs, show or
+ list. Bootloader files are per default written as Intel Hex format with
+ comments. A filename of - writes the file to stdout. If a bootloader
+ is a vector bootloader then the bootloader file contains a segment for
+ initialising the reset vector to point to the bootloader. Tag files can be used in
+ connection with the terminal disasm command. |
Baud rate quantification errors are displayed with -v. A 0.79% baud
+rate error is considered OK for external oscillators but too high for
+internal oscillators. Hence, AVRDUDE selects software I/O when neither
+uart nor swio are explicitly requested:
+
|
There is a warning when the user requests hardware UART I/O: +
+
|
Requesting best makes AVRDUDE switch to swio when UART quatisation errors are considered too high:
+
|
Alternatively, the user can request swio on those rx/tx lines that the UART uses:
+
|
Tag files can be used in connection with disasm:
+
|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
AVRDUDE was written by Brian S. Dean under the name of AVRPROG to run on +the FreeBSD Operating System. Brian renamed the software to be called +AVRDUDE when interest grew in a Windows port of the software so that the +name did not conflict with AVRPROG.EXE which is the name of Atmel’s +Windows programming software. +
+For many years, the AVRDUDE source resided in public repositories on +savannah.nongnu.org, +where it continued to be enhanced and ported to other systems. In +addition to FreeBSD, AVRDUDE now runs on Linux, macOS and Windows. The +developers behind the porting effort primarily were Ted Roth, Eric +Weddington, and Jörg Wunsch. +
+In 2022, the project moved to Github (https://github.com/avrdudes/avrdude/). +
+And in the spirit of many open source projects, this manual also draws +on the work of others. The initial revision was composed of parts of +the original Unix manual page written by Jörg Wunsch, the original web +site documentation by Brian Dean, and from the comments describing the +fields in the AVRDUDE configuration file by Brian Dean. The texi +formatting was modeled after that of the Simulavr documentation by Ted +Roth. +
+ +| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| 6.1 Atmel STK600 | + | |
| 6.2 DFU Bootloader Using FLIP Version 1 | + | |
| 6.3 SerialUPDI Programmer | + | |
| 6.4 Programmer LED Management | + |
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
The following devices are supported by the respective STK600 routing +and socket card: +
+| Routing card | Socket card | Devices |
|---|---|---|
| STK600-ATTINY10 | t4 t5 t9 t10 |
STK600-RC008T-2 | STK600-DIP | t11 t12 t13 t13a t25 t45 t85 |
STK600-RC008T-7 | STK600-DIP | t15 |
STK600-RC014T-42 | STK600-SOIC | t20 |
STK600-RC020T-1 | STK600-DIP | t2313 t2313a t4313 |
| STK600-TinyX3U | t43u |
STK600-RC014T-12 | STK600-DIP | t24 t44 t84 t24a t44a |
STK600-RC020T-8 | STK600-DIP | t26 t261 t261a t461 t861 t861a |
STK600-RC020T-43 | STK600-SOIC | t261 t261a t461 t461a t861 t861a |
STK600-RC020T-23 | STK600-SOIC | t87 t167 |
STK600-RC028T-3 | STK600-DIP | t28 |
STK600-RC028M-6 | STK600-DIP | t48 t88 m8 m8a m48 m88 m168 m48p m48pa m88p m88pa m168p m168pa m328p |
| QT600-ATTINY88-QT8 | t88 |
STK600-RC040M-4 | STK600-DIP | m8515 m162 |
STK600-RC044M-30 | STK600-TQFP44 | m8515 m162 |
STK600-RC040M-5 | STK600-DIP | m8535 m16 m16a m32 m32a m164p m164pa m324p m324pa m644 m644p m644pa m1284p |
STK600-RC044M-31 | STK600-TQFP44 | m8535 m16 m16a m32 m32a m164p m164pa m324p m324pa m644 m644p m644pa m1284p |
| QT600-ATMEGA324-QM64 | m324pa |
STK600-RC032M-29 | STK600-TQFP32 | m8 m8a m48 m88 m168 m48p m48pa m88p m88pa m168p m168pa m328p |
STK600-RC064M-9 | STK600-TQFP64 | m64 m64a m128 m128a m1281 m2561 c32 c64 c128 |
STK600-RC064M-10 | STK600-TQFP64 | m165 m165p m169 m169p m169pa m325 m325p m329 m329p m645 m649 m649p |
STK600-RC100M-11 | STK600-TQFP100 | m640 m1280 m2560 |
| STK600-ATMEGA2560 | m2560 |
STK600-RC100M-18 | STK600-TQFP100 | m3250 m3250p m3290 m3290p m6450 m6490 |
STK600-RC032U-20 | STK600-TQFP32 | usb82 usb162 m8u2 m16u2 m32u2 |
STK600-RC044U-25 | STK600-TQFP44 | m16u4 m32u4 |
STK600-RC064U-17 | STK600-TQFP64 | m32u6 usb646 usb1286 usb647 usb1287 |
STK600-RCPWM-22 | STK600-TQFP32 | m32c1 m64c1 m16m1 m32m1 m64m1 |
STK600-RCPWM-19 | STK600-SOIC | pwm2 pwm3 pwm2b pwm3b pwm216 pwm316 |
STK600-RCPWM-26 | STK600-SOIC | pwm81 |
STK600-RC044M-24 | STK600-TSSOP44 | m16hvb m32hvb |
| STK600-HVE2 | m64hve |
| STK600-ATMEGA128RFA1 | m128rfa1 |
STK600-RC100X-13 | STK600-TQFP100 | x64a1 x128a1 x128A1revd x128a1u |
| STK600-ATXMEGA1281A1 | x128a1 |
| QT600-ATXMEGA128A1-QT16 | x128a1 |
STK600-RC064X-14 | STK600-TQFP64 | x64a3 x128a3 x256a3 x64d3 x128d3 x192d3 x256d3 |
STK600-RC064X-14 | STK600-MLF64 | x256a3b |
STK600-RC044X-15 | STK600-TQFP44 | x32a4 x16a4 x16d4 x32d4 |
| STK600-ATXMEGAT0 | x32t0 |
| STK600-uC3-144 | uc3a0512 uc3a0256b uc3a0128b |
STK600-RCUC3A144-33 | STK600-TQFP144 | uc3a0512 uc3a0256b uc3a0128b |
STK600-RCuC3A100-28 | STK600-TQFP100 | uc3a1512b uc3a1256b uc3a1128b |
STK600-RCuC3B0-21 | STK600-TQFP64-2 | uc3b0256b uc3b0512revcb uc3b0512b uc3b0128b uc3b064b uc3d1128b |
STK600-RCuC3B48-27 | STK600-TQFP48 | uc3b1256b uc3b164b |
STK600-RCUC3A144-32 | STK600-TQFP144 | uc3a3512b uc3a3256b uc3a3128b uc3a364b uc3a3256sb uc3a3128sb uc3a364sb |
STK600-RCUC3C0-36 | STK600-TQFP144 | uc3c0512b uc3c0256b uc3c0128b uc3c064b |
STK600-RCUC3C1-38 | STK600-TQFP100 | uc3c1512b uc3c1256b uc3c1128b uc3c164b |
STK600-RCUC3C2-40 | STK600-TQFP64-2 | uc3c2512b uc3c2256b uc3c2128b uc3c264b |
STK600-RCUC3C0-37 | STK600-TQFP144 | uc3c0512b uc3c0256b uc3c0128b uc3c064b |
STK600-RCUC3C1-39 | STK600-TQFP100 | uc3c1512b uc3c1256b uc3c1128b uc3c164b |
STK600-RCUC3C2-41 | STK600-TQFP64-2 | uc3c2512b uc3c2256b uc3c2128b uc3c264b |
STK600-RCUC3L0-34 | STK600-TQFP48 | uc3l064b uc3l032b uc3l016b |
| QT600-AT32UC3L-QM64 | uc3l064b |
Ensure the correct socket and routing card are mounted before
+powering on the STK600. While the STK600 firmware ensures the socket
+and routing card mounted match each other (using a table stored
+internally in nonvolatile memory), it cannot handle the case where a
+wrong routing card is used, e. g. the routing card
+STK600-RC040M-5 (which is meant for 40-pin DIP AVRs that have
+an ADC, with the power supply pins in the center of the package) was
+used but an ATmega8515 inserted (which uses the “industry standard”
+pinout with Vcc and GND at opposite corners).
+
Note that for devices that use the routing card STK600-RC008T-2,
+in order to use ISP mode, the jumper for AREF0 must be removed
+as it would otherwise block one of the ISP signals. High-voltage
+serial programming can be used even with that jumper installed.
+
The ISP system of the STK600 contains a detection against shortcuts +and other wiring errors. AVRDUDE initiates a connection check before +trying to enter ISP programming mode, and display the result if the +target is not found ready to be ISP programmed. +
+High-voltage programming requires the target voltage to be set to at +least 4.5 V in order to work. This can be done using +Terminal Mode, see Terminal Mode Operation. +
+| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Bootloaders using the FLIP protocol version 1 experience some very +specific behaviour. +
+These bootloaders have no option to access memory areas other than +Flash and EEPROM. +
+ +When the bootloader is started, it enters a security mode where +the only acceptable access is to query the device configuration +parameters (which are used for the signature on AVR devices). The +only way to leave this mode is a chip erase. As a chip erase +is normally implied by the ‘-U’ option when reprogramming the +flash, this peculiarity might not be very obvious immediately. +
+Sometimes, a bootloader with security mode already disabled seems to +no longer respond with sensible configuration data, but only 0xFF for +all queries. As these queries are used to obtain the equivalent of a +signature, AVRDUDE can only continue in that situation by forcing the +signature check to be overridden with the ‘-F’ option. +
+ +A chip erase might leave the EEPROM unerased, at least on some +versions of the bootloader. +
+
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
SerialUPDI programmer can be used for programming UPDI-only devices +using very simple serial connection. +You can read more about the details here +https://github.com/SpenceKonde/AVR-Guidance/blob/master/UPDI/jtag2updi.md +
+SerialUPDI programmer has been tested using FT232RL USB->UART interface +with the following connection layout (copied from Spence Kohde’s page linked +above): +
+------------------ To Target device + DTR| _______________ + Rx |-----------,------------------| UPDI---\/\/-------> +Tx---/\/\/\---Tx |----|<|---' .--------| Gnd 470 ohm + resistor Vcc|------------------------------| Vcc + 1k CTS| .` |_______________ + Gnd|-----------------' +------------------ + |
There are several limitations in current SerialUPDI/AVRDUDE integration, +listed below. +
+Currently available devices support only UPDI NVM programming model 0, 2 +3 and 5, but there is also experimental implementation of model 4 - it +has been tested only on a single device, so issues with other devices are +expected. Full NVM v4 mode support will be provided once the hardware is +widely available. +
+ +One of the core AVRDUDE features is verification of the connection by +reading device signature prior to any operation, but this operation +is not possible on UPDI locked devices. Therefore, to be able to +connect to such a device, you have to provide ‘-F’ to override +this check. +
+Please note: using ‘-F’ during write operation to locked device +will force chip erase. Use carefully. +
+ +Another issue you might notice is slow performance of EEPROM writing +using SerialUPDI for AVR Dx devices. This can be addressed by changing +avrdude.conf section for this device - changing EEPROM page +size to 0x20 (instead of default 1), like so: +
+#------------------------------------------------------------ +# AVR128DB28 +#------------------------------------------------------------ + +part parent ".avrdx" + id = "avr128db28"; + desc = "AVR128DB28"; + signature = 0x1E 0x97 0x0E; + + memory "flash" + size = 0x20000; + offset = 0x800000; + page_size = 0x200; + readsize = 0x100; + ; + + memory "eeprom" + size = 0x200; + offset = 0x1400; + page_size = 0x20; + readsize = 0x100; + ; +; + |
The point of USERROW is to provide ability to write configuration details +to already locked device and currently SerialUPDI interface supports this +feature. Please note: on locked devices it’s not possible to read back +USERROW contents when written, so the automatic verification will most +likely fail and to prevent error messages, use ‘-V’. +
+In case you run into issues with the SerialUPDI interface, please +make sure to run the intended command with debug output enabled +(‘-v -v -v’) and provide this verbose output with your +bug report. You can also try to perform the same action using +pymcuprog (https://github.com/microchip-pic-avr-tools/pymcuprog) +utility with ‘-v debug’ and provide its output too. +You will notice that both outputs are pretty similar, and this +was implemented like that on purpose - it was supposed to make +analysis of UPDI protocol quirks easier. +
+| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Some hardware programmers have LEDs, and the firmware controls them fully
+without AVRDUDE having a way to influence their LED states. Other
+programmers have LEDs and expect the host downloader/uploader to handle
+them, for example bit-banging programmers, ftdi-based programmers or
+linuxgpio programmers. For those programmers AVRDUDE provides support of
+four LEDs (RDY, ERR, PGM and VFY) which can be set via corresponding
+subroutines in the code for the respective -c programmer.
+
The RDY LED is set once the programmer is initialised and switched off +when AVRDUDE exits. During reading, writing or erasing the target the PGM +LED flashes with around 2.5 Hz, whilst the VFY LED comes on during -U +verification of the written contents. Errors are indicated with the ERR +LED. +
+Assuming AVRDUDE got to the point where LEDs are accessible and the RDY +LED was switched on then, on exit, AVRDUDE will leave the LEDs in the +following states: +
+| PGM | VFY | ERR | Semantics | |
| off | off | off | OK: all tasks done without errors | |
| off | off | on | Some error not related to read, write or erase | |
| on | off | on | Read, write or erase error | |
| off | on | on | Verification error but no read, write or erase error | |
| on | on | on | Verification error and read, write or erase error |
Other combinations should not show after exit. +
+ +| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| A.1 Unix | + | |
| A.2 Windows | + |
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| A.1.1 Unix Installation | + | |
| A.1.2 Unix Configuration Files | + | |
| A.1.3 Unix Port Names | + | |
| A.1.4 Unix USB Permissions | + | |
| A.1.5 Unix Documentation | + |
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Refer to https://github.com/avrdudes/avrdude/wiki +for the latest installation tips. +
+
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
When AVRDUDE is built using the default ‘--prefix’ configure
+option, the default configuration file for a Unix system is located at
+/usr/local/etc/avrdude.conf. This can be overridden by using the
+‘-C’ command line option. Additionally, the user’s home directory
+is searched for a file named .avrduderc, and if found, is used to
+augment the system default configuration file.
+
| A.1.2.1 FreeBSD Configuration Files | + | |
| A.1.2.2 Linux Configuration Files | + |
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
When AVRDUDE is installed using the FreeBSD ports system, the system
+configuration file is always /usr/local/etc/avrdude.conf.
+
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| 2.1 Option Descriptions | + | |
| 2.2 Programmers Accepting Exitspec Parameters | + | |
| 2.3 Programmers Accepting Extended Parameters | + | |
| 2.4 Example Command Line Invocations | + |
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
When AVRDUDE is installed using from an rpm package, the system
+configuration file will be always be /etc/avrdude.conf.
+
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
The parallel and serial port device file names are system specific.
+macOS has no default serial port names, but available ports can be
+found under /dev/cu.*. Please take note AVRDUDE does not
+support parallel port programming under macOS.
+
The following table lists the default names for a given system. +
+| System | Default Parallel Port | Default Serial Port |
| FreeBSD | /dev/ppi0 | /dev/cuad0 |
| Linux | /dev/parport0 | /dev/ttyS0 |
| Solaris | /dev/printers/0 | /dev/term/a |
On FreeBSD systems, AVRDUDE uses the ppi(4) interface for +accessing the parallel port and the sio(4) driver for serial port +access. +
+On Linux systems, AVRDUDE uses the ppdev interface for +accessing the parallel port and the tty driver for serial port +access. +
+On Solaris systems, AVRDUDE uses the ecpp(7D) driver for +accessing the parallel port and the asy(7D) driver for serial port +access. +
+
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
In most cases the kernel driver initializes a plug-and-play device to be
+owned by user root and group root with only r/w permission
+for the user root rendering the device inaccessible to regular
+users. Whilst users can run AVRDUDE sessions as root this is definitely
+not good practice. Giving USB plug-and-play devices the correct
+permissions is much better. USB AVR programmers are normally identified by
+a two-byte hexadecimal vendor ID and a two-byte hexadecimal product id.
+Both are typically used to identify the device that needs new permissions.
+
| A.1.4.1 FreeBSD USB Permissions | + | |
| A.1.4.2 Linux USB Permissions | + |
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
In FreeBSD a so-called devd config files in
+/usr/local/etc/devd serve to modify permissions of plugged-in USB
+devices. Here is an example how Atmel’s JTAGICE3 programmer (product ID
+0x2110 or 0x2140) by Atmel (vendor ID 0x0eb) can be given appropriate
+permissions using a file jtagice3.conf:
+
|
yourgroup would be a group that the user(s) should be
+member of who wish to have access to the programmer.
+
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Linux has a special userspace /dev device manager called udev that
+deals with, amongst other things, plug-and-play USB devices. It is
+recommended to specify so-called udev rules to define access permissions
+for these devices instead. These rules typically reside in a file with the
+name nn-descriptive-name.rules in the directory
+/etc/udev/rules.d. Here, nn is a two-digit number that
+determines the lexical order in which the udev rule files are processed.
+Rules processed later can overwrite earlier rules, but it not recommended
+to put user-generated rules higher than 60, as some of the actions they
+require are processed by higher-level system rules.
+
Here a typical udev rule for allowing an ordinary user access to the +plugged-in AVRISP mkII programmer (product ID 0x2104) by Atmel (vendor ID +0x0eb): +
+
|
This furnishes the corresponding device node with 0660
+access permissions: this means r/w for the user root and any user
+belonging to the group of the device, which the device driver might assign
+to a different group than the default root. The key of the rule is
+the attached TAG named uaccess, which has the effect that
+the login daemon applies a dynamic user access control list to the device
+node making the device usable for the currently logged-in user. When used
+in anger, udev rules must appear on one line; above example was broken
+into two lines so it fits into the example box.
+
AVRDUDE’s developer option -c programmer/u will show
+above suggested udev rule for the named programmer. Wildcards are allowed:
+
|
Again, each rule must be written as one line: breaking up rules
+into two lines was only done to fit AVRDUDE’s output to the boxed display.
+USB devices in HID mode require a second rule dealing with the
+hidraw subsystem as seen above.
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
AVRDUDE installs a manual page as well as info, HTML and PDF
+documentation. The manual page is installed in
+/usr/local/man/man1 area, while the HTML and PDF documentation
+is installed in /usr/local/share/doc/avrdude directory. The
+info manual is installed in /usr/local/info/avrdude.info.
+
Note that these locations can be altered by various configure options +such as ‘--prefix’. +
+
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| A.2.1 Installation | + | |
| A.2.2 Windows Configuration Files | + | |
| A.2.3 Windows Port Names | + |
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Refer to https://github.com/avrdudes/avrdude/wiki +for the latest installation tips. +
+
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| A.2.2.1 Windows Configuration File Names | + | |
| A.2.2.2 Windows Configuration File Location | + |
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
AVRDUDE on Windows looks for a system configuration file name of
+avrdude.conf and looks for a user override configuration file of
+avrdude.rc in the same directory where avrdude.exe is located.
+
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
AVRDUDE is a command line tool, used as follows: +
+avrdude -p partname options … + |
Command line options are used to control AVRDUDE’s behaviour. The +following options are recognized: +
+-p partname--part partnameThis option tells AVRDUDE what part (MCU) is connected to the programmer.
+The partname parameter is the part’s id listed in the configuration
+file. To see a list of currently supported MCUs use ? as partname,
+which will, for each part, print its id; its official part name;
+alternative names, if any; and the list of available programming
+interfaces. Depending on the used shell, ? may need to be quoted
+as in "?" or \?. In connection with -v, this will
+also print a table of variant part names with the package code and some
+absolute maximum ratings. The part id, their official part name, the
+listed alternative names or any of the full variant part names can be used
+to specify a part with the -p option. If a part is unknown to
+AVRDUDE, it means that there is no config file entry for that part, but it
+can be added to the configuration file if you have the Atmel datasheet so
+that you can enter the programming specifications. If -p ? is
+specified with a specific programmer, see -c below, then only those
+parts are output that the programmer expects to be able to handle,
+together with the programming interface(s) that can be used in that
+combination. In reality there can be deviations from this list,
+particularly if programming is directly via a bootloader. See List of Parts for a full and detailed listing of supported parts.
+
-p wildcard/flags--part wildcard/flagsRun developer options for MCUs that are matched by wildcard. Whilst
+their main use is for developers some flags can be of utility for
+users, e.g., avrdude -p m328p/S outputs AVRDUDE’s understanding of
+ATmega328P MCU properties; for more information run avrdude -p x/h.
+
-b baudrate--baud baudrateOverride the RS-232 connection baud rate specified in the respective
+programmer’s baudrate entry of the configuration file
+or defined by the default_baudrate entry in your
+~/.config/avrdude/avrdude.rc or ~/.avrduderc configuration
+file if no baudrate entry was provided for this programmer.
+
-B bitclock--bitclock bitclockSpecify the bit clock period for the JTAG, PDI, TPI, UPDI, or ISP
+interface. The value is a floating-point number in microseconds.
+Alternatively, the value might be suffixed with Hz, kHz or
+MHz in order to specify the bit clock frequency rather than a
+period. Some programmers default their bit clock value to a 1
+microsecond bit clock period, suitable for target MCUs running at 4
+MHz clock and above. Slower MCUs need a correspondingly higher bit
+clock period. Some programmers reset their bit clock value to the
+default value when the programming software signs off, whilst
+others store the last used bit clock value. It is recommended to
+always specify the bit clock if read/write speed is important. You
+can use the ’default_bitclock’ keyword in your
+~/.config/avrdude/avrdude.rc or ~/.avrduderc
+configuration file to assign a default value to keep from having to
+specify this option on every invocation.
+
Note that some official Microchip programmers store the bitclock setting +and will continue to use it until a different value is provided. This +applies to 2nd generation programmers (AVRISPmkII, AVR Dragon, JTAG ICE +mkII, STK600) and 3rd generation programmers (JTAGICE3, Atmel ICE, Power +Debugger). 4th generation programmers (PICkit 4, MPLAB(R) SNAP) will store +the last user-specified bitclock until the programmer is disconnected from +the computer. +
+-c programmer-id--programmer programmer-idSpecify the programmer to be used. AVRDUDE knows about quite a few
+programmers. The programmer-id parameter is the programmer’s id
+listed in the configuration file. Specify -c ? to list all
+programmers in the configuration file. Depending on the used shell,
+? may need to be quoted as in "?" or \?. If you have
+a programmer that is unknown to AVRDUDE but related to a known programmer
+there is some chance that it can be added to the configuration file
+without any code changes to AVRDUDE: copy a similar entry and change those
+features that differ to match that of the unknown programmer. If -c
+? is specified with a specific part, see -p above, then only those
+programmers are output that expect to be able to handle this part,
+together with the programming interface(s) that can be used in that
+combination. In reality there can be deviations from this list,
+particularly if programming is directly via a bootloader. See List of Programmers for a full and detailed listing of known programmers.
+
-c wildcard/flags--programmer wildcard/flagsRun developer options for programmers that are matched by wildcard.
+Whilst their main use is for developers some flags can be of utility
+for users, e.g., avrdude -c usbtiny/S shows AVRDUDE’s understanding of
+usbtiny’s properties; for more information run avrdude -c x/h.
+
-C config-file--config config-fileUse the specified config file for configuration data. This file +contains all programmer and part definitions that AVRDUDE knows about. +If not specified, AVRDUDE looks for the configuration file in the following +two locations: +
+<directory from which application loaded>/../etc/avrdude.conf
+
+<directory from which application loaded>/avrdude.conf
+
+If not found there, the lookup procedure becomes platform dependent. On FreeBSD
+and Linux, AVRDUDE looks at /usr/local/etc/avrdude.conf. See Appendix A
+for the method of searching on Windows.
+
If config-file is written as +filename +then this file is read after the system wide and user configuration +files. This can be used to add entries to the configuration +without patching your system wide configuration file. It can be used +several times, the files are read in same order as given on the command +line. +
+-N--noconfigDo not load the personal configuration file that is usually located at
+~/.config/avrdude/avrdude.rc, ~/.avrduderc or in the same
+directory as the avrdude executable.
+
-ADisable the automatic removal of trailing-0xFF sequences in file input
+that is to be programmed to flash and in AVR reads from flash memory.
+Normally, trailing 0xFFs can be discarded, as flash programming requires
+the memory be erased to 0xFF beforehand. -A should be used when the
+programmer hardware, or bootloader software for that matter, does not
+carry out chip erase and instead handles the memory erase on a page level.
+The popular Arduino bootloader exhibits this behaviour; for this reason
+-A is engaged by default when specifying -c arduino.
+
-D--noeraseDisable auto-erase for flash. When the -U option for writing to any
+flash memory is specified, avrdude will perform a chip erase before
+starting any of the programming operations, since it generally is a
+mistake to program the flash without performing an erase first. This
+option disables that. Auto-erase is not used for ATxmega parts nor for the
+UPDI (AVR8X family) parts as these can use page erase before writing each
+page so no explicit chip erase is required. Note, however, that any flash
+page not affected by the current operation will retain its previous
+contents. Setting -D implies -A.
+
-e--eraseCauses a chip erase to be executed. This will reset the contents of the
+flash ROM and EEPROM to the value 0xff, and clear all lock bits.
+Except for ATxmega and UPDI (AVR8X family) devices, all of which can use
+page erase, it is basically a prerequisite command before the flash ROM
+can be reprogrammed again. The only exception would be if the new
+contents would exclusively cause bits to be programmed from the value
+1 to 0. This option carries out the chip erase at the
+beginning, before any of the -U, -T or -t options are
+processed. If a chip erase is required in at a certain position within the
+sequence of -U, -T or -t options it is recommended to
+use -T erase instead which is processed in the given command line
+order.
+
In absence of an explicit -e or -D option avrdude tries to
+augur from the command line whether or not the chip should be auto-erased
+at the beginning. If avrdude detects a -U command that writes to
+flash then auto-erase will be carried out before any other programming
+unless a -T erase commad has been detected beforehand and unless
+flash is read before writing to it. For the purpose of this analysis any
+terminal command is considered to possibly read flash.
+
Note that for reprogramming EEPROM cells, no explicit prior chip erase is +required since the MCU provides an auto-erase cycle in that case before +programming the cell. +
+-E exitspec[,…]Pass exitspec to the programmer. The interpretation of the exitspec
+parameter depends on the programmer itself. See below for a list of
+programmers accepting exitspec parameter options or issue
+avrdude -E help ... to see the options for the programmer.
+
Multiple exitspec options can be separated with commas. +
+-FNormally, AVRDUDE tries to verify that the device signature read from +the part is reasonable before continuing. Since it can happen from time +to time that a device has a broken (erased or overwritten) device +signature but is otherwise operating normally, this options is provided +to override the check. +Also, for programmers like the Atmel STK500 and STK600 which can +adjust parameters local to the programming tool (independent of an +actual connection to a target controller), this option can be used +together with ‘-t’ to continue in terminal mode. +Moreover, the option allows to continue despite failed initialization +of connection between a programmer and a target. +
+-i delayFor bitbang-type programmers, delay for approximately +delay +microseconds between each bit state change. +If the host system is very fast, or the target runs off a slow clock +(like a 32 kHz crystal, or the 128 kHz internal RC oscillator), this +can become necessary to satisfy the requirement that the ISP clock +frequency must not be higher than 1/4 of the CPU clock frequency. +This is implemented as a spin-loop delay to allow even for very +short delays. +On Unix-style operating systems, the spin loop is initially calibrated +against a system timer, so the number of microseconds might be rather +realistic, assuming a constant system load while AVRDUDE is running. +On Win32 operating systems, a preconfigured number of cycles per +microsecond is assumed that might be off a bit for very fast or very +slow machines. +
+-l logfile--logfile logfileUse logfile rather than stderr for diagnostics output. +Note that initial diagnostic messages (during option parsing) are still +written to stderr anyway. +
+-n--test-memoryNo-write: disables writing data to the MCU whilst processing -U
+(useful for debugging AVRDUDE). The terminal mode continues to write to
+the device.
+
-O--osccalPerform a RC oscillator run-time calibration according to Atmel +application note AVR053. +This is only supported on the STK500v2, AVRISP mkII, and JTAG ICE mkII +hardware. + +Note that the result will be stored in the EEPROM cell at address 0. +
+-P port--port portUse port to identify the connection through which the programmer is
+attached. This can be a parallel, serial, spi or linuxgpio connection. The
+programmer normally specifies the connection type; in absence of a -P
+specification, system-dependent default values default_parallel,
+default_serial, default_spi, or default_linuxgpio from
+the configuration file are used. If you need to use a different port, use this
+option to specify the alternate port name.
+
If avrdude has been configured with libserialport support, a serial port
+can be specified using a predefined serial adapter type in
+avrdude.conf or .avrduderc, e.g., ch340 or
+ft232r. If more than one serial adapter of the same type is
+connected, they can be distinguished by appending a serial number, e.g.,
+ft232r:12345678. Note that the USB to serial chip has to have a
+serial number for this to work. Avrdude can check for leading and trailing
+serial number matches as well. In the above example, ft232r:1234
+would also result in a match, and so would ft232r:...5678. If the
+USB to serial chip is not known to avrdude, it can be specified using the
+hexadecimal USB vendor ID, hexadecimal product ID and an optional serial
+number, following the serial number matching rules described above, e.g.,
+usb:0x2341:0x0043 or usb:2341:0043:12345678. To see a list
+of currently plugged-in serial ports use -P ?s. In order to see a
+list of all possible serial adapters known to avrdude use -P ?sa.
+Depending on the used shell, ? may need to be quoted as in
+"?" or \?.
+
For the JTAG ICE mkII, if AVRDUDE has been built with libusb support,
+port may alternatively be specified as
+usb[:serialno]. In that case, the JTAG ICE mkII will be
+looked up on USB. If serialno is also specified, it will be
+matched against the serial number read from any JTAG ICE mkII found on
+USB. The match is done after stripping any existing colons from the
+given serial number, and right-to-left, so only the least significant
+bytes from the serial number need to be given.
+For a trick how to find out the serial numbers of all JTAG ICEs
+attached to USB, see Example Command Line Invocations.
+
As the AVRISP mkII device can only be talked to over USB, the very +same method of specifying the port is required there. +
+For the USB programmer "AVR-Doper" running in HID mode, the port must +be specified as avrdoper. Libhidapi support is required on Unix +and Mac OS but not on Windows. For more information about AVR-Doper see +https://www.obdev.at/products/vusb/avrdoper.html. +
+For the USBtinyISP, which is a simplistic device not implementing +serial numbers, multiple devices can be distinguished by their +location in the USB hierarchy. +For USBasp, multiple devices can be distinguished by either USB connection +or serial number. +See the respective Troubleshooting entry for examples. +
+For the XBee programmer the target MCU is to be programmed wirelessly
+over a ZigBee mesh using the XBeeBoot bootloader. The ZigBee 64-bit
+address for the target MCU’s own XBee device must be supplied as a
+16-character hexadecimal value as a port prefix, followed by the
+@ character, and the serial device to connect to a second
+directly contactable XBee device associated with the same mesh (with
+a default baud rate of 9600). This may look similar to:
+0013a20000000001dev/tty.serial.
+
For diagnostic purposes, if the target MCU with an XBeeBoot +bootloader is connected directly to the serial port, the +64-bit address field can be omitted. In this mode the +default baud rate will be 19200. +
+For programmers that attach to a serial port using some kind of
+higher level protocol (as opposed to bit-bang style programmers),
+port can be specified as net:host:port.
+In this case, instead of trying to open a local device, a TCP
+network connection to (TCP) port on host
+is established.
+Square brackets may be placed around host to improve
+readability for numeric IPv6 addresses (e.g.
+net:[2001:db8::42]:1337).
+The remote endpoint is assumed to be a terminal or console server
+that connects the network stream to a local serial port where the
+actual programmer has been attached to.
+The port is assumed to be properly configured, for example using a
+transparent 8-bit data connection without parity at 115200 Baud
+for a STK500.
+
Note: The ability to handle IPv6 hostnames and addresses is limited to +Posix systems (by now). +
+-r--reconnectOpens the serial port at 1200 baud and immediately closes it, waits 400 ms
+for each -r on the command line and then establishes communication
+with the programmer. This is commonly known as a "1200 bps touch", and is
+used to trigger programming mode for certain boards like Arduino Leonardo,
+Arduino Micro/Pro Micro and the Arduino Nano Every. Longer waits, and
+therefore multiple -r options, are sometimes needed for slower, less
+powerful hosts.
+
-q--quellDisable (or quell) output of the progress bar while reading or writing +to the device. Specify it a second time for even quieter operation. +
+-T cmdRun terminal line cmd when it is its turn in relation to other
+-t interactive terminals, -T terminal commands and
+-U memory operations. Except for the simplest of terminal commands
+the argument cmd will most likely need to be set in quotes, see your
+OS shell manual for details. See below for a detailed description of all
+terminal commands.
+
-t--terminalTells AVRDUDE to run an interactive terminal when it is its turn in
+relation to other -t interactive terminals, -T
+terminal commands and -U memory operations.
+
-U memory:op:filename[:format]--memory memory:op:filename[:format]Perform a memory operation when it is its turn in relation to other
+-t interactive terminals, -T terminal commands and -U
+memory operations. The memory field specifies the memory type to
+operate on. From version 8.0 the memory field can also be a
+comma-separated list of memories, eg, flash,eeprom; also, Intel Hex
+or Motorola S-Record files generated by AVRDUDE can store multiple
+memories. The special memory ALL expands to all memories that a
+part has while all expands to all memories with exception of
+sub-memories. etc is the same as all; this can be used to
+change the order in which memories are written to or read from file, eg,
+signature,etc is a list of all memories such that the
+signature memory comes first. It is possible to remove a memory
+from the list so far by preceding a minus or backslash, eg,
+all,-calibration. Use the ‘-T part’ option on the command
+line or the part command in the interactive terminal to display all
+the memories supported by a particular device.
+
Typically, a device’s memory configuration at least contains the memory
+types flash, eeprom, signature and lock, which
+is sometimes known as lockbits. The signature memory contains the
+three device signature bytes, which should be, but not always are, unique
+for the part. The lock memory of one or four bytes typically
+details whether or not external reading/writing of the flash memory, or
+parts of it, is allowed. After restricting access via the lock memory,
+often the only way to unlock memory is via a chip erase. Parts will also
+typically have fuse bytes, which are read/write memories for configuration
+of the device and calibration memories that typically contain read-only
+factory calibration values.
+
The flash memory, being physically implemented as NOR-memory, is special
+in the sense that it is normally only possible to program bits to change
+from 1 to 0. Before reprogramming takes place normally flash memory has to
+be erased. Older parts would only offer a chip erase to do so, which also
+erases EEPROM unless a fuse configuration preserves its contents. If
+AVRDUDE detects a -U option that writes to a flash memory it might
+automatically trigger a chip erase for these older parts. See the
+description of auto-erase under the -e option above. ATxmegas or
+UPDI parts (AVR8X family) offer a page erase, and AVRDUDE takes advantage
+of that by erasing pages before programming them unless -e (chip
+erase) or -D (do not erase before writing) was requested. It should
+be noted that in absence of the -e chip erase option any ATxmega or
+UPDI flash pages not affected by the programming will retain their
+previous content.
+
See List of Memories for a complete list of memories that AVR +devices can have. +
+The op field specifies what operation to perform: +
+rread device memories and write to the specified file +
+wread data from the specified file and write to the device memories in the +list; read-only memories in a memory list are skipped, as are fuses and +lock bits when the programmer is a bootloader; writing to single read-only +memories fails only if the contents differs between the file and memory +
+vread data from both the device and the specified file and perform a verify +
+The filename field indicates the name of the file to read or +write. The format field is optional and contains the format of +the file to read or write. Possible values are: +
+iIntel Hex +
+IIntel Hex with comments on reading from, and tolerance of checksum errors, writing to the AVR +
+ +sMotorola S-Record +
+ + +rraw binary; little-endian byte order, in the case of the flash data +
+ +eELF (Executable and Linkable Format), the final output file from the +linker; currently only accepted as an input file +
+ +mimmediate mode; actual byte values are specified on the command line, +separated by commas or spaces in place of the filename field of the +‘-U’ option. This is useful for programming fuse bytes without +having to create a single-byte file or enter terminal mode. +
+ +aauto detect; valid for input only, and only if the input is not provided +at stdin. +
+ +ddecimal; this and the following formats generate one line of output for +the respective memory section, forming a comma-separated list of the +values. This can be particularly useful for subsequent processing, like +for fuse bit settings. +
+ +hhexadecimal; each value will get the string 0x prepended. +
+ +ooctal; each value will get a 0 +prepended unless it is less than 8 in which case it gets no prefix. +
+ +bbinary; each value will get the string 0b prepended. +
When used as input, the m, d, h, o and
+b formats will use the same code for reading lists of numbers
+separated by white space and/or commas. The read routine handles decimal,
+hexadecimal, octal or binary numbers on a number-by-number basis, and the
+list of numbers can therefore be of mixed type. In fact the syntax, is the
+same as for data used by the terminal write command, i.e., the file’s input
+data can also be 2-byte short integers, 4-byte long integers or 8-byte
+long long integers, 4-byte floating point numbers, 8-byte double precision
+numbers, C-type strings with a terminating nul or C-like characters such
+as '\t'. Numbers are written as little endian to memory. When using
+0x hexadecimal or 0b binary input leading zeros are used to
+determine the size of the integer, e.g., 0x002a will occupy two
+bytes and write a 0x2a to memory followed by 0x00, while
+0x01234 will occupy 4 bytes. See the description of the terminal
+write command for more details.
+
In absence of an explicit file format, the default is to use auto
+detection for input files, raw binary format for output files from a
+single memory read and Intel Hex with comments when an output file is
+generated from a list of memories. Note that while AVRDUDE will generate a
+single output file from a memory list for all formats with the exception
+of elf (:e) it only recognises Intel hex (:I or :i),
+Motorola S-Record (:s) or elf files (:e, generated by the
+compiler) as valid multi-memory files when reading a file for verifying or
+writing memories. Note also that if a filename contains a colon as
+penultimate character the format field is no longer optional since
+the last character would otherwise be misinterpreted as format.
+
When reading any kind of flash memory area (including the various sub-areas
+in Xmega devices), the resulting output file will be truncated to not contain
+trailing 0xFF bytes which indicate unprogrammed (erased) memory. Thus, if the
+entire memory is unprogrammed, this will result in an output file that has no
+contents at all. This behaviour can be overridden with the -A option.
+
As an abbreviation, the form -U filename
+is equivalent to specifying
+-U flash:w:filename:a or
+-U application:w:filename:a for ATxmegas.
+This will only work if filename does not have a pair of colons in it
+that sandwich a single character as otherwise the first part might be
+interpreted as memory, and the single character as memory operation.
+
A file name used for writing to flash that starts with urboot:
+autogenerates a read-only urboot bootloader file. Try for example -c
+dryrun -U urboot:help for a list of features that determine the contents
+of the bootloader. See section Autogenerated files for detailed documentation.
+Writing urboot:... files to flash using -U has the desired
+side-effect of also writing all necessary fuse configurations for the
+bootloader to work.
+
-v--verboseEnable verbose output.
+More -v options increase verbosity level.
+
-V--noverify-memoryDisable automatic verify check when writing data to the AVR with -U.
+
--versionPrint avrdude version and exit +
+-x extended_paramPass extended_param to the chosen programmer implementation as
+an extended parameter. The interpretation of the extended parameter
+depends on the programmer itself. See below for a list of programmers
+accepting extended parameters or issue avrdude -x help ... to
+see the extended options of the chosen programmer.
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
AVRDUDE on Windows has a different way of searching for the system and +user configuration files. Below is the search method for locating the +configuration files: +
+<directory from which application loaded>/../etc/avrdude.conf
+
+SYSTEM32.
+
+
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| A.2.3.1 Windows Serial Ports | + | |
| A.2.3.2 Windows Parallel Ports | + |
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
When you select a serial port (i.e. when using an STK500) use the +Windows serial port device names such as: com1, com2, etc. +
+
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
AVRDUDE does not support parallel port programming in Windows. +If you need to run AVRDUDE using programmer on a parallel port, +you might want to try one of the BSDs or Linux. +
+ + +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Please report any bugs encountered via +https://github.com/avrdudes/avrdude/issues. +
+AVRDUDE’s wiki https://github.com/avrdudes/avrdude/wiki is a great +place to learn about installing AVRDUDE on various platforms and, +generally, to learn a few tricks of the trade. In paticular, the +FAQ and the +known limitations of avrdude are worth reading. +
+Here a few examples for things that can go wrong and what to do: +
+avrdude: serial_open(): can't set attributes for device "com1",
+
Solution: This problem seems to appear with certain versions of Cygwin. Specifying
+"/dev/com1" instead of "com1" should help.
+
Solution (short): setserial port low_latency
+
Solution (long): +There are two problems here. First, the system may wait some time before it +passes data from the serial port to the program. Under Linux the following +command works around this (you may need root privileges for this). +
+setserial port low_latency
+
Secondly, the serial interface chip may delay the interrupt for some time.
+This behaviour can be changed by setting the FIFO-threshold to one. Under Linux this
+can only be done by changing the kernel source in drivers/char/serial.c.
+Search the file for UART_FCR_TRIGGER_8 and replace it with UART_FCR_TRIGGER_1. Note that overall performance might suffer if there
+is high throughput on serial lines. Also note that you are modifying the kernel at
+your own risk.
+
Solutions: The reasons for this are the same as above. +If you know how to work around this on your OS, please let us know. +
+ +Solution: None. This is an inherent feature of the way JTAG EEPROM +programming works, and is documented that way in the Atmel AVR +datasheets. +In order to successfully program the EEPROM that way, a prior chip +erase (with the EESAVE fuse unprogrammed) is required. +This also applies to the STK500 and STK600 in high-voltage programming mode. +
+Programming the EEPROM in the terminal, however, will recognise that the +programmer struggles to write to EEPROM and read the flash, EEPROM and, if +present, bootrow contents, perform a chip erase and then write the +memories back. This happens when flushing the cache or leaving the +terminal and, out of necessity, take some time. +
+Solution: If the DWEN (debugWIRE enable) fuse is activated, +the /RESET pin is not functional anymore, so normal ISP +communication cannot be established. +There are two options to deactivate that fuse again: high-voltage +programming, or getting the JTAG ICE mkII talk debugWIRE, and +prepare the target AVR to accept normal ISP communication again. +
+The first option requires a programmer that is capable of high-voltage +programming (either serial or parallel, depending on the AVR device), +for example the STK500. In high-voltage programming mode, the +/RESET pin is activated initially using a 12 V pulse (thus the +name high voltage), so the target AVR can subsequently be +reprogrammed, and the DWEN fuse can be cleared. Typically, this +operation cannot be performed while the AVR is located in the target +circuit though. +
+The second option requires a JTAG ICE mkII that can talk the debugWIRE +protocol. The ICE needs to be connected to the target using the +JTAG-to-ISP adapter, so the JTAG ICE mkII can be used as a debugWIRE +initiator as well as an ISP programmer. AVRDUDE will then be activated +using the jtag2isp programmer type. The initial ISP +communication attempt will fail, but AVRDUDE then tries to initiate a +debugWIRE reset. When successful, this will leave the target AVR in a +state where it can accept standard ISP communication. The ICE is then +signed off (which will make it signing off from the USB as well), so +AVRDUDE has to be called again afterwards. This time, standard ISP +communication can work, so the DWEN fuse can be cleared. +
+The pin mapping for the JTAG-to-ISP adapter is: +
+| JTAG pin | ISP pin |
| 1 | 3 |
| 2 | 6 |
| 3 | 1 |
| 4 | 2 |
| 6 | 5 |
| 9 | 4 |
Solution: The USBtinyISP code supports distinguishing multiple +programmers based on their bus:device connection tuple that describes +their place in the USB hierarchy on a specific host. This tuple can +be added to the -P usb option, similar to adding a serial number +on other USB-based programmers. +
+The actual naming convention for the bus and device names is +operating-system dependent; AVRDUDE will print out what it found +on the bus when running it with (at least) one -v option. +By specifying a string that cannot match any existing device +(for example, -P usb:xxx), the scan will list all possible +candidate devices found on the bus. +
+Examples: +
avrdude -c usbtiny -p atmega8 -P usb:003:025 (Linux) +avrdude -c usbtiny -p atmega8 -P usb:/dev/usb:/dev/ugen1.3 (FreeBSD 8+) +avrdude -c usbtiny -p atmega8 \ + -P usb:bus-0:\\.\libusb0-0001--0x1781-0x0c9f (Windows) + |
For USBasp, the same format for -P usb can be used to match usb bus/device. Alternatively, +device serial number can be specified as follows (for serial number ’1234’). +
+avrdude -c USBasp -p atmega8 -P usb:1234 + |
Solution: debugWIRE mode imposes several limitations. +
+The debugWIRE protocol is Atmel’s proprietary one-wire (plus ground) +protocol to allow an in-circuit emulation of the smaller AVR devices, +using the /RESET line. +DebugWIRE mode is initiated by activating the DWEN +fuse, and then power-cycling the target. +While this mode is mainly intended for debugging/emulation, it +also offers limited programming capabilities. +Effectively, the only memory areas that can be read or programmed +in this mode are flash and EEPROM. +It is also possible to read out the signature. +All other memory areas cannot be accessed. +There is no +chip erase +functionality in debugWIRE mode; instead, while reprogramming the +flash, each flash page is erased right before updating it. +This is done transparently by the JTAG ICE mkII (or AVR Dragon). +The only way back from debugWIRE mode is to initiate a special +sequence of commands to the JTAG ICE mkII (or AVR Dragon), so the +debugWIRE mode will be temporarily disabled, and the target can +be accessed using normal ISP programming. +This sequence is automatically initiated by using the JTAG ICE mkII +or AVR Dragon in ISP mode, when they detect that ISP mode cannot be +entered. +
+Solution: Use the following pin mapping: +
+| JTAGICE | Target | Squid cab- | PDI |
| mkII probe | pins | le colors | header |
| 1 (TCK) | Black | ||
| 2 (GND) | GND | White | 6 |
| 3 (TDO) | Grey | ||
| 4 (VTref) | VTref | Purple | 2 |
| 5 (TMS) | Blue | ||
| 6 (nSRST) | PDI_CLK | Green | 5 |
| 7 (N.C.) | Yellow | ||
| 8 (nTRST) | Orange | ||
| 9 (TDI) | PDI_DATA | Red | 1 |
| 10 (GND) | Brown |
Solution: Use the 6 pin ISP header on the Dragon and the following pin mapping: +
+| Dragon | Target |
| ISP Header | pins |
| 1 (SDI) | PDI_DATA |
| 2 (VCC) | VCC |
| 3 (SCK) | |
| 4 (SDO) | |
| 5 (RESET) | PDI_CLK / RST |
| 6 (GND) | GND |
Solution: Use the following pin mapping: +
+| AVRISP | Target | ATtiny |
| connector | pins | pin # |
| 1 (SDI) | TPIDATA | 1 |
| 2 (VTref) | Vcc | 5 |
| 3 (SCK) | TPICLK | 3 |
| 4 (SDO) | ||
| 5 (RESET) | /RESET | 6 |
| 6 (GND) | GND | 2 |
Solution: Since TPI has only 1 pin for bi-directional data transfer, both +SDI and SDO pins should be connected to the TPIDATA pin +on the ATtiny device. +However, a 1K resistor should be placed between the SDO and TPIDATA. +The SDI pin connects to TPIDATA directly. +The SCK pin is connected to TPICLK. +
+In addition, the Vcc, /RESET and GND pins should +be connected to their respective ports on the ATtiny device. +
+Solution: When connecting the FT232 directly to the pins of the target Atmel device,
+the polarity of the pins defined in the programmer definition should be
+inverted by prefixing a tilde. For example, the dasa programmer would
+look like this when connected via a FT232R device (notice the tildes in
+front of pins 7, 4, 3 and 8):
+
programmer + id = "dasa_ftdi"; + desc = "serial port banging, reset=rts sck=dtr sdo=txd sdi=cts"; + type = serbb; + reset = ~7; + sck = ~4; + sdo = ~3; + sdi = ~8; +; + |
Note that this uses the FT232 device as a normal serial port, not using the +FTDI drivers in the special bitbang mode. +
+Solution: Mind the limited programming supply voltage range of these +devices. +
+In-circuit programming through TPI is only guaranteed by the datasheet +at Vcc = 5 V. +
+Solution: None by this time (2010 Q1). +
+It is said that the AVR Dragon can only program devices from the A4 +Xmega sub-family. +
+Solution: This is a bug caused by an incorrect handling of zero-length +packets (ZLPs) in some versions of the libusb 0.1 API wrapper that ships +with libusb 1.x in certain Linux distributions. All Linux systems with +kernel versions < 2.6.31 and libusb >= 1.0.0 < 1.0.3 are reported to be +affected by this. +
+See also: http://www.libusb.org/ticket/6 +
+CLKPR register), further ISP connection
+attempts fail. Or a programmer cannot initialize communication with
+a brand new chip.
+
+Solution: Even though ISP starts with pulling /RESET low, the +target continues to run at the internal clock speed either as defined by +the firmware running before or as set by the factory. Therefore, the +ISP clock speed must be reduced appropriately (to less than 1/4 of the +internal clock speed) using the -B option before the ISP initialization +sequence will succeed. +
+As that slows down the entire subsequent ISP session, it might make
+sense to just issue a chip erase using the slow ISP clock
+(option -e), and then start a new session at higher speed.
+Option -D might be used there, to prevent another unneeded
+erase cycle.
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
AVRDUDE supports the programmers below: the left column lists the
+programmer’s id as used for -c, whilst the right column contains a
+short description and the list of available programming interface(s) in
+brackets; see Programmer Definitions). There is more detail about
+each programmer in the AVRDUDE configuration file.
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
AVRDUDE supports the parts below: the left column lists the part’s id, +whilst the right column contains its official part name; alternative +names, if any; and the list of available programming interfaces in +brackets; see Programmer Definitions). There is more detail about +each part in the AVRDUDE configuration file. +
+Notes +
+1. Support of 32-bit AVR (via aWire or AVT32JTAG) is experimental at best. +
+2. Flash addressing above 128 KB is not supported by all programming +hardware, though most will support it. +
+3. The ISP programming protocol of the AT90S1200 differs in subtle ways from +that of other AVRs. Thus, not all ISP programmers support this device. +Known to work are all direct bitbang programmers, and all programmers +talking the STK500v2 protocol. +
+4. Not all programmers can serve all memories that a part has. +Bootloader can never write to fuses, for example. +
+| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| E.1 Classic parts | + | |
| E.2 ATxmegas | + | |
| E.3 Modern AVR Parts | + |
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Classic devices may have the following memories in addition to
+eeprom, flash, signature and lock:
+
calibrationOne or more bytes of RC oscillator calibration data +
efuseExtended fuse byte +
fuseFuse byte in devices that have only a single fuse byte +
hfuseHigh fuse byte +
lfuseLow fuse byte +
prodsigSignature, calibration byte and serial number in a small read-only memory, +which is only documented to be available for ATmega324PB, ATmega328PB, +ATtiny102 and ATtiny104; AVRDUDE generally tries to make this memory +available, also for parts where it is not documented, but not all +programmers may be able to read this memory +
sigrowMemory alias for prodsig +
sernumThe serial number part of prodsig; owing to scarce documentation this may not +actually turn out to be a serial number or be readable by some programmers +
usersigThree extra flash pages for firmware settings; this memory is not erased
+during a chip erase. Only some classic parts,
+ATmega(64|128|256|644|1284|2564)RFR2, have a usersig memory. Usersig is
+different to flash in the sense that it can neither be accessed with ISP
+serial programming nor written to by bootloaders. AVRDUDE offers JTAG
+programming of classic-part usersig memories. As with all flash-type
+memories the -U option can only write 0-bits but not 1-bits.
+Hence, usersig needs to be erased before a file can be written to this
+memory region, e.g., using -T "erase usersig" -U
+usersig:w:parameters.hex:i
+
ioVolatile register memory; it cannot be accessed by external programming +methods only by bootloaders, which has limited use unless the bootloader +jumps to the application directly, i.e., without a WDT reset +
sramVolatile RAM memory; like io it cannot be accessed by external
+programming
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
ATxmega devices have the following memories in addition to
+eeprom, flash, signature and lock:
+
applicationapptablebootcalibrationAn area of 4 (ATxmega-A series) or 5 bytes (ATxmega-B/C/D/E) with
+oscillator calibration values; this is a sub-memory of prodsig
+
+
fusesA logical memory of 7 bytes containing all fuseX of a part, which
+can be used to program all fuses at the same time; note that some of the
+fuse bytes will be reserved, though
+
+
fuse0fuse1fuse6Fault detection action configuration TC4/5 for ATxmega E series parts +
fuseNOther fuse bytes of ATxmega devices, where N is 2, 4 or 5, for system configuration + +
prodsigThe production signature row is a read-only memory section for factory +programmed data such as calibration values for oscillators or analogue +modules; it also contains a serial number that consists of the production +lot number, wafer number and wafer coordinates for the part + +
sernumSerial number with a unique ID for the part consisting of 10 bytes; these
+are part of the prodsig memory above
+
+
sigrowtempsenseA two-byte memory, which is located within prodsig; it contains a 12-bit
+temperature sensor calibration value
+
+
+
usersigAdditional flash memory page that can be used for firmware settings; this +memory is not erased during a chip erase + +
ioVolatile register memory; AVRDUDE can read this memory but not write to it +using external programming + +
sramVolatile RAM memory; cannot be usefully accessed by external programming +
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Currently, the flip2, linuxspi, linuxgpio, raspberry_pi_gpio,
+pickit4_mplab, pickit5 and old-school parallel port programmers such
+as stk200 and dapa support -E exitspec parameter options.
+These let the user decide in which state the programmer pins after ended
+programming session. AVRDUDE only allows one -E option. However,
+multiple exitspec parameters can be specified as one comma-separated list.
+
flip2linuxspilinuxgpioraspberry_pi_gpioParallel port programmershelpShow help menu and exit. +
+ + +resetThe ‘/RESET’ signal will be left activated at program exit, that is it
+will be held low, in order to keep the MCU in reset state afterwards.
+Note in particular that the programming algorithm for the AT90S1200
+device mandates that the ‘/RESET’ signal is active before powering up
+the MCU, so in case an external power supply is used for this MCU type,
+a previous invocation of AVRDUDE with this option specified is one of
+the possible ways to guarantee this condition. flip2 will not
+exit bootloader mode at program exit if reset is used.
+
noresetThe ‘/RESET’ line will be deactivated at program exit, thus allowing the
+MCU target program to run while the programming hardware remains
+connected. flip2 will exit bootloader mode at program exit and
+start the application if noreset is used, and this is the default
+behaviour for this bootloader.
+
Parallel port programmersvccThis option will leave those parallel port pins active (i. e. high) that +can be used to supply ‘Vcc’ power to the MCU. +
+ + +novccThis option will pull the ‘Vcc’ pins of the parallel port down at +program exit. +
+ + +d_highThis option will leave the 8 data pins on the parallel port active +(i.e. high). +
+ + +d_lowThis option will leave the 8 data pins on the parallel port inactive +(i.e. low). +
Pickit 4 (MPLAB)Pickit 5| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Modern 8-bit AVR devices have the following memories in addition to
+eeprom, flash, signature and lock:
+
fuse0fuse1fuse2fuse4A.k.a. tcd0cfg (not all devices): timer counter type D configuration
+
+
fuse5fuse6fuse7A.k.a. append or codesize: either the end of the application code section or the code size in blocks of 256/512 bytes
+
+
+
fuse8A.k.a. bootend or bootsize: end of the boot section or the boot size in blocks of 256/512 bytes
+
+
fuseaA.k.a. pdicfg: configures/locks updi access; it is the only fuse that consists of two bytes
+
+
fusesA logical memory of up to 16 bytes containing all fuseX of a part, which can be used to program all fuses at the same time + +
osc16errTwo bytes typically describing the 16 MHz oscillator frequency error at 3 V and 5 V, respectively + +
osc20errTwo bytes typically describing the 20 MHz oscillator frequency error at 3 V and 5 V, respectively + +
osccal16osccal20prodsigRead-only memory section for factory programmed data such as the +signature, calibration values and serial number + +
sigrowsernumSerial number with a unique ID for the part (10 or 16 bytes) + +
tempsensebootrowExtra page of memory that is only accessible by the MCU in bootloader +code; UDPI can read and write this memory only when the device is +unlocked + + +
userrowExtra page of EEPROM memory that can be used for firmware settings; this +memory is not erased during a chip erase + +
sibSpecial system information block memory with information about AVR family, chip revision etc. + +
ioVolatile register memory; AVRDUDE can program this memory but this is of +limited utility because anything written to the io memory will be undefined or +lost after reset; writing to individual registers in the terminal can +still be used, e.g., to test I/O ports + +
sramVolatile RAM memory; can be read and written but contents will be lost after reset +
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Extended parameters are programmer-specific options; they all start with
+-x. Generally, each programmer will allow -x help, which
+will show a help menu of known extended parameters for this programmer, if
+any, and exit. The extended parameters below are all shown without the
+necessary -x option lead-in. AVRDUDE allows any number of -x
+extended parameters to be specified on the command line.
+
dryrundrybootBoth dryrun and dryboot programmers emulate programming and accept the following parameters: +
+initInitialise memories with human-readable patterns. Flash memory will be
+randomly configured with respect to bootloader, data and code length.
+Patterns can best be seen with fixed-width font and the :I format
+by inspecting the generated hex file or by using, eg, -U
+flash:r:-:I. Patterns in flash memory are executable and represent benign
+AVR code, ie, no I/O memory access. Choose a fixed seed for reproducible
+results.
+
init=<n>Shortcut for -x init -x seed=<n> (see below)
+
randomInitialise memories with random code and values. Flash memory will be +randomly configured with respect to bootloader, data and code length. +Random code in flash will be benign, that is, not accessing I/O memories, +SRAM or flash. Choose a fixed seed for reproducible results. +
+random=<n>Shortcut for -x random -x seed=<n>
+
seed=<n>Seed random number generator with n; the default is
+time(NULL). Setting this option with a fixed positive n will
+make the random choices reproducible, ie, they will stay the same between
+different avrdude runs.
+
JTAG ICE mkII/3Atmel-ICEPICkit 4MPLAB(R) SNAPPower DebuggerAVR DragonWhen using the JTAG ICE mkII, JTAGICE3, Atmel-ICE, PICkit 4, MPLAB(R) SNAP, +Power Debugger or AVR Dragon in JTAG mode, the following extended parameter +is accepted: +
jtagchain=UB,UA,BB,BASetup the JTAG scan chain for UB units before, UA units +after, BB bits before, and BA bits after the target AVR, +respectively. +Each AVR unit within the chain shifts by 4 bits. +Other JTAG units might require a different bit shift count. +
+hvupdiPower Debugger and Pickit 4 only
+
+High-voltage UPDI programming is used to enable a UPDI pin that has previously
+been set to RESET or GPIO mode. Use -x hvupdi to enable high-voltage UPDI
+initialization for supported targets.
+
vtarg=VALUE, vtargPower Debugger only
+
+The voltage generator can be enabled by setting a target voltage.
+The current set-voltage can be read by -x vtarg alone.
+
PICkit 4MPLAB(R) SNAPThe PICkit 4 and MPLAB(R) SNAP programmers accept the following extended parameters: +
mode=avr,mplab/picSwitch programmer to AVR or MPLAB mode, then exit: the PICkit 4 and MPLAB(R) SNAP
+programmer can only be utilised by Avrdude when in AVR mode.
+Use -x mode=avr for switching to AVR mode, or -x mode=mplab
+for switching to MPLAB mode.
+
PICkit 5PICkit 4 (PIC Mode)The PICkit 5 and PICkit 4 (MPLAB Mode) programmer can accept following extended parameters +
vtarg=VALUESpecify a voltage between 1.8 and 5.5 V that the programmer should supply
+to the target. If there is already a valid voltage applied to the VTG Pin,
+this setting will be ignored. When AVRDUDE detects an external voltage outside
+of this range, it will terminate the operation. You can disable this check by
+setting the voltage to 0 V. If an XMEGA part was selected, a requested voltage
+above 3.49 V will lead to an abort of operation.
+Usually, the programmer will stop providing power when the session ends.
+To continue to power the target you can use the -E vcc option.
+
hvupdiHigh-voltage UPDI programming is used to enable a UPDI pin that has previously
+been set to RESET or GPIO mode. Use -x hvupdi to enable high-voltage UPDI
+initialization for supported targets. Depending on the target, the HV pulse will
+be applied either on the RST pin, or the UPDI pin.
+
Xplained MiniThe Xplained Mini/Nano programmer (ISP or UPDI, not TPI) type accepts the +following extended parameters: +
+suffer=VALUE, sufferThe SUFFER register allows the user to modify the behavior of the on-board mEDBG.
+The current state can be read by -x suffer alone.
+
Bit 7 ARDUINO:Adds control of extra LEDs when set to 0 +
Bit 6..3:Reserved (must be set to 1) +
Bit 2 EOF:Agressive power-down, sleep after 5 seconds if no USB enumeration when set to 0 +
Bit 1 LOWP:forc running the mEDBG at 1 MHz when bit set to 0 +
Bit 0 FUSE:Fuses are safe-masked when bit sent to 1. Fuses are unprotected when set to 0 +
vtarg_switch=VALUE, vtarg_switchThe on-board target voltage switch can be turned on or off by writing a 1 or
+a 0. The current state can be read by -x vtarg_switch alone.
+Note that the target power switch will always be on after a power cycle.
+Also note that the smaller Xplained Nano boards does not have a target power switch.
+
Curiosity NanoThe Curiosity Nano board accepts the following extended parameter: +
vtarg=VALUE, vtargThe generated on-board target voltage can be changed by specifying a new voltage.
+The current set-voltage can be read by -x vtarg alone.
+
STK500STK600The STK500 and STK600 boards accept the following extended parameters: +
vtarg=VALUE, vtargThe generated on-board target voltage can be changed by specifying a new voltage.
+The current set-voltage can be read by -x vtarg alone.
+
fosc=VALUE[MHz|M|kHz|k|Hz|H], foscSet the programmable oscillator frequency in MHz, kHz or Hz.
+The current frequency can be read by -x fosc alone.
+
varef=VALUE, varefThe generated on-board analog reference voltage can be changed by specifying
+a new reference voltage. The current reference voltage can be read by
+-x varef alone.
+
varef[0,1]=VALUE, varef[0,1]STK600 only
+
+The generated on-board analog reference voltage for channel 0 or channel 1 can
+be changed by specifying a new reference voltage.
+The current reference voltage can be read by -x varef0 or
+-x varef1 alone.
+
attempts[=<1..99>]STK500V1 only
+
+Specify how many connection retry attempts to perform before exiting.
+Defaults to 10 if not specified.
+
xtal=VALUE[MHz|M|kHz|k|Hz|H]Defines the XTAL frequency of the programmer if it differs from 7.3728 MHz of the +original STK500. Used by avrdude for the correct calculation of fosc and sck. +
AVR109The AVR109 programmer type accepts the following extended parameter: +
autoresetToggle RTS/DTR lines on port open to issue a hardware reset. +
AVR910The Atmel low-cost AVR910 programmer type accepts the following extended parameter: +
devcode=VALUEOverride the device code selection by using VALUE
+as the device code.
+The programmer is not queried for the list of supported
+device codes, and the specified VALUE
+is not verified but used directly within the
+T command sent to the programmer.
+VALUE can be specified using the conventional number notation of the
+C programming language.
+
no_blockmodeDisables the default checking for block transfer capability.
+Use
+no_blockmode only if your AVR910
+programmer creates errors during initial sequence.
+
ArduinoThe Arduino programmer type accepts the following extended parameter: +
attempts[=<1..99>]Specify how many connection retry attempts to perform before exiting. +Defaults to 10 if not specified. +
noautoresetDo not toggle RTS/DTR lines on port open to prevent a hardware reset. +
UrclockThe urclock programmer type accepts the following extended parameters: +
showallShow all info for the connected part, then exit. The -x show... options
+below can be used to assemble a bespoke response consisting of a subset
+(or only one item) of all available relevant information about the
+connected part and bootloader.
+
+
+
showidShow a unique Urclock ID stored in either flash or EEPROM of the MCU, then exit. +
id=<E|F>.<addr>.<len>Historically, the Urclock ID was a six-byte unique little-endian number
+stored in Urclock boards at EEPROM address 257. The location of this
+number can be set by the -x id=<E|F>.<addr>.<len> extended parameter. E
+stands for EEPROM and F stands for flash. A negative address addr counts
+from the end of EEPROM and flash, respectively. The length len of the
+Urclock ID can be between 1 and 8 bytes.
+
+
showdateShow the last-modified date of the input file for the flash application,
+then exit. If the input file was stdin, the date will be that of the
+programming. Date and filename are part of the metadata that the urclock
+programmer stores by default in high flash just under the bootloader; see also
+
+-x nometadata.
+
showfilenameShow the input filename (or title) of the last flash writing session, then exit. +
title=<string>When set, <string> will be used in lieu of the input filename. The maximum +string length for the title/filename field is 254 bytes including +terminating nul. +
showappshowstoreShow the size of the unused flash between the application and metadata, then exit. +
showmetaShow the size of the metadata just below the bootloader, then exit. +
showbootShow the size of the bootloader, then exit. +
showversionShow bootloader version and capabilities, then exit. +
showvectorShow the vector number and name of the interrupt table vector used by the
+bootloader for starting the application, then exit. For hardware-supported
+bootloaders this will be vector 0 (Reset), and for vector bootloaders this
+will be any other vector number of the interrupt vector table or the slot
+just behind the vector table with the name VBL_ADDITIONAL_VECTOR.
+
showpartShow the part for which the bootloader was compiled, then exit. + +
bootsize=<size>Manual override for bootloader size. Urboot bootloaders put the number of +used bootloader pages into a table at the top of the bootloader section, +i.e., typically top of flash, so the urclock programmer can look up the +bootloader size itself. In backward-compatibility mode, when programming +via other bootloaders, this option can be used to tell the programmer the +size, and therefore the location, of the bootloader. + +
vectornum=<n>Manual override for vector number. Urboot bootloaders put the vector +number used by a vector bootloader into a table at the top of flash, so +this option is normally not needed for urboot bootloaders. However, it is +useful in backward-compatibility mode (or when the urboot bootloader does +not offer flash read). Specifying a vector number in these circumstances +implies a vector bootloader whilst the default assumption would be a +hardware-supported bootloader. + +
eepromrwManual override for asserting EEPROM read/write capability. Not normally +needed for urboot bootloaders, but useful for in backward-compatibility +mode if the bootloader offers EEPROM read/write. + +
emulate_ceIf an urboot bootloader does not offer a chip erase command it will tell +the urclock programmer so during handshake. In this case the urclock +programmer emulates a chip erase, if warranted by user command line +options, by filling the remainder of unused flash below the bootloader +with 0xff. If this option is specified, the urclock programmer will assume +that the bootloader cannot erase the chip itself. The option is useful +for backwards-compatible bootloaders that do not implement chip erase. + +
restoreWrite unchanged flash input files to the AVR and trim below the bootloader if
+needed. This is most useful when one has a backup of the full flash and
+wants to play that back onto the device. No metadata are written in this
+case and no vector patching happens either if it is a vector bootloader.
+However, for vector bootloaders, even under the option -x restore an
+input file will not be written to the AVR for which the reset vector does not point
+to the vector bootloader. This is to avoid loading an input file onto the
+device that would render the vector bootloader becoming unreachable after reset.
+
+
initstoreOn writing to flash fill the store space between the flash application and +the metadata section with 0xff. + +
nofilenameOn writing to flash do not store the application input filename (nor a title). + +
nodateOn writing to flash do not store the application input filename (nor a +title) and no date either. + +
nostoreOn writing to flash do not store metadata except the metadata code byte
+0xff saying there are no metadata. In particular, no data store
+frame is programmed.
+
+
+
nometadataDo not support any metadata. The full flash besides the bootloader is
+available for the application. If the application is smaller than the
+available space then a metadata code byte 0xff is stored
+nevertheless to indicate there are no further metadata available. In
+absence of -x nometadata, the default for the urclock programmer is
+to write as much metadata (filename, data and store information) as the
+size of the application and the other extended options allow. The
+subtle difference between -x nometadata and -x nostore is that
+the latter always explicitly stores in flash that no further metadata are
+available, so that a such prepared flash can always be queried with
+avrdude -x showall. In contrast to this, it cannot be guaranteed
+that a -x showall query on flash prepared with -x nometadata
+yields useful results.
+
noautoresetDo not toggle RTS/DTR lines on port open to prevent a hardware reset. +
delay=<n>Add a <n> ms delay after reset. This can be useful if a board takes a +particularly long time to exit from external reset. <n> can be negative, +in which case the default 120 ms delay after issuing reset will be +shortened accordingly. +
strictUrclock has a faster, but slightly different strategy than -c arduino to
+synchronise with the bootloader; some stk500v1 bootloaders cannot cope
+with this, and they need the -x strict option.
+
BusPirateThe BusPirate programmer type accepts the following extended parameters: +
reset=cs,aux,aux2The default setup assumes the BusPirate’s CS output pin connected to +the RESET pin on AVR side. It is however possible to have multiple AVRs +connected to the same BP with SDI, SDO and SCK lines common for all of them. +In such a case one AVR should have its RESET connected to BusPirate’s +CS +pin, second AVR’s RESET connected to BusPirate’s +AUX +pin and if your BusPirate has an +AUX2 +pin (only available on BusPirate version v1a with firmware 3.0 or newer) +use that to activate RESET on the third AVR. +
+It may be a good idea to decouple the BusPirate and the AVR’s SPI buses from +each other using a 3-state bus buffer. For example 74HC125 or 74HC244 are some +good candidates with the latches driven by the appropriate reset pin (cs, +aux or aux2). Otherwise the SPI traffic in one active circuit may interfere +with programming the AVR in the other design. +
+spifreq=0..70 | 30 kHz (default) |
1 | 125 kHz |
2 | 250 kHz |
3 | 1 MHz |
4 | 2 MHz |
5 | 2.6 MHz |
6 | 4 MHz |
7 | 8 MHz |
rawfreq=0..3Sets the SPI speed and uses the Bus Pirate’s binary “raw-wire” mode instead +of the default binary SPI mode: +
+0 | 5 kHz |
1 | 50 kHz |
2 | 100 kHz (Firmware v4.2+ only) |
3 | 400 kHz (v4.2+) |
The only advantage of the “raw-wire” mode is that different SPI frequencies +are available. Paged writing is not implemented in this mode. +
+pullupsEnable the Bus Pirate’s built-in pull-up resistors. These resistors are +useful when working with different voltage levels. VPU pin of the Bus Pirate +must be connected to an external voltage. +For example: connect VPU pin to the +5V pin or an external power supply. +
+hizEnable the Bus Pirate’s HiZ mode on SPI, allowing it to work as an +open-collector and interface with external pull-up circuits. +If the external target circuit does not have pull-ups, the Bus Pirate +will not be able to send data. +
+asciiAttempt to use ASCII mode even when the firmware supports BinMode (binary
+mode).
+BinMode is supported in firmware 2.7 and newer, older FW’s either don’t
+have BinMode or their BinMode is buggy. ASCII mode is slower and makes
+the above
+reset=, spifreq=
+and
+rawfreq=
+parameters unavailable. Be aware that ASCII mode is not guaranteed to work
+with newer firmware versions, and is retained only to maintain compatibility
+with older firmware versions.
+
nopagedwriteFirmware versions 5.10 and newer support a binary mode SPI command that enables +whole pages to be written to AVR flash memory at once, resulting in a +significant write speed increase. If use of this mode is not desirable for some +reason, this option disables it. +
+nopagedreadNewer firmware versions support in binary mode SPI command some AVR Extended +Commands. Using the “Bulk Memory Read from Flash” results in a +significant read speed increase. If use of this mode is not desirable for some +reason, this option disables it. +
+cpufreq=125..4000This sets the AUX pin to output a frequency of n kHz. Connecting +the AUX pin to the XTAL1 pin of your MCU, you can provide it a clock, +for example when it needs an external clock because of wrong fuses settings. +Make sure the CPU frequency is at least four times the SPI frequency. +
+serial_recv_timeout=1...This sets the serial receive timeout to the given value. +The timeout happens every time avrdude waits for the BusPirate prompt. +Especially in ascii mode this happens very often, so setting a smaller value +can speed up programming a lot. +The default value is 100 ms. Using 10 ms might work in most cases. +
+Micronucleus bootloaderThe Micronucleus programmer type accepts the following extended parameter: +
wait=timeoutIf the device is not connected, wait for the device to be plugged in. +The optional timeout specifies the connection time-out in seconds. +If no time-out is specified, AVRDUDE will wait indefinitely until the +device is plugged in. +
Teensy bootloaderThe Teensy programmer type accepts the following extended parameter: +
wait=timeoutIf the device is not connected, wait for the device to be plugged in. +The optional timeout specifies the connection time-out in seconds. +If no time-out is specified, AVRDUDE will wait indefinitely until the +device is plugged in. +
WiringThe Wiring programmer type accepts the following extended parameters: +
snooze=<n>After performing the port open phase, AVRDUDE will wait/snooze for +snooze milliseconds before continuing to the protocol sync phase. +No toggling of DTR/RTS is performed if snooze > 0. +
delay=<n>Add a <n> milliseconds delay after reset. This can be useful if a board +takes a particularly long time to exit from external reset. <n> can be +negative, in which case the default 100 ms delay after issuing reset will +be shortened accordingly. +
PICkit2Connection to the PICkit2 programmer: +
(AVR) | (PICkit2) |
RST | VPP/MCLR (1) |
VDD | VDD Target (2) -- possibly optional if AVR self powered |
GND | GND (3) |
SDI | PGD (4) |
SCLK | PDC (5) |
OSI | AUX (6) |
The PICkit2 programmer type accepts the following extended parameters: +
clockrate=rateSets the SPI clocking rate in Hz (default is 100 kHz). Alternately the -B or -i options can be used to set the period. +
timeout=usb-transaction-timeoutSets the timeout for USB reads and writes in milliseconds (default is 1500 ms). +
USBaspThe USBasp programmer type accepts the following extended parameter: +
section_configProgrammer will erase +configuration section with option ’-e’ (chip erase), +rather than entire chip. +Only applicable to TPI devices (ATtiny 4/5/9/10/20/40). +
xbeeThe xbee programmer type accepts the following extended parameter: +
xbeeresetpin=1..7Select the XBee pin DIO<1..7> that is connected to the MCU’s
+/RESET line. The programmer needs to know which DIO pin to use to
+reset into the bootloader. The default (3) is the DIO3 pin
+(XBee pin 17), but some commercial products use a different XBee
+pin.
+
The remaining two necessary XBee-to-MCU connections are not selectable
+- the XBee DOUT pin (pin 2) must be connected to the MCU’s
+RXD line, and the XBee DIN pin (pin 3) must be connected to
+the MCU’s TXD line.
+
jtag2updiserialupdiThe jtag2updi and serialupdi programmer types accept the following extended parameters: +
rtsdtr=low,highForces RTS/DTR lines to assume low or high state during the whole +programming session. Some programmers might use this signal to +indicate UPDI programming state, but this is strictly hardware +specific. +
+When not provided, driver/OS default value will be used. +
+linuxspiThe linuxspi programmer type accepts the following extended parameter: +
disable_no_csEnsures the programmer does not use the SPI_NO_CS bit for the SPI +driver. This parameter is useful for kernels that do not support +the CS line being managed outside the application. +
serprogThe serprog programmer type accepts the following extended parameter: +
csSets the chip select (CS) to use on supported programmers. +Programmers supporting the 0x16 serprog command can have more than the default CS (0). +This option allows to choose these additional CSes (1, 2, ...) for programming the AVR. +
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| Jump to: | !
+
+-
+
+1
+
+2
+
+3
+
+4
+
+6
+
+8
+
+ +A + +B + +C + +D + +E + +F + +H + +I + +J + +K + +L + +M + +N + +O + +P + +Q + +R + +S + +T + +U + +V + +W + +X + + |
|---|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
AVRDUDE error messages, warnings and progress reports are generally
+written to stderr which can, in bash, be turned off by 2>/dev/null
+or by using increasingly more -q options to suppress them. Terminal
+output of commands or that of the -U command with an output file
+named - are written to stdout. In some examples empty lines are
+shown for clarity that are not printed by AVRDUDE or the shell.
+
Write the file diag.hex to the ATmega128 chip using the
+STK500 programmer connected to the default serial port:
+
|
Same but in quell-progress-reporting (silent) mode -qq:
+
|
Using && to confirm that the silent AVRDUDE command went OK:
+
|
Save flash memory in raw binary format to the file named c:/diag flash.bin:
+
|
Read the fuses and print their values in different formats (hexadecimal, binary and octal): +
+
|
Using the default programmer, write the file diag.hex to flash, the
+file eeprom.hex to EEPROM, and set the extended, high, and
+low fuse bytes to 0xff, 0x89, and 0x2e respectively:
+
|
Write data from stdin (standard input) to EEPROM; no error output means all went fine: +
+
|
Execute multiple terminal mode commands separated by semicolons: +
+
|
The same using -T: +
+
|
Read EEPROM and write content to stdout (standard output): +
+
|
Same but redirect stderr (standard error output) to /dev/null instead of using -qq:
+
|
Using the Avrdude output to print strings present in flash memory: +
+
|
List the serial numbers of all JTAG ICEs attached to USB; this is +done by specifying an invalid serial number, and increasing the +verbosity level: +
+
|
Connect to the JTAG ICE mkII with a serial number ending in 1C37 +via USB, enter interactive terminal mode, list all commands for +the connected part and quit: +
+
|
Factory fuse setting of a device: +
+
|
List of all parts known to AVRDUDE: +
+
|
List of all modern AVR parts (with UPDI interface) known to AVRDUDE: +
+
|
List of all curently plugged-in serial devices known to the libserialport library: +
+
|
List of all serial adapters known to AVRDUDE, i.e., defined in avrdude.conf: +
+
|
Output a list of non-bootloader programmers that can be used for a part. +Note that 2>&1 folds stderr into stdout in a bash shell: +
|
Print programmer definition as understood by AVRDUDE: +
|
Print filename of last stored sketch with its date stamp (only with urclock programmer): +
|
AVRDUDE in a bash script creating terminal scripts that reset a part to factory settings: +
|
Run above script and use one of the created terminal scripts: +
|
Create a bash function avrdude-elf that takes an elf file as input,
+with support for optional Avrdude flags at the end, and writes to all memories
+specified in the elf file. In this example, the elf file did not contain any
+EEPROM data:
+
|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
AVRDUDE has an interactive mode called terminal mode that is +enabled by the ‘-t’ option. This mode allows one to enter +interactive commands to display and modify the various device memories, +perform a chip erase, display the device signature bytes and part +parameters, and to send raw programming commands. Commands and +parameters may be abbreviated to their shortest unambiguous form. +Terminal mode also supports a command history so that previously entered +commands can be recalled and edited. +
+| 3.1 Terminal Mode Commands | + | |
| 3.2 Terminal Mode Examples | + |
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
In this mode, AVRDUDE only initializes communication with the MCU, and then +awaits user commands on standard input. Commands and parameters may be +abbreviated to the shortest unambiguous form. Terminal mode provides a +command history using readline(3), so previously entered command lines can be +recalled and edited. +
+The addr and len parameters of the dump, read, disasm, write,
+save and erase commands can be negative with the same syntax as substring
+computations in perl or python. The table below details their meaning with
+respect to an example memory of size sz=0x800 (2048 bytes).
+
addr | len | Memory interval | Comment |
|---|---|---|---|
| 0/positive | positive | [addr, addr+len-1] | Note: len = end-start + 1 |
| 0/positive | negative | [addr, sz+len] | End is |len| bytes below memory size sz |
| negative | positive | [sz+addr, …] | Start is |addr| bytes below memory size |
| negative | negative | [sz+addr, sz+len] | Combining above two cases |
| any | zero | empty set | No action |
| 0x700 | 12 | [0x700, 0x70b] | Conventional use |
| 1024 | -257 | [0x400, 0x6ff] | Size of memory is 2048 or 0x800 |
| -512 | 512 | [0x600, 0x7ff] | Last 512 bytes |
| -256 | -1 | [0x700, 0x7ff] | Last 256 bytes |
| 0 | 49 | [0, 48] | First 49 bytes |
| 0 | -49 | [0, 1999] | All but the last 48 = |len+1| bytes |
| 0 | -1 | [0, 0x7ff] | All memory without knowing its size |
The following commands are implemented for all programmers: +
+dump memory addr lenRead from the specified memory interval (see above), and display in the +usual hexadecimal and ASCII form. +
+dump memory addrRead from memory addr as many bytes as the most recent dump memory addr +len command with this very memory had specified (default 256 bytes), and +display them. +
+dump memoryContinue dumping from the memory and location where the most recent dump +command left off; if no previous dump command has addressed a memory an +error message will be shown. +
+dumpContinue dumping from the memory and location where the most recent dump +command left off; if no previous dump command has addressed a memory an +error message will be shown. +
+dump memory addr …Start reading from addr, all the way to the last memory address
+(deprecated: use dump memory addr -1).
+
dump memory …Read all bytes from the specified memory, and display them (deprecated:
+use dump memory 0 -1).
+
readCan be used as an alias for dump. +
+disasm [options] dump-argumentsLike dump, the disasm command displays a part of the specified memory, +albeit by interpreting the memory contents as AVR opcodes and showing it +as assembler source code. Unlike dump, the disasm command has options; +these control how disasm displays its result (see below). Other than that, +the syntax of specifying the memory and its to be processed interval is +virtually the same as that of dump: the default disasm length is 32 bytes, +though, and sometimes the length can be slightly shorter or longer than +requested, so that the memory section for disasm aligns with opcodes. +Disasm options, once set, stay in force until switched off, typically by +changing the case of the option. This way, a simple disasm without further +options can be used to step through memory keeping the appearance. Disasm +knows the following options: +
-gGenerate avr-gcc source: this sets -sOFQ and outputs a .text preamble and
+a main symbol unless the disassembly emits one itself; -G (default)
+switches off -g and stops outputting a preamble
+
-ADo not show addresses; -a (the default) shows addresses
+
-ODo not show opcode bytes; -o (the default) show opcode bytes
+
-CDo not show comments; -c (the default) show comments
+
-fShow affected flags in SREG, eg, ---SVNZC for the sbiw
+opcode; -F (the default) do not show SREG flags
+
-qShow the number of machine cycles that an opcode takes; -Q
+(the default) do not show the cycles
+
-nPut the opcode full name into comment (eg, subtract immediate from word);
+-N (the default) do not show the full opcode names
+
-ePut a technical explanation of the opcode into the comment, eg,
+Rd+1:Rd <-- Rd+1:Rd - K for the sbiw opcode; -E (the
+default) do not show technical explanations
+
-SUse AVR instruction set style: this means that register pairs are shown
+as, eg, in r31:30 instead of r30; -s (the default) use avr-gcc code
+style
+
-LDo not preprocess labels; -l (the default) preprocess jump/call
+labels
+
-UDo not show unused labels; -u (the default) show unused tagged labels
+
-dDecode all opcodes including those that are undocumented; -D (the
+default) decode only opcodes that are valid for the part
+
-zZap the list of jumps and calls before disassembly +
+-t=fileDelete symbols from a previously read tagfile, if any, and read the +tagfile file for assigning addresses to symbol names. +
The tagfile is an ASCII file where each line describes a symbol for code
+label addresses (L), variable addresses in flash (P) and
+variables addresses in memory or I/O space (M). Hashmarks start a
+tagfile comment that extends to the end of the line and is ignored by
+disasm. Here is a defining example of how a tagfile looks like
+
|
Code labels L can be, eg, function names in program space or goto
+labels. They use up to four columns separated by white space: the
+address, the letter L, the symbolic name of the label and an
+optional comment column for the symbol, which is copied by disasm into the
+disassembly comment column, should this label be referenced or used by the
+code. Variable symbols have a P or M in the second column;
+they can be bytes or words (16 bits) as determined by the letter B
+or W in the third column and either single variables or arrays as
+specified by the multiplicity count in the forth column. P symbols,
+but not M symbols, can also encode chars (8 bits), longs (32 bits),
+quads (64 bits) or octas (128 bits) as signified by the letters C,
+L, Q or O, respectively, or be the base location of
+nul-terminated strings as encoded by A or S in the third
+column. Out of necessity, the space occupied by A/S strings
+varies. The difference between A and S symbols is that the
+array of A strings might have an additional nul character to
+auto-align the space occupied by them to an even address. The fifth column
+is the symbolic name for the P or M address that can be used
+by disasm to output relevant addresses symbolically. P areas
+described in the tagfile also tell disasm that the corresponding area is
+not code and should not be disassembled as such; instead the directives
+are used for disassembly of that area. As with L labels, P
+and M variables may have an optional final comment column
+pertaining to the symbol that may be output in the disassembly column as
+and when the corresponding variables are used.
+
Tagfiles are useful for disassembly to make the output of disasm more
+readable. They can be built manually and incrementally as one’s under‐
+standing of the code grows. Alternatively, the bash shell script
+elf2tag can automatically generate a tag file from the .elf file
+that produced the flash contents:
+
|
elf2tag uses the avr-objdump -d disassembly to create
+L labels and avr-nm to generate M symbols.
+
write memory addr data[,] {data[,]}Manually program the respective memory cells, starting at address +addr, using the data items provided. The terminal implements reading +from and writing to flash, EEPROM, bootrow and usersig type memories normally +through a cache and paged access functions. All other memories are +directly written to without use of a cache. Some older parts without paged +access, depending on the programmer, might also have flash and EEPROM +directly accessed without cache. +Items data can have the following formats: +
+| Type | Example | Size (bytes) |
| String | "Hello, world\n" | varying |
| File | C:/My\ projects/blink.hex | varying |
| File with format | blink.hex:i | varying |
| Character | 'A' | 1 |
| Binary integer | 0b101010 | 1, 2, 4, or 8 |
| Octal integer | 012345 | 1, 2, 4, or 8 |
| Decimal integer | 12345 | 1, 2, 4, or 8 |
| Hexadecimal integer | 0x12345 | 1, 2, 4, or 8 |
| Decimal float | 3.1415926 | 4 |
| Hexadecimal float | 0xA.8p2 | 4 |
| Decimal double | 3.141592653589793D | 8 |
| Hexadecimal double | 0xA.8p2D | 8 |
data
+can be binary, octal, decimal or hexadecimal integers, floating point
+numbers or C-style strings and characters. If nothing matches, data
+will be interpreted as a name of a file containing data, which will be
+read and inserted at this point. In order to force the interpretation of a
+data item as file, e.g., when the file name would be understood as a
+number otherwise, the file name can be given a :f format
+specifier. In absence of a format suffix, the terminal will try to
+auto-detect the file format.
+
A file name that starts with urboot: autogenerates a read-only
+urboot bootloader file. Try for example the terminal command write
+flash urboot:help for a list of features that determine the contents of
+the bootloader. See section Autogenerated files for detailed documentation. It
+is worth noting here that writing urboot:... files to flash in the
+terminal does not write the necessary fuses for the bootloader to
+work (in contrast to -U operations).
+
For integers, an optional case-insensitive suffix specifies the data size: +
+LL | 8 bytes (64 bits) |
L | 4 bytes (32 bits) |
H or S | 2 bytes (16 bits) |
HH | 1 byte (8 bits) |
Suffix D indicates a 64-bit double, F a 32-bit float, whilst a
+floating point number without suffix defaults to 32-bit float. Hexadecimal
+floating point notation is supported. An ambiguous trailing suffix, e.g.,
+0x1.8D, is read as no-suffix float where D is part of the
+mantissa; use a zero exponent 0x1.8p0D to clarify.
+
An optional U suffix makes integers unsigned. Ordinary 0x
+hexadecimal and 0b binary integers are always treated as unsigned.
++0x, -0x, +0b and -0b numbers with an explicit
+sign are treated as signed unless they have a U suffix. Unsigned
+integers cannot be larger than 2^64-1. If n is an unsigned integer
+then -n is also a valid unsigned integer as in C. Signed integers
+must fall into the [-2^63, 2^63-1] range or a correspondingly smaller
+range when a suffix specifies a smaller type.
+
Ordinary 0x hexadecimal and 0b binary integers with n
+hex digits (counting leading zeros) use the smallest size of one, two,
+four and eight bytes that can accommodate any n-digit hexadecimal/binary
+integer. If an integer suffix specifies a size explicitly the
+corresponding number of least significant bytes are written, and a warning
+shown if the number does not fit into the desired representation.
+Otherwise, unsigned integers occupy the smallest of one, two, four or
+eight bytes needed. Signed numbers are allowed to fit into the smallest
+signed or smallest unsigned representation: For example, 255 is
+stored as one byte as 255U would fit in one byte, though as a
+signed number it would not fit into a one-byte interval [-128, 127]. The
+number -1 is stored in one byte whilst -1U needs eight bytes
+as it is the same as 0xFFFFffffFFFFffffU.
+
One trailing comma at the end of data items is ignored to facilitate copy +and paste of lists. +
+write memory dataThe start address may be omitted if the size of the memory being written +to is one byte. data can be anything including a file. +
+write memory fileThe start address may be omitted when a file is written to the memory. +
+write memory addr len data[,] {data[,]} …The ellipsis … form writes the data to the entire memory intervall +addressed by addr len and, if necessary, pads the remaining space by +repeating the last data item. The fill write command does not write beyond +the specified memory area even if more data than needed were given. +
+save memory {addr len} file[:format]Save one or more memory segments to a file in a format specified by the
+:format letter. The default is :r for raw binary. Each
+memory segment is described by an address and length pair. In absence of
+any memory segments the entire memory is saved to the file. Only Motorola
+S-Record (:s) and Intel Hex (:i or :I) formats store
+address information with the saved data. Avrdude cannot currently save
+ELF file formats. All the other file formats lose the address information
+and concatenate the chosen memory segments into the output file. If the
+file name is - then avrdude writes to stdout.
+
backup memlist file[:format]Backup one or more memories to the specified file using the selected
+format. The default format for a single-memory backup is :r (raw
+binary); for multi-memory backups it is :I (Intel Hex with
+comments). Memlist can be a comma separated list of memories just as
+in the -U command line argument. backup flushes the cache
+before reading memories.
+
restore memlist file[:format]Restore one or more memories from the specified file. It is the user’s
+responsibility to erase memories as needed beforehand: some paged memories
+look like NOR-memory when using certain programmers, meaning programming
+cannot set bits to 1 (eg, flash under most programmers). These memories
+need to be erased beforehand using the erase command (see below). The
+format only needs to be specified if it cannot be automatically detected,
+eg, when the file is - for standard input. Memlist can be a
+comma separated list of memories just as in the -U command line
+argument. restore flushes the cache before writing memories and
+resets the cache after writing memories. Note that restoring read-only
+memories verifies file contents with the corresponding microprocessor’s
+memories.
+
verify memlist file[:format]Compare one or more memories with the specified file. Memlist can be a
+comma separated list of memories just as in the -U command line
+argument. verify flushes the cache before verifying memories.
+
erasePerform a chip erase and discard all pending writes to flash, EEPROM and bootrow. +Note that EEPROM will be preserved if the EESAVE fuse bit is active, ie, had +a corresponding value at the last reset prior to the operation. +
+erase memoryErase the entire specified memory. +
+erase memory addr lenErase a section of the specified memory. +
+flushSynchronise with the device all pending writes to flash, EEPROM, bootrow and +usersig. With some programmer and part combinations, flash (and sometimes +EEPROM, too) looks like a NOR memory, i.e., a write can only clear bits, +never set them. For NOR memories a page erase or, if not available, a chip +erase needs to be issued before writing arbitrary data. Usersig is +unaffected by a chip erase. When a memory looks like a NOR +memory, either page erase is deployed (e.g., with parts that have PDI/UPDI +interfaces), or if that is not available, both EEPROM and flash caches are +fully read in, a chip erase command is issued and both EEPROM and flash +are written back to the device. Hence, it can take minutes to ensure that +a single previously cleared bit is set and, therefore, this routine should +be called sparingly. +
+ + + + + +abortNormally, caches are only ever actually written to the device when using
+flush, at the end of the terminal session after typing quit,
+or after EOF on input is encountered. The abort command resets the
+cache discarding all previous writes to the flash, EEPROM, bootrow and
+usersig cache.
+
config [-f|-a|-v]Show all configuration properties of the part; these are usually bitfields
+in fuses or lock bits bytes that can take on values, which typically have
+a mnemonic name. Each part has their own set of configurable items. The
+option -f groups the configuration properties by the fuses and lock
+bits byte they are housed in, and shows the current value of these
+memories as well. Config -a outputs an initialisation script with
+all properties and all possible respective assignments. The currently
+assigned mnemonic values are the ones that are not commented out. The
+option -v increases the verbosity of the output of the config
+command.
+
config [-f|-v] property [-f|-v]Show the current value of the named configuration property. Wildcards or +initial strings are permitted (but not both), in which case the current +values of all matching properties are displayed. +
+config [-f|-v] property= [-f|-v]Show all possible values of the named configuration property (notice the
+trailing =). The one that is currently set is the only one not
+commented out. As before, wildcards or initial strings are permitted.
+
config [-f|-v|-c] property=value [-f|-v|-c]Modify the named configuration property to the given value. The
+corresponding fuse or lock bits will be changed immediately but the change
+will normally only take effect the next time the part is reset, at which
+point the fuses and lock bits are utilised. Value can either be a valid
+integer or one of the symbolic mnemonics, if known. Wildcards or initial
+strings are permitted for either the property or the assigned mnemonic
+value, but an assignment only happens if both the property and the name
+can be uniquely resolved. Option -v shows the value of the assigned
+configuration property by reading it again from the fuse. In absence of
+-v the option -c confirms the new value of the configuration
+property only if it has changed.
+
It is quite possible, as is with direct writing to the underlying fuses +and lock bits, to brick a part, i.e., make it unresponsive to further +programming with the chosen programmer: here be dragons. +
+ + +factory resetResets the connected part to factory state as far as possible
+(bootloaders, for example, cannot write fuses and may not have a means to
+erase EEPROM). This command may change the clock frequency F_CPU of the
+part after the next MCU reset when the changed fuse values come into
+effect. As such, this may require that future avrdude calls use a
+different bit clock rate up to F_CPU/4 for the programmer next time. Note
+that the command factory can be abbreviated but the required
+argument reset needs to be spelled out in full.
+
regfile [opts]regfile with no further argument displays the register file of a
+part, i.e., all register names and their contents in io memory, if
+possible: note that external programming cannot read the registers of
+classic parts (ISP or TPI interfaces).
+
Option -a displays the register I/O addresses in addition;
+-m displays the register memory addresses used for
+lds/sts opcodes instead of the I/O addresses. Option
+-s also shows the size of the register in bytes whilst -v
+shows a slightly expanded register explanation alongside each register.
+
regfile [opts] reg [opts]regfile together with a register name reg shows all those
+registers that are matched by reg. Wildcards or partial strings are
+permitted but not both. Register names have the form module.name or
+module.instance.name. If the provided reg is a full, existing
+register name, e.g., porta.out then that is the only register that
+is displayed even though that might be a partial name of another register,
+eg, porta.outdir. If the provided reg is the same as
+instance.name or name then partial matching is no longer
+utilised and all module registers with that exact instance.name or
+name are shown. Partial matching can be forced through use of
+wildcards, e.g., using porta.out*
+
regfile [opts] reg=value [opts]This sets a single register addressed by reg to the given +value. Only external programming of modern parts (those with UPDI +interface) can read from and write to register io memory, but as that +memory is volatile, the contents will be lost after reset. +
+include [opts] fileInclude contents of the named file file as if it was typed. This is
+useful for batch scripts, e.g., recurring initialisation code for fuses. The
+include option -e prints the lines of the file as comments before
+processing them; on a non-zero verbosity level the line numbers are
+printed, too.
+
signatureDisplay the device signature bytes. +
+part [opts]Display the current part information, including supported programming modes, +memory and variants tables. Use -m to only print the memory table, +and -v to only print the variants table. +
+verbose ]level]Change (when level is provided), or display the verbosity
+level.
+The initial verbosity level is controlled by the number of -v options
+given on the command line.
+
quell [level]Change (when level is provided), or display the quell
+level. 1 is used to suppress progress reports. 2 or higher yields
+progressively quieter operations. The initial quell level is controlled
+by the number of -q options given on the command line.
+
?helpGive a short on-line summary of the available commands. +
+quitLeave terminal mode and thus AVRDUDE. +
+qCan be used as an alias for quit.
+
!lineRun the shell line in a subshell, e.g., !ls *.hex. Subshell
+commands take the rest of the line as their command. For security reasons,
+they must be enabled explictly by putting allow_subshells = yes;
+into your ${HOME}/.config/avrdude/avrdude.rc or
+${HOME}/.avrduderc file.
+
# commentPlace comments onto the terminal line (useful for scripts). +
+In addition, the following commands are supported on some programmers: +
+pgerase memory addrErase one page of the memory specified. +
+send b1 b2 b3 b4Send raw instruction codes to the AVR device. If you need access to a +feature of an AVR part that is not directly supported by AVRDUDE, this +command allows you to use it, even though AVRDUDE does not implement the +command. When using direct SPI mode, up to 3 bytes +can be omitted. +
+spiEnter direct SPI mode. The pgmled pin acts as chip select. +Only supported on parallel bitbang programmers, and partially by USBtiny. +Chip Select must be externally held low for direct SPI when +using USBtinyISP, and send must be a multiple of four bytes. +
+pgmReturn to programming mode (from direct SPI mode). +
+vtarg voltageSet the target’s supply voltage to voltage Volts. +
+varef [channel] voltageSet the adjustable voltage source to voltage Volts. +This voltage is normally used to drive the target’s +Aref input on the STK500 and STK600. +The STK600 offers two reference voltages, which can be +selected by the optional parameter channel (either +0 or 1). +
+fosc freq[M|k]Set the programming oscillator to freq Hz.
+An optional trailing letter M
+multiplies by 1E6, a trailing letter k by 1E3.
+
fosc offTurn the programming oscillator off. +
+sck periodSet the SCK clock period to period microseconds.
+Note that some official Microchip programmers store the bitclock setting and
+will continue to use it until a diferent value is provided. See
+-B bitclock for more information.
+
parmsDisplay programmer specific parameters. +
+| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [Top] | +[Contents] | +[Index] | +[ ? ] | +
+ This document was generated on June 23, 2025 using texi2html 1.82. +
++ The buttons in the navigation panels have the following meaning: +
+| Button | +Name | +Go to | +From 1.2.3 go to | +
|---|---|---|---|
| [ < ] | +Back | +Previous section in reading order | +1.2.2 | +
| [ > ] | +Forward | +Next section in reading order | +1.2.4 | +
| [ << ] | +FastBack | +Beginning of this chapter or previous chapter | +1 | +
| [ Up ] | +Up | +Up section | +1.2 | +
| [ >> ] | +FastForward | +Next chapter | +2 | +
| [Top] | +Top | +Cover (top) of document | ++ |
| [Contents] | +Contents | +Table of contents | ++ |
| [Index] | +Index | +Index | ++ |
| [ ? ] | +About | +About (help) | ++ |
+ where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure: +
+ +| [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+
| [Top] | +[Contents] | +[Index] | +[ ? ] | +
| [Top] | +[Contents] | +[Index] | +[ ? ] | +
+
+ This document was generated on June 23, 2025 using texi2html 1.82.
+
+
+
+