is a program for downloading code and data to Atmel AVR
microcontrollers.
.NmAvrdude
supports Atmel's STK500 programmer,
Atmel's AVRISP and AVRISP mkII devices,
Atmel's STK600,
Atmel's JTAG ICE (mkI, mkII and 3, the latter two also in ISP mode),
programmers complying to AppNote AVR910 and AVR109 (including the Butterfly),
as well as a simple hard-wired
programmer connected directly to a
.Xrppi4
or
.Xrparport4
parallel port, or to a standard serial port.
In the simplest case, the hardware consists just of a
cable connecting the respective AVR signal lines to the parallel port.
.Pp
The MCU is programmed in
.Emserialprogrammingmode,
so, for the
.Xrppi4
based programmer, the MCU signals
.Ql/RESET,
.QlSCK,
.QlMISO
and
.QlMOSI
need to be connected to the parallel port. Optionally, some otherwise
unused output pins of the parallel port can be used to supply power
for the MCU part, so it is also possible to construct a passive
stand-alone programming device. Some status LEDs indicating the
current operating state of the programmer can be connected, and a
signal is available to control a buffer/driver IC 74LS367 (or
74HCT367). The latter can be useful to decouple the parallel port
from the MCU when in-system programming is used.
.Pp
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.
.Pp
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 MOSI, MISO, RESET
and SCK pins on the AVR and use the linuxgpio programmer type. It bitbangs
the lines using the Linux sysfs GPIO interface. Of course, care should
be taken about voltage level compatibility. Also, although not strictrly
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 http://kolev.info/avrdude-linuxgpio for a more
detailed tutorial about using this programmer type.
.Pp
Atmel's STK500 programmer is also supported and connects to a serial
port.
Both, firmware versions 1.x and 2.x can be handled, but require a
different programmer type specification (by now).
Using firmware version 2, high-voltage programming is also supported,
both parallel and serial
(programmer types stk500pp and stk500hvsp).
.Pp
Wiring boards are supported, utilizing STK500 V2.x protocol, but
a simple DTR/RTS toggle is used to set the boards into programming mode.
The programmer type is ``wiring''.
.Pp
The Arduino (which is very similar to the STK500 1.x) is supported via
its own programmer type specification ``arduino''.
.Pp
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
.Emextendedparameters
below for details.
.Pp
Atmel's STK600 programmer is supported in ISP and high-voltage
programming modes, and connects through the USB.
For ATxmega devices, the STK600 is supported in PDI mode.
For ATtiny4/5/9/10 devices, the STK600 and AVRISP mkII are supported in TPI mode.
.Pp
The simple serial programmer described in Atmel's application note
AVR910, and the bootloader described in Atmel's application note
AVR109 (which is also used by the AVR Butterfly evaluation board), are
supported on a serial port.
.Pp
Atmel's JTAG ICE (mkI, mkII, and 3) is supported as well to up- or download memory
areas from/to an AVR target (no support for on-chip debugging).
For the JTAG ICE mkII, JTAG, debugWire and ISP mode are supported, provided
it has a firmware revision of at least 4.14 (decimal).
JTAGICE3 also supports all of JTAG, debugWIRE, and ISP mode.
See below for the limitations of debugWire.
For ATxmega devices, the JTAG ICE mkII is supported in PDI mode, provided it
has a revision 1 hardware and firmware version of at least 5.37 (decimal).
For ATxmega devices, the JTAGICE3 is supported in PDI mode.
.Pp
Atmel-ICE (ARM/AVR) is supported in all modes (JTAG, PDI for Xmega, debugWIRE,
ISP).
.Pp
Atmel's XplainedPro boards, using the EDBG protocol (CMSIS-DAP compatible),
are supported using the "jtag3" programmer type.
.Pp
Atmel's XplainedMini boards, using the mEDBG protocol,
are also supported using the "jtag3" programmer type.
.Pp
The AVR Dragon is supported in all modes (ISP, JTAG, 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 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
.FlBArbitclock
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).
.Pp
The avrftdi, USBasp ISP and USBtinyISP adapters are also supported, provided
.Nmavrdude
has been compiled with libusb support.
USBasp ISP and USBtinyISP both feature simple firmware-only USB implementations,
running on an ATmega8 (or ATmega88), or ATtiny2313, respectively. If libftdi has
has been compiled in
.Nmavrdude,
the avrftdi device adds support for many programmers using FTDI's 2232C/D/H
and 4232H parts running in MPSSE mode, which hard-codes (in the chip)
SCK to bit 1, MOSI to bit 2, and MISO to bit 3. Reset is usually bit 4.
.Pp
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.
.Pp
Input files can be provided, and output files can be written in
different file formats, such as raw binary files containing the data
to download to the chip, Intel hex format, or Motorola S-record
format. There are a number of tools available to produce those files,
like
.Xrasl1
as a standalone assembler, or
.Xravr-objcopy1
for the final stage of the GNU toolchain for the AVR microcontroller.
.Pp
Provided
.Xrlibelf3
was present when compiling
.Nmavrdude,
the input file can also be the final ELF file as produced by the linker.
The appropriate ELF section(s) will be examined, according to the memory
area to write to.
.Pp
.NmAvrdude
can program the EEPROM and flash ROM memory cells of supported AVR
parts. Where supported by the serial instruction set, fuse bits and
lock bits can be programmed as well. These are implemented within
.Nm
as separate memory types and can be programmed using data from a file
(see the
.Flm
option) or from terminal mode (see the
.Ardump
and
.Arwrite
commands). It is also possible to read the chip (provided it has not
been code-protected previously, of course) and store the data in a
file. Finally, a ``terminal'' mode is available that allows one to
interactively communicate with the MCU, and to display or program
individual memory cells.
On the STK500 and STK600 programmer, several operational parameters (target supply
voltage, target Aref voltage, master clock) can be examined and changed
from within terminal mode as well.
.SsOptions
In order to control all the different operation modi, a number of options
need to be specified to
.Nmavrdude.
.Bl-tag-offsetindent-widthindent
.ItFlpArpartno
This is the only option that is mandatory for every invocation of
.Nmavrdude.
It specifies the type of the MCU connected to the programmer. These are read from the config file.
For currently supported MCU types use ? as partno, this will print a list of partno ids and official part names on the terminal. (Both can be used with the -p option.)
.Pp
Following parts need special attention:
.Bl-tag-width"ATmega1234"
.It"AT90S1200"
The ISP programming protocol of the AT90S1200 differs in subtle ways
from that of other AVRs. Thus, not all programmers support this
device. Known to work are all direct bitbang programmers, and all
programmers talking the STK500v2 protocol.
.It"AT90S2343"
The AT90S2323 and ATtiny22 use the same algorithm.
.It"ATmega2560, ATmega2561"
Flash addressing above 128 KB is not supported by all
programming hardware. Known to work are jtag2, stk500v2,
and bit-bang programmers.
.It"ATtiny11"
The ATtiny11 can only be
programmed in high-voltage serial mode.
.El
.ItFlbArbaudrate
Override the RS-232 connection baud rate specified in the respective
programmer's entry of the configuration file.
.ItFlBArbitclock
Specify the bit clock period for the JTAG interface or the ISP clock (JTAG ICE only).
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.
The default value of the JTAG ICE results in about 1 microsecond bit
clock period, suitable for target MCUs running at 4 MHz clock and
above.
Unlike certain parameters in the STK500, the JTAG ICE resets all its
parameters to default values when the programming software signs
off from the ICE, so for MCUs running at lower clock speeds, this
parameter must be specified on the command-line.
You can use the 'default_bitclock' keyword in your
.Pa${HOME}/.avrduderc
file to assign a default value to keep from having to specify this
option on every invocation.
.ItFlcArprogrammer-id
Use the programmer specified by the argument. Programmers and their pin
configurations are read from the config file (see the
.FlC
option). New pin configurations can be easily added or modified
through the use of a config file to make
.Nmavrdude
work with different programmers as long as the programmer supports the
Atmel AVR serial program method. You can use the 'default_programmer'
keyword in your
.Pa${HOME}/.avrduderc
file to assign a default programmer to keep from having to specify
this option on every invocation.
A full list of all supported programmers is output to the terminal
by using ? as programmer-id.
.ItFlCArconfig-file
Use the specified config file to load configuration data. This file
contains all programmer and part definitions that
.Nmavrdude
knows about.
See the config file, located at
.Pa${PREFIX}/etc/avrdude.conf,
which contains a description of the format.
.Pp
If
.Arconfig-file
is written as
.Pa+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.
.ItFlD
Disable auto erase for flash. When the
.FlU
option with flash memory is specified,
.Nm
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 devices as these devices can
use page erase before writing each page so no explicit chip erase
is required.
Note however that any page not affected by the current operation
will retain its previous contents.
.ItFle
Causes a chip erase to be executed. This will reset the contents of the
flash ROM and EEPROM to the value
.Ql0xff,
and clear all lock bits.
Except for ATxmega devices 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
.Ql1
to
.Ql0.
Note that in order to reprogram EERPOM cells, no explicit prior chip
erase is required since the MCU provides an auto-erase cycle in that
case before programming the cell.
.ItXoFlEArexitspecNs
.Op\&,NsArexitspec
.Xc
By default,
.Nm
leaves the parallel port in the same state at exit as it has been
found at startup. This option modifies the state of the
.Ql/RESET
and
.QlVcc
lines the parallel port is left at, according to the
.Arexitspec
arguments provided, as follows:
.Bl-tag-widthnoreset
.ItArreset
The
.Ql/RESET
signal will be left activated at program exit, that is it will be held
.Emlow,
in order to keep the MCU in reset state afterwards. Note in particular
that the programming algorithm for the AT90S1200 device mandates that
the
.Ql/RESET
signal is active
.Embefore
powering up the MCU, so in case an external power supply is used for this
MCU type, a previous invocation of
.Nm
with this option specified is one of the possible ways to guarantee this
condition.
.ItArnoreset
The
.Ql/RESET
line will be deactivated at program exit, thus allowing the MCU target
program to run while the programming hardware remains connected.
.ItArvcc
This option will leave those parallel port pins active
.Pq\&i.\&e.Emhigh
that can be used to supply
.QlVcc
power to the MCU.
.ItArnovcc
This option will pull the
.QlVcc
pins of the parallel port down at program exit.
.ItArd_high
This option will leave the 8 data pins on the parallel port active.
.Pq\&i.\&e.Emhigh
.ItArd_low
This option will leave the 8 data pins on the parallel port inactive.
.Pq\&i.\&e.Emlow
.El
.Pp
Multiple
.Arexitspec
arguments can be separated with commas.
.ItFlF
Normally,
.Nm
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
.Flt
to continue in terminal mode.
.ItFliArdelay
For bitbang-type programmers, delay for approximately
.Ardelay
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
.Nm
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.
.ItFllArlogfile
Use
.Arlogfile
rather than
.Vastderr
for diagnostics output.
Note that initial diagnostic messages (during option parsing) are still
written to
.Vastderr
anyway.
.ItFln
No-write - disables actually writing data to the MCU (useful for debugging
.Nmavrdude
).
.ItFlO
Perform 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.
.ItFlPArport
Use
.Arport
to identify the device to which the programmer is attached. By
default the
.Pa/dev/ppi0
port is used, but if the programmer type normally connects to the
serial port, the
.Pa/dev/cuaa0
port is the default. If you need to use a different parallel or
serial port, use this option to specify the alternate port name.
.Pp
On Win32 operating systems, the parallel ports are referred to as lpt1
through lpt3, referring to the addresses 0x378, 0x278, and 0x3BC,
respectively. If the parallel port can be accessed through a different
address, this address can be specified directly, using the common C
language notation (i. e., hexadecimal values are prefixed by
.Ql0x
).
.Pp
For the JTAG ICE mkII and JTAGICE3, if
.Nm
has been configured with libusb support,
.Arport
can alternatively be specified as
.PausbNsOp\&:NsArserialno.
This will cause
.Nm
to search the programmer on USB.
If
.Arserialno
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.
.Pp
As the AVRISP mkII device can only be talked to over USB, the very
same method of specifying the port is required there.
.Pp
For the USB programmer "AVR-Doper" running in HID mode, the port must
be specified as
.Aravrdoper.
Libusb support is required on Unix but not on Windows. For more
information about AVR-Doper see http://www.obdev.at/avrusb/avrdoper.html.
.Pp
For the USBtinyISP, which is a simplicistic device not implementing
serial numbers, multiple devices can be distinguished by their
location in the USB hierarchy. See the the respective
.EmTroubleshooting
entry in the detailed documentation for examples.
.Pp
For programmers that attach to a serial port using some kind of
higher level protocol (as opposed to bit-bang style programmers),
.Arport
can be specified as
.PanetNs\&:NsArhostNs\&:NsArport.
In this case, instead of trying to open a local device, a TCP