Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
AVRDUDE(1)		FreeBSD	General	Commands Manual		    AVRDUDE(1)

     avrdude --	driver program for ``simple'' Atmel AVR	MCU programmer

     avrdude -p	partno [-b baudrate] [-B bitclock] [-c programmer-id]
	     [-C config-file] [-D] [-e]	[-E exitspec[,exitspec]] [-F]
	     [-i delay]	[-n -logfile] [-n] [-O]	[-P port] [-q] [-s] [-t] [-u]
	     [-U memtype:op:filename:filefmt] [-v] [-x extended_param] [-V]

     Avrdude is	a program for downloading code and data	to Atmel AVR microcon-
     trollers.	Avrdude	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 pro-
     grammer connected directly	to a ppi(4) or parport(4) 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

     The MCU is	programmed in serial programming mode, so, for the ppi(4)
     based programmer, the MCU signals `/RESET', `SCK',	`MISO' and `MOSI' 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 program-
     ming 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 de-
     couple the	parallel port from the MCU when	in-system programming is used.

     A number of equally simple	bit-bang programming adapters that connect to
     a serial port are supported as well, among	them the popular Ponyprog se-
     rial 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 phys-
     ical 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 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 re-
     quired, it	is strongly advisable to protect the GPIO pins from overcur-
     rent situations in	some way. The simplest would be	to just	put some re-
     sistors in	series or better yet use a 3-state buffer driver like the
     74HC244. Have a look at for a more
     detailed tutorial about using this	programmer type.

     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).

     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 pro-
     grammer type is ``wiring''.

     The Arduino (which	is very	similar	to the STK500 1.x) is supported	via
     its own programmer	type specification ``arduino''.

     The BusPirate is a	versatile tool that can	also be	used as	an AVR pro-
     grammer.  A single	BusPirate can be connected to up to 3 independent
     AVRs. See the section on extended parameters below	for details.

     Atmel's STK600 programmer is supported in ISP and high-voltage program-
     ming 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.

     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.

     Atmel's JTAG ICE (mkI, mkII, and 3) is supported as well to up- or	down-
     load memory areas from/to an AVR target (no support for on-chip debug-
     ging).  For the JTAG ICE mkII, JTAG, debugWire and	ISP mode are sup-
     ported, 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.

     Atmel-ICE (ARM/AVR) is supported in all modes (JTAG, PDI for Xmega, de-
     bugWIRE, ISP).

     Atmel's XplainedPro boards, using the EDBG	protocol (CMSIS-DAP compati-
     ble), are supported using the "jtag3" programmer type.

     Atmel's XplainedMini boards, using	the mEDBG protocol, are	also supported
     using the "jtag3" programmer type.

     The AVR Dragon is supported in all	modes (ISP, JTAG, HVSP,	PP, debug-
     Wire).  When used in JTAG and debugWire mode, the AVR Dragon behaves sim-
     ilar 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	simi-
     lar to an AVRISP mkII (or JTAG ICE	mkII in	ISP mode), so all device-spe-
     cific 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 ver-
     sion of at	least 6.11 (decimal).

     The avrftdi, USBasp ISP and USBtinyISP adapters are also supported, pro-
     vided avrdude has been compiled with libusb support.  USBasp ISP and US-
     BtinyISP both feature simple firmware-only	USB implementations, running
     on	an ATmega8 (or ATmega88), or ATtiny2313, respectively. If libftdi has
     has been compiled in avrdude, 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.

     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.

     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 asl(1) as a	stand-
     alone assembler, or avr-objcopy(1)	for the	final stage of the GNU
     toolchain for the AVR microcontroller.

     Provided libelf(3)	was present when compiling avrdude, 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

     Avrdude 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
     avrdude as	separate memory	types and can be programmed using data from a
     file (see the -m option) or from terminal mode (see the dump and write
     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 interac-
     tively 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.

     In	order to control all the different operation modi, a number of options
     need to be	specified to avrdude.

	   -p partno
		   This	is the only option that	is mandatory for every invoca-
		   tion	of avrdude.  It	specifies the type of the MCU con-
		   nected 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	op-

		   Following parts need	special	attention:

		   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 program-
			       mers, and all programmers talking the STK500v2

		   AT90S2343   The AT90S2323 and ATtiny22 use the same algo-

		   ATmega2560, ATmega2561
			       Flash addressing	above 128 KB is	not supported
			       by all programming hardware.  Known to work are
			       jtag2, stk500v2,	and bit-bang programmers.

		   ATtiny11    The ATtiny11 can	only be	programmed in high-
			       voltage serial mode.

	   -b baudrate
		   Override the	RS-232 connection baud rate specified in the
		   respective programmer's entry of the	configuration file.

	   -B bitclock
		   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 'de-
		   fault_bitclock' keyword in your ${HOME}/.avrduderc file to
		   assign a default value to keep from having to specify this
		   option on every invocation.

	   -c programmer-id
		   Use the programmer specified	by the argument.  Programmers
		   and their pin configurations	are read from the config file
		   (see	the -C option).	 New pin configurations	can be easily
		   added or modified through the use of	a config file to make
		   avrdude work	with different programmers as long as the pro-
		   grammer supports the	Atmel AVR serial program method.  You
		   can use the 'default_programmer' keyword in your
		   ${HOME}/.avrduderc file to assign a default programmer to
		   keep	from having to specify this option on every invoca-
		   tion.  A full list of all supported programmers is output
		   to the terminal by using ? as programmer-id.

	   -C config-file
		   Use the specified config file to load configuration data.
		   This	file contains all programmer and part definitions that
		   avrdude knows about.	 See the config	file, located at
		   ${PREFIX}/etc/avrdude.conf, which contains a	description of
		   the format.

		   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	with-
		   out 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.

	   -D	   Disable auto	erase for flash.  When the -U option with
		   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	with-
		   out 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 af-
		   fected by the current operation will	retain its previous

	   -e	   Causes 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	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 `1' to `0'.
		   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.

	   -E exitspec[,exitspec]
		   By default, avrdude leaves the parallel port	in the same
		   state at exit as it has been	found at startup.  This	option
		   modifies the	state of the `/RESET' and `Vcc'	lines the par-
		   allel port is left at, according to the exitspec arguments
		   provided, as	follows:

		   reset    The	`/RESET' signal	will be	left activated at pro-
			    gram 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.

		   noreset  The	`/RESET' line will be deactivated at program
			    exit, thus allowing	the MCU	target program to run
			    while the programming hardware remains connected.

		   vcc	    This option	will leave those parallel port pins
			    active (i. e. high)	that can be used to supply
			    `Vcc' power	to the MCU.

		   novcc    This option	will pull the `Vcc' pins of the	paral-
			    lel	port down at program exit.

		   d_high   This option	will leave the 8 data pins on the par-
			    allel port active.	(i. e. high)

		   d_low    This option	will leave the 8 data pins on the par-
			    allel port inactive.  (i. e. low)

		   Multiple exitspec arguments can be separated	with commas.

	   -F	   Normally, 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 con-
		   troller), this option can be	used together with -t to con-
		   tinue in terminal mode.

	   -i delay
		   For 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 oscilla-
		   tor), 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 cali-
		   brated against a system timer, so the number	of microsec-
		   onds	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 ma-

	   -l logfile
		   Use logfile rather than stderr for diagnostics output.
		   Note	that initial diagnostic	messages (during option	pars-
		   ing)	are still written to stderr anyway.

	   -n	   No-write - disables actually	writing	data to	the MCU	(use-
		   ful for debugging avrdude ).

	   -O	   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.

	   -P port
		   Use port to identify	the device to which the	programmer is
		   attached.  By default the /dev/ppi0 port is used, but if
		   the programmer type normally	connects to the	serial port,
		   the /dev/cuaa0 port is the default.	If you need to use a
		   different parallel or serial	port, use this option to spec-
		   ify the alternate port name.

		   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 `0x' ).

		   For the JTAG	ICE mkII and JTAGICE3, if avrdude has been
		   configured with libusb support, port	can alternatively be
		   specified as	usb[:serialno].	 This will cause avrdude to
		   search the programmer on USB.  If serialno is also speci-
		   fied, it will be matched against the	serial number read
		   from	any JTAG ICE mkII found	on USB.	 The match is done af-
		   ter 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.

		   As the AVRISP mkII device can only be talked	to over	USB,
		   the very same method	of specifying the port is required

		   For the USB programmer "AVR-Doper" running in HID mode, the
		   port	must be	specified as avrdoper. Libusb support is re-
		   quired on Unix but not on Windows. For more information
		   about AVR-Doper see

		   For the USBtinyISP, which is	a simplicistic device not im-
		   plementing serial numbers, multiple devices can be distin-
		   guished by their location in	the USB	hierarchy.  See	the
		   the respective Troubleshooting entry	in the detailed	docu-
		   mentation for examples.

		   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.
		   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 us-
		   ing a transparent 8-bit data	connection without parity at
		   115200 Baud for a STK500.

	   -q	   Disable (or quell) output of	the progress bar while reading
		   or writing to the device.  Specify it a second time for
		   even	quieter	operation.

	   -s	   Disable safemode prompting.	When safemode discovers	that
		   one or more fuse bits have unintentionally changed, it will
		   prompt for confirmation regarding whether or	not it should
		   attempt to recover the fuse bit(s).	Specifying this	flag
		   disables the	prompt and assumes that	the fuse bit(s)	should
		   be recovered	without	asking for confirmation	first.

	   -t	   Tells avrdude to enter the interactive ``terminal'' mode
		   instead of up- or downloading files.	 See below for a de-
		   tailed description of the terminal mode.

	   -u	   Disable the safemode	fuse bit checks.  Safemode is enabled
		   by default and is intended to prevent unintentional fuse
		   bit changes.	 When enabled, safemode	will issue a warning
		   if the any fuse bits	are found to be	different at program
		   exit	than they were when avrdude was	invoked.  Safemode
		   won't alter fuse bits itself, but rather will prompt	for
		   instructions, unless	the terminal is	non-interactive, in
		   which case safemode is disabled.  See the -s	option to dis-
		   able	safemode prompting.

		   If one of the configuration files has a line
			 default_safemode = no;
		   safemode is disabled	by default.  The -u option's effect is
		   negated in that case, i. e. it enables safemode.

		   Safemode is always disabled for AVR32, Xmega	and TPI	de-

	   -U memtype:op:filename[:format]
		   Perform a memory operation as indicated.  The memtype field
		   specifies the memory	type to	operate	on.  The available
		   memory types	are device-dependent, the actual configuration
		   can be viewed with the part command in terminal mode.  Typ-
		   ically, a device's memory configuration at least contains
		   the memory types flash and eeprom.  All memory types	cur-
		   rently known	are:
		   calibration	One or more bytes of RC	oscillator calibration
		   eeprom	The EEPROM of the device.
		   efuse	The extended fuse byte.
		   flash	The flash ROM of the device.
		   fuse		The fuse byte in devices that have only	a sin-
				gle fuse byte.
		   hfuse	The high fuse byte.
		   lfuse	The low	fuse byte.
		   lock		The lock byte.
		   signature	The three device signature bytes (device ID).
		   fuseN	The fuse bytes of ATxmega devices, N is	an in-
				teger number for each fuse supported by	the
		   application	The application	flash area of ATxmega devices.
		   apptable	The application	table flash area of ATxmega
		   boot		The boot flash area of ATxmega devices.
		   prodsig	The production signature (calibration) area of
				ATxmega	devices.
		   usersig	The user signature area	of ATxmega devices.

		   The op field	specifies what operation to perform:

		   r	    read device	memory and write to the	specified file

		   w	    read data from the specified file and write	to the
			    device memory

		   v	    read 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.	 Format	can be one of:

		   i	Intel Hex

		   s	Motorola S-record

		   r	raw binary; little-endian byte order, in the case of
			the flash ROM data

		   e	ELF (Executable	and Linkable Format)

		   m	immediate; actual byte values specified	on the command
			line, separated	by commas or spaces.  This is good for
			programming fuse bytes without having to create	a sin-
			gle-byte file or enter terminal	mode.

		   a	auto detect; valid for input only, and only if the in-
			put is not provided at stdin.

		   d	decimal; this and the following	formats	are only valid
			on output.  They 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.

		   h	hexadecimal; each value	will get the string 0x

		   o	octal; each value will get a 0 prepended unless	it is
			less than 8 in which case it gets no prefix.

		   b	binary;	each value will	get the	string 0b prepended.

		   The default is to use auto detection	for input files, and
		   raw binary format for output	files.	Note that if filename
		   contains a colon, the format	field is no longer optional
		   since the filename part following the colon 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 out-
		   put file that has no	contents at all.

		   As an abbreviation, the form	-U filename is equivalent to
		   specifying -U flash:w:filename:a.  This will	only work if
		   filename does not have a colon in it.

	   -v	   Enable verbose output.  More	-v options increase verbosity

	   -V	   Disable automatic verify check when uploading data.

	   -x extended_param
		   Pass	extended_param to the chosen programmer	implementation
		   as an extended parameter.  The interpretation of the	ex-
		   tended parameter depends on the programmer itself.  See be-
		   low for a list of programmers accepting extended parame-

   Terminal mode
     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 following	commands are currently imple-

	   dump	memtype	addr nbytes
		   Read	nbytes bytes from the specified	memory area, and dis-
		   play	them in	the usual hexadecimal and ASCII	form.

	   dump	   Continue dumping the	memory contents	for another nbytes
		   where the previous dump command left	off.

	   write memtype addr byte1 ...	byteN
		   Manually program the	respective memory cells, starting at
		   address addr, using the values byte1	through	byteN.	This
		   feature is not implemented for bank-addressed memories such
		   as the flash	memory of ATMega devices.

	   erase   Perform a chip erase.

	   send	b1 b2 b3 b4
		   Send	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.

	   sig	   Display the device signature	bytes.

	   spi	   Enter direct	SPI mode.  The pgmled pin acts as slave	se-
		   lect.  Only supported on parallel bitbang programmers.

	   part	   Display the current part settings and parameters.  Includes
		   chip	specific information including all memory types	sup-
		   ported by the device, read/write timing, etc.

	   pgm	   Return to programming mode (from direct SPI mode).

	   vtarg voltage
		   Set the target's supply voltage to voltage Volts.  Only
		   supported on	the STK500 and STK600 programmer.

	   varef [channel] voltage
		   Set the adjustable voltage source to	voltage	Volts.	This
		   voltage is normally used to drive the target's Aref input
		   on the STK500.  On the Atmel	STK600,	two reference voltages
		   are available, which	can be selected	by the optional
		   channel argument (either 0 or 1).  Only supported on	the
		   STK500 and STK600 programmer.

	   fosc	freq[M|k]
		   Set the master oscillator to	freq Hz.  An optional trailing
		   letter M multiplies by 1E6, a trailing letter k by 1E3.
		   Only	supported on the STK500	and STK600 programmer.

	   fosc	off
		   Turn	the master oscillator off.  Only supported on the
		   STK500 and STK600 programmer.

	   sck period
		   STK500 and STK600 programmer	only: Set the SCK clock	period
		   to period microseconds.

		   JTAG	ICE only: Set the JTAG ICE bit clock period to period
		   microseconds.  Note that unlike STK500 settings, this set-
		   ting	will be	reverted to its	default	value (approximately 1
		   microsecond)	when the programming software signs off	from
		   the JTAG ICE.  This parameter can also be used on the JTAG
		   ICE mkII, JTAGICE3, and Atmel-ICE to	specify	the ISP	clock
		   period when operating the ICE in ISP	mode.

	   parms   STK500 and STK600 programmer	only: Display the current
		   voltage and master oscillator parameters.

		   JTAG	ICE only: Display the current target supply voltage
		   and JTAG bit	clock rate/period.

	   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 commandline.


	   help	   Give	a short	on-line	summary	of the available commands.

	   quit	   Leave terminal mode and thus	avrdude.

   Default Parallel port pin connections
     (these can	be changed, see	the -c option)
     Pin number	  Function
     2-5	  Vcc (optional	power supply to	MCU)
     7		  /RESET (to MCU)
     8		  SCK (to MCU)
     9		  MOSI (to MCU)
     10		  MISO (from MCU)
     18-25	  GND

   debugWire limitations
     The debugWire protocol is Atmel's proprietary one-wire (plus ground) pro-
     tocol 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 in-
     tended for	debugging/emulation, it	also offers limited programming	capa-
     bilities.	Effectively, the only memory areas that	can be read or pro-
     grammed in	this mode are flash ROM	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 ROM, each flash ROM 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 debug-
     Wire 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.

   FLIP	version	1 idiosyncrasies
     Bootloaders using the FLIP	protocol version 1 experience some very	spe-
     cific 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 op-
     tion when reprogramming the flash,	this peculiarity might not be very ob-
     vious 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 signa-
     ture, avrdude can only continue in	that situation by forcing the signa-
     ture check	to be overridden with the -F option.

     A chip erase might	leave the EEPROM unerased, at least on some versions
     of	the bootloader.

   Programmers accepting extended parameters



	   AVR Dragon
		   When	using the JTAG ICE mkII, JTAGICE3, Atmel-ICE or	AVR
		   Dragon in JTAG mode,	the following extended parameter is

				 Setup the JTAG	scan chain for UB units	be-
				 fore, 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 dif-
				 ferent	bit shift count.


				 Override 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 veri-
				 fied but used directly	within the `T' command
				 sent to the programmer.  VALUE	can be speci-
				 fied using the	conventional number notation
				 of the	C programming language.

				 Disables the default checking for block
				 transfer capability.  Use no_blockmode	only
				 if your AVR910	programmer creates errors dur-
				 ing initial sequence.


				 The 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 MISO, MOSI
				 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 avail-
				 able 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 BusPi-
				 rate 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 inter-
				 fere with programming the AVR in the other

				 The SPI speed for the Bus Pirate's binary SPI

				 0 ..  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

				 Sets the SPI speed and	uses the Bus Pirate's
				 binary	"raw-wire" 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
				 the different SPI frequencies available.
				 Paged writing is not implemented in this

			 ascii	 Attempt 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.

				 Firmware 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 desir-
				 able for some reason, this option disables

				 Newer firmware	versions support in binary
				 mode SPI command some AVR Extended Commands.
				 Using the "Bulk Memory	Read from Flash" re-
				 sults in a significant	read speed increase.
				 If use	of this	mode is	not desirable for some
				 reason, this option disables it.

				 This 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.

				 This sets the serial receive timeout to the
				 given value.  The timeout happens every time
				 avrdude waits for the BusPirate prompt.  Es-
				 pecially in ascii mode	this happens very of-
				 ten, so setting a smaller value can speed up
				 programming a lot.  The default value is
				 100ms.	Using 10ms might work in most cases.

	   Wiring  When	using the Wiring programmer type, the following	op-
		   tional extended parameter is	accepted:

				 After performing the port open	phase, AVRDUDE
				 will wait/snooze for snooze milliseconds be-
				 fore continuing to the	protocol sync phase.
				 No toggling of	DTR/RTS	is performed if	snooze
				 is greater than 0.

		   Connection to the PICkit2 programmer:

		   (AVR)    (PICkit2)
		   RST	-   VPP/MCLR (1)
		   VDD	-   VDD	Target (2) -- possibly optional	if AVR self powered
		   GND	-   GND	(3)
		   MISO	-   PGD	(4)
		   SCLK	-   PDC	(5)
		   MOSI	-   AUX	(6)

		   Extended commandline	parameters:

				 Sets the SPI clocking rate in Hz (default is
				 100kHz). Alternately the -B or	-i options can
				 be used to set	the period.

				 Sets the timeout for USB reads	and writes in
				 milliseconds (default is 1500 ms).

	   /dev/ppi0	 default device	to be used for communication with the
			 programming hardware

			 programmer and	parts configuration file

			 programmer and	parts configuration file (per-user

	   ~/.inputrc	 Initialization	file for the readline(3) library

			 Schematic of programming hardware

     avrdude: jtagmkII_setparm(): bad response to set parameter	command: RSP_FAILED
     avrdude: jtagmkII_getsync(): ISP activation failed, trying	debugWire
     avrdude: Target prepared for ISP, signed off.
     avrdude: Please restart avrdude without power-cycling the target.

     If	the target AVR has been	set up for debugWire mode (i. e. the DWEN fuse
     is	programmed), normal ISP	connection attempts will fail as the /RESET
     pin is not	available.  When using the JTAG	ICE mkII in ISP	mode, the mes-
     sage shown	indicates that avrdude has guessed this	condition, and tried
     to	initiate a debugWire reset to the target.  When	successful, this will
     leave the target AVR in a state where it can respond to normal ISP	commu-
     nication again (until the next power cycle).  Typically, the same command
     is	going to be retried again immediately afterwards, and will then	suc-
     ceed connecting to	the target using normal	ISP communication.

     avr-objcopy(1), ppi(4), libelf(3,)	readline(3)

     The AVR microcontroller product description can be	found at

     Avrdude was written by Brian S. Dean <>.

     This man page by Joerg Wunsch.

     Please report bugs	via

     The JTAG ICE programmers currently	cannot write to	the flash ROM one byte
     at	a time.	 For that reason, updating the flash ROM from terminal mode
     does not work.

     Page-mode programming the EEPROM through JTAG (i.e. through an -U option)
     requires a	prior chip erase.  This	is an inherent feature of the way JTAG
     EEPROM programming	works.	This also applies to the STK500	and STK600 in
     parallel programming mode.

     The USBasp	and USBtinyISP drivers do not offer any	option to distinguish
     multiple devices connected	simultaneously,	so effectively only a single
     device is supported.

     The avrftdi driver	allows one to select specific devices using any	combi-
     nation of vid,pid serial number (usbsn) vendor description	(usbvendoror
     part description (usbproduct) as seen with	lsusb or whatever tool used to
     view USB device information. Multiple devices can be on the bus at	the
     same time.	For the	H parts, which have multiple MPSSE interfaces, the in-
     terface can also be selected.  It defaults	to interface 'A'.

FreeBSD	13.0		       January 24, 2021			  FreeBSD 13.0


Want to link to this manual page? Use this URL:

home | help