2686 lines
95 KiB
Plaintext
2686 lines
95 KiB
Plaintext
|
%% -*-texinfo-*-
|
|||
|
|
\input texinfo
|
|||
|
|
|
|||
|
|
@c $Id$
|
|||
|
|
|
|||
|
|
@setfilename avrdude.info
|
|||
|
|
@settitle AVRDUDE
|
|||
|
@finalout
|
|||
|
|
|
|||
|
@include version.texi
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c These are set in version.texi which is automatically generated by automake.
|
|||
|
|
@c
|
|||
|
|
@c @set UPDATED 26 Febuary 2003
|
|||
|
|
@c @set EDITION 3.2.0
|
|||
|
|
@c @set VERSION 3.2.0
|
|||
|
|
|
|||
|
|
@c This is a dir.info fragment to support semi-automated addition of
|
|||
|
|
@c manuals to an info tree.
|
|||
|
|
@dircategory AVR Programming & development tools.
|
|||
|
|
@direntry
|
|||
|
|
* AvrDude: (avrdude). AVR program downloader/uploader.
|
|||
|
|
@end direntry
|
|||
|
|
|
|||
|
|
@ifinfo
|
|||
|
|
This file documents the avrdude program.
|
|||
|
|
|
|||
|
|
For avrdude version @value{VERSION}, @value{UPDATED}.
|
|||
|
|
|
|||
|
Copyright @copyright{} 2003, 2005 Brian Dean
|
|||
|
|
|
|||
|
|
Copyright @copyright{} 2006 - 2021 J@"org Wunsch
|
|||
|
|
|
|||
|
|
Permission is granted to make and distribute verbatim copies of
|
|||
|
|
this manual provided the copyright notice and this permission notice
|
|||
|
|
are preserved on all copies.
|
|||
|
|
|
|||
|
|
@ignore
|
|||
|
|
Permission is granted to process this file through TeX and print the
|
|||
|
|
results, provided the printed document carries copying permission
|
|||
|
|
notice identical to this one except for the removal of this paragraph
|
|||
|
|
(this paragraph not being relevant to the printed manual).
|
|||
|
|
|
|||
|
|
@end ignore
|
|||
|
|
Permission is granted to copy and distribute modified versions of this
|
|||
|
|
manual under the conditions for verbatim copying, provided that the entire
|
|||
|
|
resulting derived work is distributed under the terms of a permission
|
|||
|
|
notice identical to this one.
|
|||
|
|
|
|||
|
|
Permission is granted to copy and distribute translations of this manual
|
|||
|
|
into another language, under the above conditions for modified versions,
|
|||
|
|
except that this permission notice may be stated in a translation approved
|
|||
|
|
by the Free Software Foundation.
|
|||
|
|
|
|||
|
|
Alternatively, this documentation may be copied and distributed under
|
|||
|
|
the terms of the GNU Free Documentation License (FDL), version 1.3.
|
|||
|
|
@end ifinfo
|
|||
|
|
|
|||
|
|
@titlepage
|
|||
|
|
@title AVRDUDE
|
|||
|
|
@subtitle A program for download/uploading AVR microcontroller flash and eeprom.
|
|||
|
|
@subtitle For AVRDUDE, Version @value{VERSION}, @value{UPDATED}.
|
|||
|
|
@author by Brian S. Dean
|
|||
|
|
|
|||
|
|
@page
|
|||
|
|
Send comments on AVRDUDE to @w{@email{avrdude-dev@@nongnu.org}}.
|
|||
|
|
|
|||
|
|
Use @uref{http://savannah.nongnu.org/bugs/?group=avrdude} to report bugs.
|
|||
|
|
|
|||
|
|
Copyright @copyright{} 2003,2005 Brian S. Dean
|
|||
|
|
|
|||
|
|
Copyright @copyright{} 2006 - 2013 J@"org Wunsch
|
|||
|
|
@sp 2
|
|||
|
|
|
|||
|
|
Permission is granted to make and distribute verbatim copies of
|
|||
|
|
this manual provided the copyright notice and this permission notice
|
|||
|
|
are preserved on all copies.
|
|||
|
|
|
|||
|
|
Permission is granted to copy and distribute modified versions of this
|
|||
|
|
manual under the conditions for verbatim copying, provided that the entire
|
|||
|
|
resulting derived work is distributed under the terms of a permission
|
|||
|
|
notice identical to this one.
|
|||
|
|
|
|||
|
|
Permission is granted to copy and distribute translations of this manual
|
|||
|
|
into another language, under the above conditions for modified versions,
|
|||
|
|
except that this permission notice may be stated in a translation approved
|
|||
|
|
by the Free Software Foundation.
|
|||
|
|
@end titlepage
|
|||
|
|
|
|||
|
|
@contents
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Top Node
|
|||
|
|
@c
|
|||
|
|
@node Top, Introduction, (dir), (dir)
|
|||
|
|
@comment node-name, next, previous, up
|
|||
|
|
|
|||
|
|
@ifinfo
|
|||
|
|
This file documents the avrdude program for downloading/uploading
|
|||
|
|
programs to Atmel AVR microcontrollers.
|
|||
|
|
|
|||
|
|
For avrdude version @value{VERSION}, @value{UPDATED}.
|
|||
|
|
|
|||
|
|
Send comments on AVRDUDE to @w{@email{avrdude-dev@@nongnu.org}}.
|
|||
|
|
|
|||
|
|
Use @uref{http://savannah.nongnu.org/bugs/?group=avrdude} to report bugs.
|
|||
|
|
|
|||
|
|
Copyright @copyright{} 2003,2005 Brian S. Dean
|
|||
|
|
|
|||
|
|
Copyright @copyright{} 2006 J@"org Wunsch
|
|||
|
|
@end ifinfo
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* Introduction::
|
|||
|
|
* Command Line Options::
|
|||
|
|
* Terminal Mode Operation::
|
|||
|
|
* Configuration File::
|
|||
|
|
* Programmer Specific Information::
|
|||
|
|
* Platform Dependent Information::
|
|||
|
|
* Troubleshooting::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Introduction, Command Line Options, Top, Top
|
|||
|
|
@comment node-name, next, previous, up
|
|||
|
|
@chapter Introduction
|
|||
|
|
@cindex introduction
|
|||
|
|
|
|||
|
|
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 and EEPROM, and where supported by the serial
|
|||
|
|
programming protocol, it can program fuse and lock bits. AVRDUDE also
|
|||
|
|
supplies a direct instruction mode allowing one to issue any programming
|
|||
|
|
instruction to the AVR chip regardless of whether AVRDUDE implements
|
|||
|
|
that specific feature of a particular chip.
|
|||
|
|
|
|||
|
|
AVRDUDE can be used effectively via the command line to read or write
|
|||
|
|
all chip memory types (eeprom, flash, fuse bits, lock bits, signature
|
|||
|
|
bytes) or 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.
|
|||
|
|
|
|||
|
|
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, the latter two also in ISP mode), 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 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 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 http://kolev.info/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 slave 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 5V and the SPI runs at 3.3V. The
|
|||
|
|
GPIO chosen for reset can be configured in the avrdude configuration
|
|||
|
|
file using the @code{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 MOSI, MISO, 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:
|
|||
|
|
|
|||
|
|
@multitable @columnfractions .15 .15 .3
|
|||
|
|
@item @code{J8 pin} @tab @code{ISP pin} @tab @code{Name}
|
|||
|
|
@item @code{21} @tab @code{1} @tab @code{MISO}
|
|||
|
|
@item @code{-} @tab @code{2} @tab @code{Vcc - leave open}
|
|||
|
|
@item @code{23} @tab @code{3} @tab @code{SCK}
|
|||
|
|
@item @code{19} @tab @code{4} @tab @code{MOSI}
|
|||
|
|
@item @code{22} @tab @code{5} @tab @code{/RESET}
|
|||
|
|
@item @code{25} @tab @code{6} @tab @code{GND}
|
|||
|
|
@end multitable
|
|||
|
|
|
|||
|
|
(Mind the 3.3 V voltage level of the Raspberry Pi!)
|
|||
|
|
|
|||
|
|
The @code{-P @var{portname}} option defaults to
|
|||
|
|
@code{/dev/spidev0.0:/dev/gpiochip0} for this programmer.
|
|||
|
|
|
|||
|
|
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 @code{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 1 (the lsb of the byte in the config
|
|||
|
|
file) is SCK. Bit 2 is MOSI, and Bit 3 is MISO. Bit 4 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 ROM, 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, 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 for Xmega, debugWIRE, ISP modes).
|
|||
|
|
|
|||
|
|
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 @code{-B @var{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.
|
|||
|
|
|
|||
|
|
The Arduino (which is very similar to the STK500 1.x) is supported via
|
|||
|
|
its own programmer type specification ``arduino''. This programmer works for
|
|||
|
|
the Arduino Uno Rev3.
|
|||
|
|
|
|||
|
|
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
|
|||
|
|
@emph{extended parameters}
|
|||
|
|
below for details.
|
|||
|
|
|
|||
|
|
The USBasp ISP and USBtinyISP adapters are also supported, provided AVRDUDE
|
|||
|
|
has been compiled with libusb support.
|
|||
|
|
They both feature simple firmware-only USB implementations, running on
|
|||
|
|
an ATmega8 (or ATmega88), or ATtiny2313, respectively.
|
|||
|
|
|
|||
|
|
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, MPLAB(R) SNAP, and Curiosity Nano boards are
|
|||
|
|
supported in UPDI mode. The Curiosity Nano board is dubbed ``PICkit on
|
|||
|
|
Board'', thus the name @code{pkobn_updi}.
|
|||
|
|
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* History::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node History, , Introduction, Introduction
|
|||
|
|
@section History and Credits
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
The AVRDUDE source now resides in the public CVS repository on
|
|||
|
|
savannah.gnu.org (@url{http://savannah.gnu.org/projects/avrdude/}),
|
|||
|
|
where it continues to be enhanced and ported to other systems. In
|
|||
|
|
addition to FreeBSD, AVRDUDE now runs on Linux and Windows. The
|
|||
|
|
developers behind the porting effort primarily were Ted Roth, Eric
|
|||
|
|
Weddington, and Joerg Wunsch.
|
|||
|
|
|
|||
|
|
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 Joerg 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.
|
|||
|
|
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Command Line Options, Terminal Mode Operation, Introduction, Top
|
|||
|
|
@chapter Command Line Options
|
|||
|
|
@cindex options
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* Option Descriptions::
|
|||
|
|
* Programmers accepting extended parameters::
|
|||
|
|
* Example Command Line Invocations::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Option Descriptions, Programmers accepting extended parameters, Command Line Options, Command Line Options
|
|||
|
|
@section Option Descriptions
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
AVRDUDE is a command line tool, used as follows:
|
|||
|
|
|
|||
|
|
@smallexample
|
|||
|
|
avrdude -p partno @var{options} @dots{}
|
|||
|
|
@end smallexample
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
Command line options are used to control AVRDUDE's behaviour. The
|
|||
|
|
following options are recognized:
|
|||
|
|
|
|||
|
|
@table @code
|
|||
|
|
@item -p @var{partno}
|
|||
|
|
This is the only mandatory option and it tells AVRDUDE what type of part
|
|||
|
|
(MCU) that is connected to the programmer. The @var{partno} parameter
|
|||
|
|
is the part's id listed in the configuration file. Specify -p ? to list
|
|||
|
|
all parts in the configuration file. 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.
|
|||
|
|
Currently, the following MCU types are understood:
|
|||
|
|
|
|||
|
|
@multitable @columnfractions .15 .3
|
|||
|
|
@include parts.texi
|
|||
|
|
@end multitable
|
|||
|
|
|
|||
|
|
(*) The AT90S2323 and ATtiny22 use the same algorithm.
|
|||
|
|
|
|||
|
|
(**) Flash addressing above 128 KB is not supported by all
|
|||
|
|
programming hardware. Known to work are jtag2, stk500v2,
|
|||
|
|
and bit-bang programmers.
|
|||
|
|
|
|||
|
|
(***)
|
|||
|
|
The ATtiny11 can only be
|
|||
|
|
programmed in high-voltage serial mode.
|
|||
|
|
|
|||
|
|
(****)
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
@item -b @var{baudrate}
|
|||
|
|
Override the RS-232 connection baud rate specified in the respective
|
|||
|
|
programmer's entry of the configuration file.
|
|||
|
|
|
|||
|
|
@item -B @var{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.
|
|||
|
|
It can also be set in the configuration file by using the 'default_bitclock'
|
|||
|
|
keyword.
|
|||
|
|
|
|||
|
|
@item -c @var{programmer-id}
|
|||
|
|
Specify the programmer to be used. AVRDUDE knows about several common
|
|||
|
|
programmers. Use this option to specify which one to use. The
|
|||
|
|
@var{programmer-id} parameter is the programmer's id listed in the
|
|||
|
|
configuration file. Specify -c ? to list all programmers in the
|
|||
|
|
configuration file. If you have a programmer that is unknown to
|
|||
|
|
AVRDUDE, and the programmer is controlled via the PC parallel port,
|
|||
|
|
there's a good chance that it can be easily added to the configuration
|
|||
|
|
file without any code changes to AVRDUDE. Simply copy an existing entry
|
|||
|
|
and change the pin definitions to match that of the unknown programmer.
|
|||
|
|
Currently, the following programmer ids are understood and supported:
|
|||
|
|
|
|||
|
|
@multitable @columnfractions .2 .6
|
|||
|
|
@include programmers.texi
|
|||
|
|
@end multitable
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
@item -C @var{config-file}
|
|||
|
|
Use the specified config file for configuration data. This file
|
|||
|
|
contains all programmer and part definitions that AVRDUDE knows about.
|
|||
|
|
If not
|
|||
|
|
specified, AVRDUDE reads the configuration file from
|
|||
|
|
/usr/local/etc/avrdude.conf (FreeBSD and Linux). See Appendix A for
|
|||
|
|
the method of searching for the configuration file for Windows.
|
|||
|
|
|
|||
|
|
If @var{config-file} is written as @var{+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.
|
|||
|
|
|
|||
|
|
|
|||
|
|
@item -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
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
@item -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.
|
|||
|
|
|
|||
|
|
|
|||
|
|
@item -E @var{exitspec}[,@dots{}]
|
|||
|
|
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 parallel port is left at, according to
|
|||
|
|
the exitspec arguments provided, as follows:
|
|||
|
|
|
|||
|
|
@table @code
|
|||
|
|
@item reset
|
|||
|
|
The `/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.
|
|||
|
|
|
|||
|
|
@item noreset
|
|||
|
|
The `/RESET' line will be deactivated at program exit, thus allowing the
|
|||
|
|
MCU target program to run while the programming hardware remains
|
|||
|
|
connected.
|
|||
|
|
|
|||
|
|
@item vcc
|
|||
|
|
This option will leave those parallel port pins active (i. e. high) that
|
|||
|
|
can be used to supply `Vcc' power to the MCU.
|
|||
|
|
|
|||
|
|
@item novcc
|
|||
|
|
This option will pull the `Vcc' pins of the parallel port down at
|
|||
|
|
program exit.
|
|||
|
|
|
|||
|
|
@item d_high
|
|||
|
|
This option will leave the 8 data pins on the parallel port active
|
|||
|
|
(i. e. high).
|
|||
|
|
|
|||
|
|
@item d_low
|
|||
|
|
This option will leave the 8 data pins on the parallel port inactive
|
|||
|
|
(i. e. low).
|
|||
|
|
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
Multiple @var{exitspec} arguments can be separated with commas.
|
|||
|
|
|
|||
|
|
|
|||
|
|
@item -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 controller), this option can be used
|
|||
|
|
together with @option{-t} to continue in terminal mode.
|
|||
|
|
|
|||
|
|
@item -i @var{delay}
|
|||
|
|
For bitbang-type programmers, delay for approximately
|
|||
|
|
@var{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.
|
|||
|
|
|
|||
|
|
@item -l @var{logfile}
|
|||
|
|
Use @var{logfile} rather than @var{stderr} for diagnostics output.
|
|||
|
|
Note that initial diagnostic messages (during option parsing) are still
|
|||
|
|
written to @var{stderr} anyway.
|
|||
|
|
|
|||
|
|
@item -n
|
|||
|
|
No-write - disables actually writing data to the MCU (useful for
|
|||
|
|
debugging AVRDUDE).
|
|||
|
|
|
|||
|
|
@item -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.
|
|||
|
|
|
|||
|
|
@item -P @var{port}
|
|||
|
|
Use port to identify the device to which the programmer is attached.
|
|||
|
|
Normally, the default parallel port is used, but if the programmer type
|
|||
|
|
normally connects to the serial port, the default serial port will be
|
|||
|
|
used. See Appendix A, Platform Dependent Information, to find out the
|
|||
|
|
default port names for your platform. If you need to use a different
|
|||
|
|
parallel or serial port, use this option to specify 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 @var{0x}).
|
|||
|
|
|
|||
|
|
For the JTAG ICE mkII, if AVRDUDE has been built with libusb support,
|
|||
|
|
@var{port} may alternatively be specified as
|
|||
|
|
@code{usb}[:@var{serialno}]. In that case, the JTAG ICE mkII will be
|
|||
|
|
looked up on USB. If @var{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 @ref{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 @var{avrdoper}. Libhidapi support is required on Unix
|
|||
|
|
and Mac OS but not on Windows. For more information about AVR-Doper see
|
|||
|
|
@url{http://www.obdev.at/avrusb/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.
|
|||
|
|
See the respective
|
|||
|
|
@xref{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
|
|||
|
|
@code{@@} 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:
|
|||
|
|
@code{0013a20000000001@/dev/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),
|
|||
|
|
@var{port} can be specified as @code{net}:@var{host}:@var{port}.
|
|||
|
|
In this case, instead of trying to open a local device, a TCP
|
|||
|
|
network connection to (TCP) @var{port} on @var{host}
|
|||
|
|
is established.
|
|||
|
|
Square brackets may be placed around @var{host} to improve
|
|||
|
|
readability for numeric IPv6 addresses (e.g.
|
|||
|
|
@code{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).
|
|||
|
|
|
|||
|
|
@item -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.
|
|||
|
|
|
|||
|
|
@item -u
|
|||
|
|
Disables the default behaviour of reading out the fuses three times before
|
|||
|
|
programming, then verifying at the end of programming that the fuses have not
|
|||
|
|
changed. If you want to change fuses you will need to specify this option,
|
|||
|
|
as avrdude will see the fuses have changed (even though you wanted to) and
|
|||
|
|
will change them back for your "safety". This option was designed to
|
|||
|
|
prevent cases of fuse bits magically changing (usually called @emph{safemode}).
|
|||
|
|
|
|||
|
|
If one of the configuration files contains a line
|
|||
|
|
|
|||
|
|
@code{default_safemode = no;}
|
|||
|
|
|
|||
|
|
safemode is disabled by default.
|
|||
|
|
The @option{-u} option's effect is negated in that case, i. e. it
|
|||
|
|
@emph{enables} safemode.
|
|||
|
|
|
|||
|
|
Safemode is always disabled for AVR32, Xmega and TPI devices.
|
|||
|
|
|
|||
|
|
@item -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.
|
|||
|
|
|
|||
|
|
@item -t
|
|||
|
|
Tells AVRDUDE to enter the interactive ``terminal'' mode instead of up-
|
|||
|
|
or downloading files. See below for a detailed description of the
|
|||
|
|
terminal mode.
|
|||
|
|
|
|||
|
|
@item -U @var{memtype}:@var{op}:@var{filename}[:@var{format}]
|
|||
|
|
Perform a memory operation.
|
|||
|
|
Multiple @option{-U} options can be specified in order to operate on
|
|||
|
|
multiple memories on the same command-line invocation. The
|
|||
|
|
@var{memtype} field specifies the memory type to operate on. Use
|
|||
|
|
the @option{-v} option on the command line or the @code{part} command from
|
|||
|
|
terminal mode to display all the memory types supported by a particular
|
|||
|
|
device.
|
|||
|
|
Typically, a device's memory configuration at least contains
|
|||
|
|
the memory types
|
|||
|
|
@code{flash}
|
|||
|
|
and
|
|||
|
|
@code{eeprom}.
|
|||
|
|
All memory types currently known are:
|
|||
|
|
@table @code
|
|||
|
|
@item calibration
|
|||
|
|
One or more bytes of RC oscillator calibration data.
|
|||
|
|
@item eeprom
|
|||
|
|
The EEPROM of the device.
|
|||
|
|
@item efuse
|
|||
|
|
The extended fuse byte.
|
|||
|
|
@item flash
|
|||
|
|
The flash ROM of the device.
|
|||
|
|
@item fuse
|
|||
|
|
The fuse byte in devices that have only a single fuse byte.
|
|||
|
|
@item hfuse
|
|||
|
|
The high fuse byte.
|
|||
|
|
@item lfuse
|
|||
|
|
The low fuse byte.
|
|||
|
|
@item lock
|
|||
|
|
The lock byte.
|
|||
|
|
@item signature
|
|||
|
|
The three device signature bytes (device ID).
|
|||
|
|
@item fuse@emph{N}
|
|||
|
|
The fuse bytes of ATxmega devices, @emph{N} is an integer number
|
|||
|
|
for each fuse supported by the device.
|
|||
|
|
@item application
|
|||
|
|
The application flash area of ATxmega devices.
|
|||
|
|
@item apptable
|
|||
|
|
The application table flash area of ATxmega devices.
|
|||
|
|
@item boot
|
|||
|
|
The boot flash area of ATxmega devices.
|
|||
|
|
@item prodsig
|
|||
|
|
The production signature (calibration) area of ATxmega devices.
|
|||
|
|
@item usersig
|
|||
|
|
The user signature area of ATxmega devices.
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
The @var{op} field specifies what operation to perform:
|
|||
|
|
|
|||
|
|
@table @code
|
|||
|
|
@item r
|
|||
|
|
read the specified device memory and write to the specified file
|
|||
|
|
|
|||
|
|
@item w
|
|||
|
|
read the specified file and write it to the specified device memory
|
|||
|
|
|
|||
|
|
@item v
|
|||
|
|
read the specified device memory and the specified file and perform a verify operation
|
|||
|
|
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
The @var{filename} field indicates the name of the file to read or
|
|||
|
|
write. The @var{format} field is optional and contains the format of
|
|||
|
|
the file to read or write. Possible values are:
|
|||
|
|
|
|||
|
|
@table @code
|
|||
|
|
@item i
|
|||
|
|
Intel Hex
|
|||
|
|
|
|||
|
|
@item s
|
|||
|
|
Motorola S-record
|
|||
|
|
|
|||
|
|
@item r
|
|||
|
|
raw binary; little-endian byte order, in the case of the flash ROM data
|
|||
|
|
|
|||
|
|
@item e
|
|||
|
|
ELF (Executable and Linkable Format), the final output file from the
|
|||
|
|
linker; currently only accepted as an input file
|
|||
|
|
|
|||
|
|
@item m
|
|||
|
|
immediate mode; actual byte values specified on the command line,
|
|||
|
|
separated by commas or spaces in place of the @var{filename} field of
|
|||
|
|
the @option{-U} option. This is useful
|
|||
|
|
for programming fuse bytes without having to create a single-byte file
|
|||
|
|
or enter terminal mode. If the number specified begins with @code{0x},
|
|||
|
|
it is treated as a hex value. If the number otherwise begins with a
|
|||
|
|
leading zero (@code{0}) it is treated as octal. Otherwise, the value is
|
|||
|
|
treated as decimal.
|
|||
|
|
|
|||
|
|
@item a
|
|||
|
|
auto detect; valid for input only, and only if the input is not provided
|
|||
|
|
at stdin.
|
|||
|
|
|
|||
|
|
@item 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.
|
|||
|
|
|
|||
|
|
@item h
|
|||
|
|
hexadecimal; each value will get the string @emph{0x} prepended.
|
|||
|
|
|
|||
|
|
@item o
|
|||
|
|
octal; each value will get a @emph{0}
|
|||
|
|
prepended unless it is less than 8 in which case it gets no prefix.
|
|||
|
|
|
|||
|
|
@item b
|
|||
|
|
binary; each value will get the string @emph{0b} prepended.
|
|||
|
|
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
The default is to use auto detection for input files, and raw binary
|
|||
|
|
format for output files.
|
|||
|
|
|
|||
|
|
Note that if @var{filename} contains a colon, the @var{format} field is
|
|||
|
|
no longer optional since the filename part following the colon would
|
|||
|
|
otherwise be misinterpreted as @var{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.
|
|||
|
|
|
|||
|
|
As an abbreviation, the form @code{-U} @var{filename}
|
|||
|
|
is equivalent to specifying
|
|||
|
|
@code{-U} @emph{flash:w:}@var{filename}@emph{:a}.
|
|||
|
|
This will only work if @var{filename} does not have a colon in it.
|
|||
|
|
|
|||
|
|
@item -v
|
|||
|
|
Enable verbose output.
|
|||
|
|
More @code{-v} options increase verbosity level.
|
|||
|
|
|
|||
|
|
@item -V
|
|||
|
|
Disable automatic verify check when uploading data.
|
|||
|
|
|
|||
|
|
@item -x @var{extended_param}
|
|||
|
|
Pass @var{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.
|
|||
|
|
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
@page
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Programmers accepting extended parameters, Example Command Line Invocations, Option Descriptions, Command Line Options
|
|||
|
|
@section Programmers accepting extended parameters
|
|||
|
|
|
|||
|
|
@table @code
|
|||
|
|
|
|||
|
|
@item JTAG ICE mkII/3
|
|||
|
|
@itemx AVR Dragon
|
|||
|
|
|
|||
|
|
When using the JTAG ICE mkII/3 or AVR Dragon in JTAG mode, the
|
|||
|
|
following extended parameter is accepted:
|
|||
|
|
@table @code
|
|||
|
|
@item @samp{jtagchain=UB,UA,BB,BA}
|
|||
|
|
Setup the JTAG scan chain for @var{UB} units before, @var{UA} units
|
|||
|
|
after, @var{BB} bits before, and @var{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.
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
@item AVR910
|
|||
|
|
|
|||
|
|
The AVR910 programmer type accepts the following extended parameter:
|
|||
|
|
@table @code
|
|||
|
|
@item @samp{devcode=VALUE}
|
|||
|
|
Override the device code selection by using @var{VALUE}
|
|||
|
|
as the device code.
|
|||
|
|
The programmer is not queried for the list of supported
|
|||
|
|
device codes, and the specified @var{VALUE}
|
|||
|
|
is not verified but used directly within the
|
|||
|
|
@code{T} command sent to the programmer.
|
|||
|
|
@var{VALUE} can be specified using the conventional number notation of the
|
|||
|
|
C programming language.
|
|||
|
|
@item @samp{no_blockmode}
|
|||
|
|
Disables the default checking for block transfer capability.
|
|||
|
|
Use
|
|||
|
|
@samp{no_blockmode} only if your @samp{AVR910}
|
|||
|
|
programmer creates errors during initial sequence.
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
@item BusPirate
|
|||
|
|
|
|||
|
|
The BusPirate programmer type accepts the following extended parameters:
|
|||
|
|
@table @code
|
|||
|
|
@item @samp{reset=cs,aux,aux2}
|
|||
|
|
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
|
|||
|
|
@emph{CS}
|
|||
|
|
pin, second AVR's RESET connected to BusPirate's
|
|||
|
|
@emph{AUX}
|
|||
|
|
pin and if your BusPirate has an
|
|||
|
|
@emph{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.
|
|||
|
|
|
|||
|
|
@item @samp{spifreq=@var{0..7}}
|
|||
|
|
@multitable @columnfractions .05 .3
|
|||
|
|
@item @code{0} @tab 30 kHz (default)
|
|||
|
|
@item @code{1} @tab 125 kHz
|
|||
|
|
@item @code{2} @tab 250 kHz
|
|||
|
|
@item @code{3} @tab 1 MHz
|
|||
|
|
@item @code{4} @tab 2 MHz
|
|||
|
|
@item @code{5} @tab 2.6 MHz
|
|||
|
|
@item @code{6} @tab 4 MHz
|
|||
|
|
@item @code{7} @tab 8 MHz
|
|||
|
|
@end multitable
|
|||
|
|
|
|||
|
|
@item @samp{rawfreq=0..3}
|
|||
|
|
Sets the SPI speed and uses the Bus Pirate's binary ``raw-wire'' mode instead
|
|||
|
|
of the default binary SPI mode:
|
|||
|
|
|
|||
|
|
@multitable @columnfractions .05 .3
|
|||
|
|
@item @code{0} @tab 5 kHz
|
|||
|
|
@item @code{1} @tab 50 kHz
|
|||
|
|
@item @code{2} @tab 100 kHz (Firmware v4.2+ only)
|
|||
|
|
@item @code{3} @tab 400 kHz (v4.2+)
|
|||
|
|
@end multitable
|
|||
|
|
|
|||
|
|
The only advantage of the ``raw-wire'' mode is that different SPI frequencies
|
|||
|
|
are available. Paged writing is not implemented in this mode.
|
|||
|
|
|
|||
|
|
@item @samp{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
|
|||
|
|
@samp{reset=}, @samp{spifreq=}
|
|||
|
|
and
|
|||
|
|
@samp{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.
|
|||
|
|
|
|||
|
|
@item @samp{nopagedwrite}
|
|||
|
|
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 desirable for some
|
|||
|
|
reason, this option disables it.
|
|||
|
|
|
|||
|
|
@item @samp{nopagedread}
|
|||
|
|
Newer 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.
|
|||
|
|
|
|||
|
|
@item @samp{cpufreq=@var{125..4000}}
|
|||
|
|
This sets the @emph{AUX} pin to output a frequency of @var{n} kHz. Connecting
|
|||
|
|
the @emph{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.
|
|||
|
|
|
|||
|
|
@item @samp{serial_recv_timeout=@var{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 100ms. Using 10ms might work in most cases.
|
|||
|
|
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
@item Wiring
|
|||
|
|
|
|||
|
|
When using the Wiring programmer type, the
|
|||
|
|
following optional extended parameter is accepted:
|
|||
|
|
@table @code
|
|||
|
|
@item @samp{snooze=@var{0..32767}}
|
|||
|
|
After performing the port open phase, AVRDUDE will wait/snooze for
|
|||
|
|
@var{snooze} milliseconds before continuing to the protocol sync phase.
|
|||
|
|
No toggling of DTR/RTS is performed if @var{snooze} > 0.
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
@item PICkit2
|
|||
|
|
Connection to the PICkit2 programmer:
|
|||
|
|
@multitable @columnfractions .05 .3
|
|||
|
|
@item @code{(AVR)} @tab @code{(PICkit2)}
|
|||
|
|
@item @code{RST} @tab @code{VPP/MCLR (1) }
|
|||
|
|
@item @code{VDD} @tab @code{VDD Target (2) -- possibly optional if AVR self powered }
|
|||
|
|
@item @code{GND} @tab @code{GND (3) }
|
|||
|
|
@item @code{MISO} @tab @code{PGD (4) }
|
|||
|
|
@item @code{SCLK} @tab @code{PDC (5) }
|
|||
|
|
@item @code{OSI} @tab @code{AUX (6) }
|
|||
|
|
@end multitable
|
|||
|
|
|
|||
|
|
Extended command line parameters:
|
|||
|
|
@table @code
|
|||
|
|
@item @samp{clockrate=@var{rate}}
|
|||
|
|
Sets the SPI clocking rate in Hz (default is 100kHz). Alternately the -B or -i options can be used to set the period.
|
|||
|
|
@item @samp{timeout=@var{usb-transaction-timeout}}
|
|||
|
|
Sets the timeout for USB reads and writes in milliseconds (default is 1500 ms).
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
@item USBasp
|
|||
|
|
Extended parameters:
|
|||
|
|
@table @code
|
|||
|
|
@item @samp{section_config}
|
|||
|
|
Programmer 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).
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
@item xbee
|
|||
|
|
Extended parameters:
|
|||
|
|
@table @code
|
|||
|
|
@item @samp{xbeeresetpin=@var{1..7}}
|
|||
|
|
Select the XBee pin @code{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 @code{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 @code{DOUT} pin (pin 2) must be connected to the MCU's
|
|||
|
|
‘RXD’ line, and the XBee @code{DIN} pin (pin 3) must be connected to
|
|||
|
|
the MCU's ‘TXD’ line.
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
@page
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Example Command Line Invocations, , Programmers accepting extended parameters, Command Line Options
|
|||
|
|
@section Example Command Line Invocations
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
Download the file @code{diag.hex} to the ATmega128 chip using the
|
|||
|
|
STK500 programmer connected to the default serial port:
|
|||
|
|
|
|||
|
|
@smallexample
|
|||
|
|
@cartouche
|
|||
|
|
% avrdude -p m128 -c stk500 -e -U flash:w:diag.hex
|
|||
|
|
|
|||
|
|
avrdude: AVR device initialized and ready to accept instructions
|
|||
|
|
|
|||
|
|
Reading | ################################################## | 100% 0.03s
|
|||
|
|
|
|||
|
|
avrdude: Device signature = 0x1e9702
|
|||
|
|
avrdude: erasing chip
|
|||
|
|
avrdude: done.
|
|||
|
|
avrdude: performing op: 1, flash, 0, diag.hex
|
|||
|
|
avrdude: reading input file "diag.hex"
|
|||
|
|
avrdude: input file diag.hex auto detected as Intel Hex
|
|||
|
|
avrdude: writing flash (19278 bytes):
|
|||
|
|
|
|||
|
|
Writing | ################################################## | 100% 7.60s
|
|||
|
|
|
|||
|
|
avrdude: 19456 bytes of flash written
|
|||
|
|
avrdude: verifying flash memory against diag.hex:
|
|||
|
|
avrdude: load data flash data from input file diag.hex:
|
|||
|
|
avrdude: input file diag.hex auto detected as Intel Hex
|
|||
|
|
avrdude: input file diag.hex contains 19278 bytes
|
|||
|
|
avrdude: reading on-chip flash data:
|
|||
|
|
|
|||
|
|
Reading | ################################################## | 100% 6.83s
|
|||
|
|
|
|||
|
|
avrdude: verifying ...
|
|||
|
|
avrdude: 19278 bytes of flash verified
|
|||
|
|
|
|||
|
|
avrdude: safemode: Fuses OK
|
|||
|
|
|
|||
|
|
avrdude done. Thank you.
|
|||
|
|
|
|||
|
|
%
|
|||
|
|
@end cartouche
|
|||
|
|
@end smallexample
|
|||
|
|
|
|||
|
|
@page
|
|||
|
|
@noindent
|
|||
|
|
Upload the flash memory from the ATmega128 connected to the STK500
|
|||
|
|
programmer and save it in raw binary format in the file named
|
|||
|
|
@code{c:/diag flash.bin}:
|
|||
|
|
|
|||
|
|
@smallexample
|
|||
|
|
@cartouche
|
|||
|
|
% avrdude -p m128 -c stk500 -U flash:r:"c:/diag flash.bin":r
|
|||
|
|
|
|||
|
|
avrdude: AVR device initialized and ready to accept instructions
|
|||
|
|
|
|||
|
|
Reading | ################################################## | 100% 0.03s
|
|||
|
|
|
|||
|
|
avrdude: Device signature = 0x1e9702
|
|||
|
|
avrdude: reading flash memory:
|
|||
|
|
|
|||
|
|
Reading | ################################################## | 100% 46.10s
|
|||
|
|
|
|||
|
|
avrdude: writing output file "c:/diag flash.bin"
|
|||
|
|
|
|||
|
|
avrdude: safemode: Fuses OK
|
|||
|
|
|
|||
|
|
avrdude done. Thank you.
|
|||
|
|
|
|||
|
|
%
|
|||
|
|
@end cartouche
|
|||
|
|
@end smallexample
|
|||
|
|
|
|||
|
|
@page
|
|||
|
|
@noindent
|
|||
|
|
Using the default programmer, download the file @code{diag.hex} to
|
|||
|
|
flash, @code{eeprom.hex} to EEPROM, and set the Extended, High, and Low
|
|||
|
|
fuse bytes to 0xff, 0x89, and 0x2e respectively:
|
|||
|
|
|
|||
|
|
@smallexample
|
|||
|
|
@cartouche
|
|||
|
|
|
|||
|
|
% avrdude -p m128 -u -U flash:w:diag.hex \
|
|||
|
|
> -U eeprom:w:eeprom.hex \
|
|||
|
|
> -U efuse:w:0xff:m \
|
|||
|
|
> -U hfuse:w:0x89:m \
|
|||
|
|
> -U lfuse:w:0x2e:m
|
|||
|
|
|
|||
|
|
avrdude: AVR device initialized and ready to accept instructions
|
|||
|
|
|
|||
|
|
Reading | ################################################## | 100% 0.03s
|
|||
|
|
|
|||
|
|
avrdude: Device signature = 0x1e9702
|
|||
|
|
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
|
|||
|
|
To disable this feature, specify the -D option.
|
|||
|
|
avrdude: erasing chip
|
|||
|
|
avrdude: reading input file "diag.hex"
|
|||
|
|
avrdude: input file diag.hex auto detected as Intel Hex
|
|||
|
|
avrdude: writing flash (19278 bytes):
|
|||
|
|
|
|||
|
|
Writing | ################################################## | 100% 7.60s
|
|||
|
|
|
|||
|
|
avrdude: 19456 bytes of flash written
|
|||
|
|
avrdude: verifying flash memory against diag.hex:
|
|||
|
|
avrdude: load data flash data from input file diag.hex:
|
|||
|
|
avrdude: input file diag.hex auto detected as Intel Hex
|
|||
|
|
avrdude: input file diag.hex contains 19278 bytes
|
|||
|
|
avrdude: reading on-chip flash data:
|
|||
|
|
|
|||
|
|
Reading | ################################################## | 100% 6.84s
|
|||
|
|
|
|||
|
|
avrdude: verifying ...
|
|||
|
|
avrdude: 19278 bytes of flash verified
|
|||
|
|
|
|||
|
|
[ ... other memory status output skipped for brevity ... ]
|
|||
|
|
|
|||
|
|
avrdude done. Thank you.
|
|||
|
|
|
|||
|
|
%
|
|||
|
|
@end cartouche
|
|||
|
|
@end smallexample
|
|||
|
|
|
|||
|
|
@page
|
|||
|
|
@noindent
|
|||
|
|
Connect to the JTAG ICE mkII which serial number ends up in 1C37 via
|
|||
|
|
USB, and enter terminal mode:
|
|||
|
|
|
|||
|
|
@smallexample
|
|||
|
|
@cartouche
|
|||
|
|
|
|||
|
|
% avrdude -c jtag2 -p m649 -P usb:1c:37 -t
|
|||
|
|
|
|||
|
|
avrdude: AVR device initialized and ready to accept instructions
|
|||
|
|
|
|||
|
|
Reading | ################################################## | 100% 0.03s
|
|||
|
|
|
|||
|
|
avrdude: Device signature = 0x1e9603
|
|||
|
|
|
|||
|
|
[ ... terminal mode output skipped for brevity ... ]
|
|||
|
|
|
|||
|
|
avrdude done. Thank you.
|
|||
|
|
|
|||
|
|
@end cartouche
|
|||
|
|
@end smallexample
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
@smallexample
|
|||
|
|
@cartouche
|
|||
|
|
|
|||
|
|
% avrdude -c jtag2 -p m128 -P usb:xx -v
|
|||
|
|
[...]
|
|||
|
|
Using Port : usb:xxx
|
|||
|
|
Using Programmer : jtag2
|
|||
|
|
avrdude: usbdev_open(): Found JTAG ICE, serno: 00A000001C6B
|
|||
|
|
avrdude: usbdev_open(): Found JTAG ICE, serno: 00A000001C3A
|
|||
|
|
avrdude: usbdev_open(): Found JTAG ICE, serno: 00A000001C30
|
|||
|
|
avrdude: usbdev_open(): did not find any (matching) USB device "usb:xxx"
|
|||
|
|
|
|||
|
|
@end cartouche
|
|||
|
|
@end smallexample
|
|||
|
|
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Terminal Mode Operation, Configuration File, Command Line Options, Top
|
|||
|
|
@chapter Terminal Mode Operation
|
|||
|
|
|
|||
|
|
AVRDUDE has an interactive mode called @var{terminal mode} that is
|
|||
|
|
enabled by the @option{-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.
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* Terminal Mode Commands::
|
|||
|
|
* Terminal Mode Examples::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@node Terminal Mode Commands, Terminal Mode Examples, Terminal Mode Operation, Terminal Mode Operation
|
|||
|
|
@section Terminal Mode Commands
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
The following commands are implemented:
|
|||
|
|
|
|||
|
|
@table @code
|
|||
|
|
|
|||
|
|
@item dump @var{memtype} @var{addr} @var{nbytes}
|
|||
|
|
Read @var{nbytes} from the specified memory area, and display them in
|
|||
|
|
the usual hexadecimal and ASCII form.
|
|||
|
|
|
|||
|
|
@item dump
|
|||
|
|
Continue dumping the memory contents for another @var{nbytes} where the
|
|||
|
|
previous dump command left off.
|
|||
|
|
|
|||
|
|
@item write @var{memtype} @var{addr} @var{byte1} @dots{} @var{byteN}
|
|||
|
|
Manually program the respective memory cells, starting at address addr,
|
|||
|
|
using the values @var{byte1} through @var{byteN}. This feature is not
|
|||
|
|
implemented for bank-addressed memories such as the flash memory of
|
|||
|
|
ATMega devices.
|
|||
|
|
|
|||
|
|
@item erase
|
|||
|
|
Perform a chip erase.
|
|||
|
|
|
|||
|
|
@item send @var{b1} @var{b2} @var{b3} @var{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.
|
|||
|
|
|
|||
|
|
@item sig
|
|||
|
|
Display the device signature bytes.
|
|||
|
|
|
|||
|
|
@item spi
|
|||
|
|
Enter direct SPI mode. The @emph{pgmled} pin acts as slave select.
|
|||
|
|
@emph{Only supported on parallel bitbang programmers.}
|
|||
|
|
|
|||
|
|
@item part
|
|||
|
|
Display the current part settings and parameters. Includes chip
|
|||
|
|
specific information including all memory types supported by the
|
|||
|
|
device, read/write timing, etc.
|
|||
|
|
|
|||
|
|
@item pgm
|
|||
|
|
Return to programming mode (from direct SPI mode).
|
|||
|
|
|
|||
|
|
@item verbose [@var{level}]
|
|||
|
|
Change (when @var{level} is provided), or display the verbosity
|
|||
|
|
level.
|
|||
|
|
The initial verbosity level is controlled by the number of @code{-v} options
|
|||
|
|
given on the command line.
|
|||
|
|
|
|||
|
|
@item ?
|
|||
|
|
@itemx help
|
|||
|
|
Give a short on-line summary of the available commands.
|
|||
|
|
|
|||
|
|
@item quit
|
|||
|
|
Leave terminal mode and thus AVRDUDE.
|
|||
|
|
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
In addition, the following commands are supported on the STK500
|
|||
|
|
and STK600 programmer:
|
|||
|
|
|
|||
|
|
@table @code
|
|||
|
|
|
|||
|
|
@item vtarg @var{voltage}
|
|||
|
|
Set the target's supply voltage to @var{voltage} Volts.
|
|||
|
|
|
|||
|
|
@item varef [@var{channel}] @var{voltage}
|
|||
|
|
Set the adjustable voltage source to @var{voltage} Volts.
|
|||
|
|
This voltage is normally used to drive the target's
|
|||
|
|
@emph{Aref} input on the STK500 and STK600.
|
|||
|
|
The STK600 offers two reference voltages, which can be
|
|||
|
|
selected by the optional parameter @var{channel} (either
|
|||
|
|
0 or 1).
|
|||
|
|
|
|||
|
|
@item fosc @var{freq}[@code{M}|@code{k}]
|
|||
|
|
Set the master oscillator to @var{freq} Hz.
|
|||
|
|
An optional trailing letter @code{M}
|
|||
|
|
multiplies by 1E6, a trailing letter @code{k} by 1E3.
|
|||
|
|
|
|||
|
|
@item fosc off
|
|||
|
|
Turn the master oscillator off.
|
|||
|
|
|
|||
|
|
@item sck @var{period}
|
|||
|
|
@emph{STK500 and STK600 only:}
|
|||
|
|
Set the SCK clock period to @var{period} microseconds.
|
|||
|
|
|
|||
|
|
@emph{JTAG ICE only:}
|
|||
|
|
Set the JTAG ICE bit clock period to @var{period} microseconds.
|
|||
|
|
Note that unlike STK500 settings, this setting 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/3 to specify the
|
|||
|
|
ISP clock period when operating the ICE in ISP mode.
|
|||
|
|
|
|||
|
|
@item parms
|
|||
|
|
@emph{STK500 and STK600 only:}
|
|||
|
|
Display the current voltage and master oscillator parameters.
|
|||
|
|
|
|||
|
|
@emph{JTAG ICE only:}
|
|||
|
|
Display the current target supply voltage and JTAG bit clock rate/period.
|
|||
|
|
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Terminal Mode Examples, , Terminal Mode Commands, Terminal Mode Operation
|
|||
|
|
@section Terminal Mode Examples
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
Display part parameters, modify eeprom cells, perform a chip erase:
|
|||
|
|
|
|||
|
|
@smallexample
|
|||
|
|
@cartouche
|
|||
|
|
% avrdude -p m128 -c stk500 -t
|
|||
|
|
|
|||
|
|
avrdude: AVR device initialized and ready to accept instructions
|
|||
|
|
avrdude: Device signature = 0x1e9702
|
|||
|
|
avrdude: current erase-rewrite cycle count is 52 (if being tracked)
|
|||
|
|
avrdude> part
|
|||
|
|
>>> part
|
|||
|
|
|
|||
|
|
AVR Part : ATMEGA128
|
|||
|
|
Chip Erase delay : 9000 us
|
|||
|
|
PAGEL : PD7
|
|||
|
|
BS2 : PA0
|
|||
|
|
RESET disposition : dedicated
|
|||
|
|
RETRY pulse : SCK
|
|||
|
|
serial program mode : yes
|
|||
|
|
parallel program mode : yes
|
|||
|
|
Memory Detail :
|
|||
|
|
|
|||
|
|
Page Polled
|
|||
|
|
Memory Type Paged Size Size #Pages MinW MaxW ReadBack
|
|||
|
|
----------- ------ ------ ---- ------ ----- ----- ---------
|
|||
|
|
eeprom no 4096 8 0 9000 9000 0xff 0xff
|
|||
|
|
flash yes 131072 256 512 4500 9000 0xff 0x00
|
|||
|
|
lfuse no 1 0 0 0 0 0x00 0x00
|
|||
|
|
hfuse no 1 0 0 0 0 0x00 0x00
|
|||
|
|
efuse no 1 0 0 0 0 0x00 0x00
|
|||
|
|
lock no 1 0 0 0 0 0x00 0x00
|
|||
|
|
calibration no 1 0 0 0 0 0x00 0x00
|
|||
|
|
signature no 3 0 0 0 0 0x00 0x00
|
|||
|
|
|
|||
|
|
avrdude> dump eeprom 0 16
|
|||
|
|
>>> dump eeprom 0 16
|
|||
|
|
0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
|
|||
|
|
|
|||
|
|
avrdude> write eeprom 0 1 2 3 4
|
|||
|
|
>>> write eeprom 0 1 2 3 4
|
|||
|
|
|
|||
|
|
avrdude> dump eeprom 0 16
|
|||
|
|
>>> dump eeprom 0 16
|
|||
|
|
0000 01 02 03 04 ff ff ff ff ff ff ff ff ff ff ff ff |................|
|
|||
|
|
|
|||
|
|
avrdude> erase
|
|||
|
|
>>> erase
|
|||
|
|
avrdude: erasing chip
|
|||
|
|
avrdude> dump eeprom 0 16
|
|||
|
|
>>> dump eeprom 0 16
|
|||
|
|
0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
|
|||
|
|
|
|||
|
|
avrdude>
|
|||
|
|
@end cartouche
|
|||
|
|
@end smallexample
|
|||
|
|
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
Program the fuse bits of an ATmega128 (disable M103 compatibility,
|
|||
|
|
enable high speed external crystal, enable brown-out detection, slowly
|
|||
|
|
rising power). Note since we are working with fuse bits the -u (unsafe)
|
|||
|
|
option is specified, which allows you to modify the fuse bits. First
|
|||
|
|
display the factory defaults, then reprogram:
|
|||
|
|
|
|||
|
|
@smallexample
|
|||
|
|
@cartouche
|
|||
|
|
% avrdude -p m128 -u -c stk500 -t
|
|||
|
|
|
|||
|
|
avrdude: AVR device initialized and ready to accept instructions
|
|||
|
|
avrdude: Device signature = 0x1e9702
|
|||
|
|
avrdude: current erase-rewrite cycle count is 52 (if being tracked)
|
|||
|
|
avrdude> d efuse
|
|||
|
|
>>> d efuse
|
|||
|
|
0000 fd |. |
|
|||
|
|
|
|||
|
|
avrdude> d hfuse
|
|||
|
|
>>> d hfuse
|
|||
|
|
0000 99 |. |
|
|||
|
|
|
|||
|
|
avrdude> d lfuse
|
|||
|
|
>>> d lfuse
|
|||
|
|
0000 e1 |. |
|
|||
|
|
|
|||
|
|
avrdude> w efuse 0 0xff
|
|||
|
|
>>> w efuse 0 0xff
|
|||
|
|
|
|||
|
|
avrdude> w hfuse 0 0x89
|
|||
|
|
>>> w hfuse 0 0x89
|
|||
|
|
|
|||
|
|
avrdude> w lfuse 0 0x2f
|
|||
|
|
>>> w lfuse 0 0x2f
|
|||
|
|
|
|||
|
|
avrdude>
|
|||
|
|
@end cartouche
|
|||
|
|
@end smallexample
|
|||
|
|
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Configuration File, Programmer Specific Information, Terminal Mode Operation, Top
|
|||
|
|
@chapter Configuration File
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
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 by AVRDUDE, chances are good that you can copy and
|
|||
|
|
existing programmer definition, and with only a few changes, make your
|
|||
|
|
programmer work with AVRDUDE.
|
|||
|
|
|
|||
|
|
AVRDUDE first looks for a system wide configuration file in a platform
|
|||
|
|
dependent location. On Unix, this is usually
|
|||
|
|
@code{/usr/local/etc/avrdude.conf}, while on Windows it is usually in the
|
|||
|
|
same location as the executable file. The name of this file can be
|
|||
|
|
changed using the @option{-C} command line option. After the system wide
|
|||
|
|
configuration file is parsed, AVRDUDE looks for a per-user configuration
|
|||
|
|
file to augment or override the system wide defaults. On Unix, the
|
|||
|
|
per-user file is @code{.avrduderc} within the user's home directory. On
|
|||
|
|
Windows, this file is the @code{avrdude.rc} file located in the same
|
|||
|
|
directory as the executable.
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* AVRDUDE Defaults::
|
|||
|
|
* Programmer Definitions::
|
|||
|
|
* Part Definitions::
|
|||
|
|
* Other Notes::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node AVRDUDE Defaults, Programmer Definitions, Configuration File, Configuration File
|
|||
|
|
@section AVRDUDE Defaults
|
|||
|
|
|
|||
|
|
@table @code
|
|||
|
|
|
|||
|
|
@item default_parallel = "@var{default-parallel-device}";
|
|||
|
|
Assign the default parallel port device. Can be overridden using the
|
|||
|
|
@option{-P} option.
|
|||
|
|
|
|||
|
|
@item default_serial = "@var{default-serial-device}";
|
|||
|
|
Assign the default serial port device. Can be overridden using the
|
|||
|
|
@option{-P} option.
|
|||
|
|
|
|||
|
|
@item default_programmer = "@var{default-programmer-id}";
|
|||
|
|
Assign the default programmer id. Can be overridden using the @option{-c}
|
|||
|
|
option.
|
|||
|
|
|
|||
|
|
@item default_bitclock = "@var{default-bitclock}";
|
|||
|
|
Assign the default bitclock value. Can be overridden using the @option{-B}
|
|||
|
|
option.
|
|||
|
|
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Programmer Definitions, Part Definitions, AVRDUDE Defaults, Configuration File
|
|||
|
|
@section Programmer Definitions
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
The format of the programmer definition is as follows:
|
|||
|
|
|
|||
|
|
@smallexample
|
|||
|
|
programmer
|
|||
|
|
parent <id> # <id> is a quoted string
|
|||
|
|
id = <id1> [, <id2> [, <id3>] ...] ; # <idN> are quoted strings
|
|||
|
|
desc = <description> ; # quoted string
|
|||
|
|
type = "par" | "stk500" | ... ; # programmer type (see below for a list)
|
|||
|
|
baudrate = <num> ; # baudrate for serial ports
|
|||
|
|
vcc = <num1> [, <num2> ... ] ; # pin number(s)
|
|||
|
|
buff = <num1> [, <num2> ... ] ; # pin number(s)
|
|||
|
|
reset = <num> ; # pin number
|
|||
|
|
sck = <num> ; # pin number
|
|||
|
|
mosi = <num> ; # pin number
|
|||
|
|
miso = <num> ; # pin number
|
|||
|
|
errled = <num> ; # pin number
|
|||
|
|
rdyled = <num> ; # pin number
|
|||
|
|
pgmled = <num> ; # pin number
|
|||
|
|
vfyled = <num> ; # pin number
|
|||
|
|
usbvid = <hexnum>; # USB VID (Vendor ID)
|
|||
|
|
usbpid = <hexnum> [, <hexnum> ...]; # USB PID (Product ID)
|
|||
|
|
usbdev = <interface>; # USB interface or other device info
|
|||
|
|
usbvendor = <vendorname>; # USB Vendor Name
|
|||
|
|
usbproduct = <productname>; # USB Product Name
|
|||
|
|
usbsn = <serialno>; # USB Serial Number
|
|||
|
|
;
|
|||
|
|
@end smallexample
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
To invert a bit in the pin definitions, use @code{= ~ <num>}.
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
Not all programmer types can handle a list of USB PIDs.
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
Following programmer types are currently implemented:
|
|||
|
|
|
|||
|
|
@multitable @columnfractions .25 .6
|
|||
|
|
@include programmer_types.texi
|
|||
|
|
@end multitable
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Part Definitions, Other Notes, Programmer Definitions, Configuration File
|
|||
|
|
@section Part Definitions
|
|||
|
|
|
|||
|
|
@smallexample
|
|||
|
|
part
|
|||
|
|
id = <id> ; # quoted string
|
|||
|
|
desc = <description> ; # quoted string
|
|||
|
|
family_id = <description> ; # quoted string
|
|||
|
|
has_jtag = <yes/no> ; # part has JTAG i/f
|
|||
|
|
has_debugwire = <yes/no> ; # part has debugWire i/f
|
|||
|
|
has_pdi = <yes/no> ; # part has PDI i/f
|
|||
|
|
has_updi = <yes/no> ; # part has UPDI i/f
|
|||
|
|
has_tpi = <yes/no> ; # part has TPI i/f
|
|||
|
|
devicecode = <num> ; # numeric
|
|||
|
|
stk500_devcode = <num> ; # numeric
|
|||
|
|
avr910_devcode = <num> ; # numeric
|
|||
|
|
signature = <num> <num> <num> ; # signature bytes
|
|||
|
|
usbpid = <num> ; # DFU USB PID
|
|||
|
|
reset = dedicated | io;
|
|||
|
|
retry_pulse = reset | sck;
|
|||
|
|
pgm_enable = <instruction format> ;
|
|||
|
|
chip_erase = <instruction format> ;
|
|||
|
|
chip_erase_delay = <num> ; # micro-seconds
|
|||
|
|
# STK500 parameters (parallel programming IO lines)
|
|||
|
|
pagel = <num> ; # pin name in hex, i.e., 0xD7
|
|||
|
|
bs2 = <num> ; # pin name in hex, i.e., 0xA0
|
|||
|
|
serial = <yes/no> ; # can use serial downloading
|
|||
|
|
parallel = <yes/no/pseudo>; # can use par. programming
|
|||
|
|
# STK500v2 parameters, to be taken from Atmel's XML files
|
|||
|
|
timeout = <num> ;
|
|||
|
|
stabdelay = <num> ;
|
|||
|
|
cmdexedelay = <num> ;
|
|||
|
|
synchloops = <num> ;
|
|||
|
|
bytedelay = <num> ;
|
|||
|
|
pollvalue = <num> ;
|
|||
|
|
pollindex = <num> ;
|
|||
|
|
predelay = <num> ;
|
|||
|
|
postdelay = <num> ;
|
|||
|
|
pollmethod = <num> ;
|
|||
|
|
mode = <num> ;
|
|||
|
|
delay = <num> ;
|
|||
|
|
blocksize = <num> ;
|
|||
|
|
readsize = <num> ;
|
|||
|
|
hvspcmdexedelay = <num> ;
|
|||
|
|
# STK500v2 HV programming parameters, from XML
|
|||
|
|
pp_controlstack = <num>, <num>, ...; # PP only
|
|||
|
|
hvsp_controlstack = <num>, <num>, ...; # HVSP only
|
|||
|
|
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>;
|
|||
|
|
# JTAG ICE mkII parameters, also from XML 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.
|
|||
|
|
# (only when != 0x3c)
|
|||
|
|
is_at90s1200 = <yes/no> ; # AT90S1200 part
|
|||
|
|
is_avr32 = <yes/no> ; # AVR32 part
|
|||
|
|
|
|||
|
|
memory <memtype>
|
|||
|
|
paged = <yes/no> ; # yes / no
|
|||
|
|
size = <num> ; # bytes
|
|||
|
|
page_size = <num> ; # bytes
|
|||
|
|
num_pages = <num> ; # numeric
|
|||
|
|
min_write_delay = <num> ; # micro-seconds
|
|||
|
|
max_write_delay = <num> ; # micro-seconds
|
|||
|
|
readback_p1 = <num> ; # byte value
|
|||
|
|
readback_p2 = <num> ; # byte value
|
|||
|
|
pwroff_after_write = <yes/no> ; # yes / no
|
|||
|
|
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> ;
|
|||
|
|
;
|
|||
|
|
;
|
|||
|
|
@end smallexample
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* Parent Part::
|
|||
|
|
* Instruction Format::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Parent Part, Instruction Format, Part Definitions, Part Definitions
|
|||
|
|
@subsection Parent Part
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
@smallexample
|
|||
|
|
part parent <id> # quoted string
|
|||
|
|
id = <id> ; # quoted string
|
|||
|
|
<any set of other parameters from the list above>
|
|||
|
|
;
|
|||
|
|
@end smallexample
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Instruction Format, , Parent Part, Part Definitions
|
|||
|
|
@subsection Instruction Format
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
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:
|
|||
|
|
|
|||
|
|
@table @code
|
|||
|
|
|
|||
|
|
@item 1
|
|||
|
|
The bit is always set on input as well as output
|
|||
|
|
|
|||
|
|
@item 0
|
|||
|
|
the bit is always clear on input as well as output
|
|||
|
|
|
|||
|
|
@item x
|
|||
|
|
the bit is ignored on input and output
|
|||
|
|
|
|||
|
|
@item a
|
|||
|
|
the bit is an address bit, the bit-number matches this bit specifier's
|
|||
|
|
position within the current instruction byte
|
|||
|
|
|
|||
|
|
@item a@var{N}
|
|||
|
|
the bit is the @var{N}th address bit, bit-number = N, i.e., @code{a12}
|
|||
|
|
is address bit 12 on input, @code{a0} is address bit 0.
|
|||
|
|
|
|||
|
|
@item i
|
|||
|
|
the bit is an input data bit
|
|||
|
|
|
|||
|
|
@item o
|
|||
|
|
the bit is an output data bit
|
|||
|
|
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
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:
|
|||
|
|
|
|||
|
|
@smallexample
|
|||
|
|
|
|||
|
|
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";
|
|||
|
|
|
|||
|
|
@end smallexample
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Other Notes, , Part Definitions, Configuration File
|
|||
|
|
@section Other Notes
|
|||
|
|
|
|||
|
|
|
|||
|
|
@itemize @bullet
|
|||
|
|
@item
|
|||
|
|
The @code{devicecode} parameter is the device code used by the STK500
|
|||
|
|
and is obtained from the software section (@code{avr061.zip}) of
|
|||
|
|
Atmel's AVR061 application note available from
|
|||
|
|
@url{http://www.atmel.com/dyn/resources/prod_documents/doc2525.pdf}.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Not all memory types will implement all instructions.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
AVR Fuse bits and Lock bits are implemented as a type of memory.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Example memory types are: @code{flash}, @code{eeprom}, @code{fuse},
|
|||
|
|
@code{lfuse} (low fuse), @code{hfuse} (high fuse), @code{efuse}
|
|||
|
|
(extended fuse), @code{signature}, @code{calibration}, @code{lock}.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
The memory type specified on the AVRDUDE command line must match one of
|
|||
|
|
the memory types defined for the specified chip.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
The @code{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:
|
|||
|
|
|
|||
|
|
@url{http://www.atmel.com/dyn/resources/prod_documents/doc1280.pdf}
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
The boot loader from application note AVR109 (and thus also the AVR
|
|||
|
|
Butterfly) does not support writing of fuse bits. Writing lock bits
|
|||
|
|
is supported, but is restricted to the boot lock bits (BLBxx). These
|
|||
|
|
are restrictions imposed by the underlying SPM instruction that is used
|
|||
|
|
to program the device from inside the boot loader. Note that programming
|
|||
|
|
the boot lock bits can result in a ``shoot-into-your-foot'' scenario as
|
|||
|
|
the only way to unprogram these bits is a chip erase, which will also
|
|||
|
|
erase the boot loader code.
|
|||
|
|
|
|||
|
|
The boot loader implements the ``chip erase'' function by erasing the
|
|||
|
|
flash pages of the application section.
|
|||
|
|
|
|||
|
|
Reading fuse and lock bits is fully supported.
|
|||
|
|
|
|||
|
|
Note that due to the inability to write the fuse bits, the safemode
|
|||
|
|
functionality does not make sense for these boot loaders.
|
|||
|
|
|
|||
|
|
@end itemize
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Programmer Specific Information, Platform Dependent Information, Configuration File, Top
|
|||
|
|
@chapter Programmer Specific Information
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* Atmel STK600::
|
|||
|
|
* Atmel DFU bootloader using FLIP version 1::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Atmel STK600, Atmel DFU bootloader using FLIP version 1, Programmer Specific Information, Programmer Specific Information
|
|||
|
|
@section Atmel STK600
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Update the table below by running the tools/get-stk600-devices.xsl
|
|||
|
|
@c XSLT transformation on targetboard.xml as shipped by the latest
|
|||
|
|
@c release of AVR Studio.
|
|||
|
|
@c
|
|||
|
|
The following devices are supported by the respective STK600 routing
|
|||
|
|
and socket card:
|
|||
|
|
|
|||
|
|
@multitable @columnfractions .25 .25 .5
|
|||
|
|
@headitem Routing card @tab Socket card @tab Devices
|
|||
|
|
@item @code{} @tab @code{STK600-ATTINY10} @tab ATtiny4 ATtiny5 ATtiny9 ATtiny10
|
|||
|
|
@item @code{STK600-RC008T-2} @tab @code{STK600-DIP} @tab ATtiny11 ATtiny12 ATtiny13 ATtiny13A ATtiny25 ATtiny45 ATtiny85
|
|||
|
|
@item @code{STK600-RC008T-7} @tab @code{STK600-DIP} @tab ATtiny15
|
|||
|
|
@item @code{STK600-RC014T-42} @tab @code{STK600-SOIC} @tab ATtiny20
|
|||
|
|
@item @code{STK600-RC020T-1} @tab @code{STK600-DIP} @tab ATtiny2313 ATtiny2313A ATtiny4313
|
|||
|
|
@item @code{} @tab @code{STK600-TinyX3U} @tab ATtiny43U
|
|||
|
|
@item @code{STK600-RC014T-12} @tab @code{STK600-DIP} @tab ATtiny24 ATtiny44 ATtiny84 ATtiny24A ATtiny44A
|
|||
|
|
@item @code{STK600-RC020T-8} @tab @code{STK600-DIP} @tab ATtiny26 ATtiny261 ATtiny261A ATtiny461 ATtiny861 ATtiny861A
|
|||
|
|
@item @code{STK600-RC020T-43} @tab @code{STK600-SOIC} @tab ATtiny261 ATtiny261A ATtiny461 ATtiny461A ATtiny861 ATtiny861A
|
|||
|
|
@item @code{STK600-RC020T-23} @tab @code{STK600-SOIC} @tab ATtiny87 ATtiny167
|
|||
|
|
@item @code{STK600-RC028T-3} @tab @code{STK600-DIP} @tab ATtiny28
|
|||
|
|
@item @code{STK600-RC028M-6} @tab @code{STK600-DIP} @tab ATtiny48 ATtiny88 ATmega8 ATmega8A ATmega48 ATmega88 ATmega168 ATmega48P ATmega48PA ATmega88P ATmega88PA ATmega168P ATmega168PA ATmega328P
|
|||
|
|
@item @code{} @tab @code{QT600-ATTINY88-QT8} @tab ATtiny88
|
|||
|
|
@item @code{STK600-RC040M-4} @tab @code{STK600-DIP} @tab ATmega8515 ATmega162
|
|||
|
|
@item @code{STK600-RC044M-30} @tab @code{STK600-TQFP44} @tab ATmega8515 ATmega162
|
|||
|
|
@item @code{STK600-RC040M-5} @tab @code{STK600-DIP} @tab ATmega8535 ATmega16 ATmega16A ATmega32 ATmega32A ATmega164P ATmega164PA ATmega324P ATmega324PA ATmega644 ATmega644P ATmega644PA ATmega1284P
|
|||
|
|
@item @code{STK600-RC044M-31} @tab @code{STK600-TQFP44} @tab ATmega8535 ATmega16 ATmega16A ATmega32 ATmega32A ATmega164P ATmega164PA ATmega324P ATmega324PA ATmega644 ATmega644P ATmega644PA ATmega1284P
|
|||
|
|
@item @code{} @tab @code{QT600-ATMEGA324-QM64} @tab ATmega324PA
|
|||
|
|
@item @code{STK600-RC032M-29} @tab @code{STK600-TQFP32} @tab ATmega8 ATmega8A ATmega48 ATmega88 ATmega168 ATmega48P ATmega48PA ATmega88P ATmega88PA ATmega168P ATmega168PA ATmega328P
|
|||
|
|
@item @code{STK600-RC064M-9} @tab @code{STK600-TQFP64} @tab ATmega64 ATmega64A ATmega128 ATmega128A ATmega1281 ATmega2561 AT90CAN32 AT90CAN64 AT90CAN128
|
|||
|
|
@item @code{STK600-RC064M-10} @tab @code{STK600-TQFP64} @tab ATmega165 ATmega165P ATmega169 ATmega169P ATmega169PA ATmega325 ATmega325P ATmega329 ATmega329P ATmega645 ATmega649 ATmega649P
|
|||
|
|
@item @code{STK600-RC100M-11} @tab @code{STK600-TQFP100} @tab ATmega640 ATmega1280 ATmega2560
|
|||
|
|
@item @code{} @tab @code{STK600-ATMEGA2560} @tab ATmega2560
|
|||
|
|
@item @code{STK600-RC100M-18} @tab @code{STK600-TQFP100} @tab ATmega3250 ATmega3250P ATmega3290 ATmega3290P ATmega6450 ATmega6490
|
|||
|
|
@item @code{STK600-RC032U-20} @tab @code{STK600-TQFP32} @tab AT90USB82 AT90USB162 ATmega8U2 ATmega16U2 ATmega32U2
|
|||
|
|
@item @code{STK600-RC044U-25} @tab @code{STK600-TQFP44} @tab ATmega16U4 ATmega32U4
|
|||
|
|
@item @code{STK600-RC064U-17} @tab @code{STK600-TQFP64} @tab ATmega32U6 AT90USB646 AT90USB1286 AT90USB647 AT90USB1287
|
|||
|
|
@item @code{STK600-RCPWM-22} @tab @code{STK600-TQFP32} @tab ATmega32C1 ATmega64C1 ATmega16M1 ATmega32M1 ATmega64M1
|
|||
|
|
@item @code{STK600-RCPWM-19} @tab @code{STK600-SOIC} @tab AT90PWM2 AT90PWM3 AT90PWM2B AT90PWM3B AT90PWM216 AT90PWM316
|
|||
|
|
@item @code{STK600-RCPWM-26} @tab @code{STK600-SOIC} @tab AT90PWM81
|
|||
|
|
@item @code{STK600-RC044M-24} @tab @code{STK600-TSSOP44} @tab ATmega16HVB ATmega32HVB
|
|||
|
|
@item @code{} @tab @code{STK600-HVE2} @tab ATmega64HVE
|
|||
|
|
@item @code{} @tab @code{STK600-ATMEGA128RFA1} @tab ATmega128RFA1
|
|||
|
|
@item @code{STK600-RC100X-13} @tab @code{STK600-TQFP100} @tab ATxmega64A1 ATxmega128A1 ATxmega128A1_revD ATxmega128A1U
|
|||
|
|
@item @code{} @tab @code{STK600-ATXMEGA1281A1} @tab ATxmega128A1
|
|||
|
|
@item @code{} @tab @code{QT600-ATXMEGA128A1-QT16} @tab ATxmega128A1
|
|||
|
|
@item @code{STK600-RC064X-14} @tab @code{STK600-TQFP64} @tab ATxmega64A3 ATxmega128A3 ATxmega256A3 ATxmega64D3 ATxmega128D3 ATxmega192D3 ATxmega256D3
|
|||
|
|
@item @code{STK600-RC064X-14} @tab @code{STK600-MLF64} @tab ATxmega256A3B
|
|||
|
|
@item @code{STK600-RC044X-15} @tab @code{STK600-TQFP44} @tab ATxmega32A4 ATxmega16A4 ATxmega16D4 ATxmega32D4
|
|||
|
|
@item @code{} @tab @code{STK600-ATXMEGAT0} @tab ATxmega32T0
|
|||
|
|
@item @code{} @tab @code{STK600-uC3-144} @tab AT32UC3A0512 AT32UC3A0256 AT32UC3A0128
|
|||
|
|
@item @code{STK600-RCUC3A144-33} @tab @code{STK600-TQFP144} @tab AT32UC3A0512 AT32UC3A0256 AT32UC3A0128
|
|||
|
|
@item @code{STK600-RCuC3A100-28} @tab @code{STK600-TQFP100} @tab AT32UC3A1512 AT32UC3A1256 AT32UC3A1128
|
|||
|
|
@item @code{STK600-RCuC3B0-21} @tab @code{STK600-TQFP64-2} @tab AT32UC3B0256 AT32UC3B0512RevC AT32UC3B0512 AT32UC3B0128 AT32UC3B064 AT32UC3D1128
|
|||
|
|
@item @code{STK600-RCuC3B48-27} @tab @code{STK600-TQFP48} @tab AT32UC3B1256 AT32UC3B164
|
|||
|
|
@item @code{STK600-RCUC3A144-32} @tab @code{STK600-TQFP144} @tab AT32UC3A3512 AT32UC3A3256 AT32UC3A3128 AT32UC3A364 AT32UC3A3256S AT32UC3A3128S AT32UC3A364S
|
|||
|
|
@item @code{STK600-RCUC3C0-36} @tab @code{STK600-TQFP144} @tab AT32UC3C0512 AT32UC3C0256 AT32UC3C0128 AT32UC3C064
|
|||
|
|
@item @code{STK600-RCUC3C1-38} @tab @code{STK600-TQFP100} @tab AT32UC3C1512 AT32UC3C1256 AT32UC3C1128 AT32UC3C164
|
|||
|
|
@item @code{STK600-RCUC3C2-40} @tab @code{STK600-TQFP64-2} @tab AT32UC3C2512 AT32UC3C2256 AT32UC3C2128 AT32UC3C264
|
|||
|
|
@item @code{STK600-RCUC3C0-37} @tab @code{STK600-TQFP144} @tab AT32UC3C0512 AT32UC3C0256 AT32UC3C0128 AT32UC3C064
|
|||
|
|
@item @code{STK600-RCUC3C1-39} @tab @code{STK600-TQFP100} @tab AT32UC3C1512 AT32UC3C1256 AT32UC3C1128 AT32UC3C164
|
|||
|
|
@item @code{STK600-RCUC3C2-41} @tab @code{STK600-TQFP64-2} @tab AT32UC3C2512 AT32UC3C2256 AT32UC3C2128 AT32UC3C264
|
|||
|
|
@item @code{STK600-RCUC3L0-34} @tab @code{STK600-TQFP48} @tab AT32UC3L064 AT32UC3L032 AT32UC3L016
|
|||
|
|
@item @code{} @tab @code{QT600-AT32UC3L-QM64} @tab AT32UC3L064
|
|||
|
|
@end multitable
|
|||
|
|
|
|||
|
|
Ensure the correct socket and routing card are mounted @emph{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
|
|||
|
|
@code{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 @code{STK600-RC008T-2},
|
|||
|
|
in order to use ISP mode, the jumper for @code{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
|
|||
|
|
@emph{Terminal Mode}, see @ref{Terminal Mode Operation}.
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Atmel DFU bootloader using FLIP version 1, , Atmel STK600, Programmer Specific Information
|
|||
|
|
@section Atmel DFU bootloader using FLIP version 1
|
|||
|
|
|
|||
|
|
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 @emph{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 @emph{chip erase}. As a chip erase
|
|||
|
|
is normally implied by the @option{-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 @option{-F} option.
|
|||
|
|
|
|||
|
|
A @emph{chip erase} might leave the EEPROM unerased, at least on some
|
|||
|
|
versions of the bootloader.
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Platform Dependent Information, Troubleshooting, Programmer Specific Information, Top
|
|||
|
|
@appendix Platform Dependent Information
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* Unix::
|
|||
|
|
* Windows::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Unix, Windows, Platform Dependent Information, Platform Dependent Information
|
|||
|
|
@section Unix
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* Unix Installation::
|
|||
|
|
* Unix Configuration Files::
|
|||
|
|
* Unix Port Names::
|
|||
|
|
* Unix Documentation::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Unix Installation, Unix Configuration Files, Unix, Unix
|
|||
|
|
@subsection Unix Installation
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
To build and install from the source tarball on Unix like systems:
|
|||
|
|
|
|||
|
|
@example
|
|||
|
|
$ gunzip -c avrdude-@value{VERSION}.tar.gz | tar xf -
|
|||
|
|
$ cd avrdude-@value{VERSION}
|
|||
|
|
$ ./configure
|
|||
|
|
$ make
|
|||
|
|
$ su root -c 'make install'
|
|||
|
|
@end example
|
|||
|
|
|
|||
|
|
The default location of the install is into @code{/usr/local} so you
|
|||
|
|
will need to be sure that @code{/usr/local/bin} is in your @code{PATH}
|
|||
|
|
environment variable.
|
|||
|
|
|
|||
|
|
If you do not have root access to your system, you can do the
|
|||
|
|
following instead:
|
|||
|
|
|
|||
|
|
@example
|
|||
|
|
$ gunzip -c avrdude-@value{VERSION}.tar.gz | tar xf -
|
|||
|
|
$ cd avrdude-@value{VERSION}
|
|||
|
|
$ ./configure --prefix=$HOME/local
|
|||
|
|
$ make
|
|||
|
|
$ make install
|
|||
|
|
@end example
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* FreeBSD Installation::
|
|||
|
|
* Linux Installation::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node FreeBSD Installation, Linux Installation, Unix Installation, Unix Installation
|
|||
|
|
@subsubsection FreeBSD Installation
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
AVRDUDE is installed via the FreeBSD Ports Tree as follows:
|
|||
|
|
|
|||
|
|
@example
|
|||
|
|
% su - root
|
|||
|
|
# cd /usr/ports/devel/avrdude
|
|||
|
|
# make install
|
|||
|
|
@end example
|
|||
|
|
|
|||
|
|
If you wish to install from a pre-built package instead of the source,
|
|||
|
|
you can use the following instead:
|
|||
|
|
|
|||
|
|
@example
|
|||
|
|
% su - root
|
|||
|
|
# pkg_add -r avrdude
|
|||
|
|
@end example
|
|||
|
|
|
|||
|
|
Of course, you must be connected to the Internet for these methods to
|
|||
|
|
work, since that is where the source as well as the pre-built package is
|
|||
|
|
obtained.
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Linux Installation, , FreeBSD Installation, Unix Installation
|
|||
|
|
@subsubsection Linux Installation
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
On rpm based Linux systems (such as RedHat, SUSE, Mandrake, etc.), you
|
|||
|
|
can build and install the rpm binaries directly from the tarball:
|
|||
|
|
|
|||
|
|
@example
|
|||
|
|
$ su - root
|
|||
|
|
# rpmbuild -tb avrdude-@value{VERSION}.tar.gz
|
|||
|
|
# rpm -Uvh /usr/src/redhat/RPMS/i386/avrdude-@value{VERSION}-1.i386.rpm
|
|||
|
|
@end example
|
|||
|
|
|
|||
|
|
Note that the path to the resulting rpm package, differs from system
|
|||
|
|
to system. The above example is specific to RedHat.
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Unix Configuration Files, Unix Port Names, Unix Installation, Unix
|
|||
|
|
@subsection Unix Configuration Files
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
When AVRDUDE is build using the default @option{--prefix} configure
|
|||
|
|
option, the default configuration file for a Unix system is located at
|
|||
|
|
@code{/usr/local/etc/avrdude.conf}. This can be overridden by using the
|
|||
|
|
@option{-C} command line option. Additionally, the user's home directory
|
|||
|
|
is searched for a file named @code{.avrduderc}, and if found, is used to
|
|||
|
|
augment the system default configuration file.
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* FreeBSD Configuration Files::
|
|||
|
|
* Linux Configuration Files::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node FreeBSD Configuration Files, Linux Configuration Files, Unix Configuration Files, Unix Configuration Files
|
|||
|
|
@subsubsection FreeBSD Configuration Files
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
When AVRDUDE is installed using the FreeBSD ports system, the system
|
|||
|
|
configuration file is always @code{/usr/local/etc/avrdude.conf}.
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Linux Configuration Files, , FreeBSD Configuration Files, Unix Configuration Files
|
|||
|
|
@subsubsection Linux Configuration Files
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
When AVRDUDE is installed using from an rpm package, the system
|
|||
|
|
configuration file will be always be @code{/etc/avrdude.conf}.
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Unix Port Names, Unix Documentation, Unix Configuration Files, Unix
|
|||
|
|
@subsection Unix Port Names
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
The parallel and serial port device file names are system specific.
|
|||
|
|
The following table lists the default names for a given system.
|
|||
|
|
|
|||
|
|
@multitable @columnfractions .30 .30 .30
|
|||
|
|
@item @strong{System}
|
|||
|
|
@tab @strong{Default Parallel Port}
|
|||
|
|
@tab @strong{Default Serial Port}
|
|||
|
|
@item FreeBSD
|
|||
|
|
@tab @code{/dev/ppi0}
|
|||
|
|
@tab @code{/dev/cuad0}
|
|||
|
|
@item Linux
|
|||
|
|
@tab @code{/dev/parport0}
|
|||
|
|
@tab @code{/dev/ttyS0}
|
|||
|
|
@item Solaris
|
|||
|
|
@tab @code{/dev/printers/0}
|
|||
|
|
@tab @code{/dev/term/a}
|
|||
|
|
@end multitable
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Unix Documentation, , Unix Port Names, Unix
|
|||
|
|
@subsection Unix Documentation
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
AVRDUDE installs a manual page as well as info, HTML and PDF
|
|||
|
|
documentation. The manual page is installed in
|
|||
|
|
@code{/usr/local/man/man1} area, while the HTML and PDF documentation
|
|||
|
|
is installed in @code{/usr/local/share/doc/avrdude} directory. The
|
|||
|
|
info manual is installed in @code{/usr/local/info/avrdude.info}.
|
|||
|
|
|
|||
|
|
Note that these locations can be altered by various configure options
|
|||
|
|
such as @option{--prefix}.
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Windows, , Unix, Platform Dependent Information
|
|||
|
|
@section Windows
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* Windows Installation::
|
|||
|
|
* Windows Configuration Files::
|
|||
|
|
* Windows Port Names::
|
|||
|
|
* Using the parallel port::
|
|||
|
|
* Documentation::
|
|||
|
|
* Credits.::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Windows Installation, Windows Configuration Files, Windows, Windows
|
|||
|
|
@subsection Installation
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
A Windows executable of avrdude is included in WinAVR which can be found at
|
|||
|
|
@url{http://sourceforge.net/projects/winavr}. WinAVR is a suite of executable,
|
|||
|
|
open source software development tools for the AVR for the Windows platform.
|
|||
|
|
|
|||
|
|
There are two options to build avrdude from source under Windows.
|
|||
|
|
The first one is to use Cygwin (@url{http://www.cygwin.com/}).
|
|||
|
|
|
|||
|
|
To build and install from the source tarball for Windows (using Cygwin):
|
|||
|
|
|
|||
|
|
@example
|
|||
|
|
$ set PREFIX=<your install directory path>
|
|||
|
|
$ export PREFIX
|
|||
|
|
$ gunzip -c avrdude-@value{VERSION}.tar.gz | tar xf -
|
|||
|
|
$ cd avrdude-@value{VERSION}
|
|||
|
|
$ ./configure LDFLAGS="-static" --prefix=$PREFIX --datadir=$PREFIX
|
|||
|
|
--sysconfdir=$PREFIX/bin --enable-versioned-doc=no
|
|||
|
|
$ make
|
|||
|
|
$ make install
|
|||
|
|
@end example
|
|||
|
|
|
|||
|
|
Note that recent versions of Cygwin (starting with 1.7) removed the
|
|||
|
|
MinGW support from the compiler that is needed in order to build a
|
|||
|
|
native Win32 API binary that does not require to install the Cygwin
|
|||
|
|
library @code{cygwin1.dll} at run-time. Either try using an older
|
|||
|
|
compiler version that still supports MinGW builds, or use MinGW
|
|||
|
|
(@url{http://www.mingw.org/}) directly.
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c XXX Please add more detailed instructions here.
|
|||
|
|
@c
|
|||
|
|
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Windows Configuration Files, Windows Port Names, Windows Installation, Windows
|
|||
|
|
@subsection Configuration Files
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* Configuration file names::
|
|||
|
|
* How AVRDUDE finds the configuration files.::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Configuration file names, How AVRDUDE finds the configuration files., Windows Configuration Files, Windows Configuration Files
|
|||
|
|
@subsubsection Configuration file names
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
AVRDUDE on Windows looks for a system configuration file name of
|
|||
|
|
@code{avrdude.conf} and looks for a user override configuration file of
|
|||
|
|
@code{avrdude.rc}.
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node How AVRDUDE finds the configuration files., , Configuration file names, Windows Configuration Files
|
|||
|
|
@subsubsection How AVRDUDE finds the configuration files.
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
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:
|
|||
|
|
|
|||
|
|
@enumerate
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
The directory from which the application loaded.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
The current directory.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
The Windows system directory. On Windows NT, the name of this directory
|
|||
|
|
is @code{SYSTEM32}.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Windows NT: The 16-bit Windows system directory. The name of this
|
|||
|
|
directory is @code{SYSTEM}.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
The Windows directory.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
The directories that are listed in the PATH environment variable.
|
|||
|
|
|
|||
|
|
@end enumerate
|
|||
|
|
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Windows Port Names, Using the parallel port, Windows Configuration Files, Windows
|
|||
|
|
@subsection Port Names
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* Serial Ports::
|
|||
|
|
* Parallel Ports::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Serial Ports, Parallel Ports, Windows Port Names, Windows Port Names
|
|||
|
|
@subsubsection Serial Ports
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
When you select a serial port (i.e. when using an STK500) use the
|
|||
|
|
Windows serial port device names such as: com1, com2, etc.
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Parallel Ports, , Serial Ports, Windows Port Names
|
|||
|
|
@subsubsection Parallel Ports
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
AVRDUDE will accept 3 Windows parallel port names: lpt1, lpt2, or
|
|||
|
|
lpt3. Each of these names corresponds to a fixed parallel port base
|
|||
|
|
address:
|
|||
|
|
|
|||
|
|
@table @code
|
|||
|
|
@item lpt1
|
|||
|
|
0x378
|
|||
|
|
|
|||
|
|
@item lpt2
|
|||
|
|
0x278
|
|||
|
|
|
|||
|
|
@item lpt3
|
|||
|
|
0x3BC
|
|||
|
|
|
|||
|
|
@end table
|
|||
|
|
|
|||
|
|
On your desktop PC, lpt1 will be the most common choice. If you are
|
|||
|
|
using a laptop, you might have to use lpt3 instead of lpt1. Select the
|
|||
|
|
name of the port the corresponds to the base address of the parallel
|
|||
|
|
port that you want.
|
|||
|
|
|
|||
|
|
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 @code{0x}).
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Using the parallel port, Documentation, Windows Port Names, Windows
|
|||
|
|
@subsection Using the parallel port
|
|||
|
|
|
|||
|
|
@menu
|
|||
|
|
* Windows NT/2K/XP::
|
|||
|
|
* Windows 95/98::
|
|||
|
|
@end menu
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Windows NT/2K/XP, Windows 95/98, Using the parallel port, Using the parallel port
|
|||
|
|
@subsubsection Windows NT/2K/XP
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
On Windows NT, 2000, and XP user applications cannot directly access the
|
|||
|
|
parallel port. However, kernel mode drivers can access the parallel port.
|
|||
|
|
giveio.sys is a driver that can allow user applications to set the state
|
|||
|
|
of the parallel port pins.
|
|||
|
|
|
|||
|
|
Before using AVRDUDE, the giveio.sys driver must be loaded. The
|
|||
|
|
accompanying command-line program, loaddrv.exe, can do just that.
|
|||
|
|
|
|||
|
|
To make things even easier there are 3 batch files that are also
|
|||
|
|
included:
|
|||
|
|
|
|||
|
|
@enumerate
|
|||
|
|
@item install_giveio.bat
|
|||
|
|
Install and start the giveio driver.
|
|||
|
|
|
|||
|
|
@item status_giveio.bat
|
|||
|
|
Check on the status of the giveio driver.
|
|||
|
|
|
|||
|
|
@item remove_giveio.bat
|
|||
|
|
Stop and remove the giveio driver from memory.
|
|||
|
|
@end enumerate
|
|||
|
|
|
|||
|
|
These 3 batch files calls the loaddrv program with various options to
|
|||
|
|
install, start, stop, and remove the driver.
|
|||
|
|
|
|||
|
|
When you first execute install_giveio.bat, loaddrv.exe and giveio.sys
|
|||
|
|
must be in the current directory. When install_giveio.bat is executed it
|
|||
|
|
will copy giveio.sys from your current directory to your Windows
|
|||
|
|
directory. It will then load the driver from the Windows directory. This
|
|||
|
|
means that after the first time install_giveio is executed, you should
|
|||
|
|
be able to subsequently execute the batch file from any directory and have
|
|||
|
|
it successfully start the driver.
|
|||
|
|
|
|||
|
|
Note that you must have administrator privilege to load the giveio driver.
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Windows 95/98, , Windows NT/2K/XP, Using the parallel port
|
|||
|
|
@subsubsection Windows 95/98
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
On Windows 95 and 98 the giveio.sys driver is not needed.
|
|||
|
|
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Documentation, Credits., Using the parallel port, Windows
|
|||
|
|
@subsection Documentation
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
AVRDUDE installs a manual page as well as info, HTML and PDF
|
|||
|
|
documentation. The manual page is installed in
|
|||
|
|
@code{/usr/local/man/man1} area, while the HTML and PDF documentation
|
|||
|
|
is installed in @code{/usr/local/share/doc/avrdude} directory. The
|
|||
|
|
info manual is installed in @code{/usr/local/info/avrdude.info}.
|
|||
|
|
|
|||
|
|
Note that these locations can be altered by various configure options
|
|||
|
|
such as @option{--prefix} and @option{--datadir}.
|
|||
|
|
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Credits., , Documentation, Windows
|
|||
|
|
@subsection Credits.
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
Thanks to:
|
|||
|
|
|
|||
|
|
@itemize @bullet
|
|||
|
|
@item
|
|||
|
|
Dale Roberts for the giveio driver.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Paula Tomlinson for the loaddrv sources.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Chris Liechti <cliechti@@gmx.net> for modifying loaddrv to be command
|
|||
|
|
line driven and for writing the batch files.
|
|||
|
|
|
|||
|
|
@end itemize
|
|||
|
|
|
|||
|
|
@c
|
|||
|
|
@c Node
|
|||
|
|
@c
|
|||
|
|
@node Troubleshooting, ,Platform Dependent Information ,Top
|
|||
|
|
@appendix Troubleshooting
|
|||
|
|
|
|||
|
|
@noindent
|
|||
|
|
In general, please report any bugs encountered via
|
|||
|
|
@*
|
|||
|
|
@url{http://savannah.nongnu.org/bugs/?group=avrdude}.
|
|||
|
|
|
|||
|
|
|
|||
|
|
@itemize @bullet
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: I'm using a serial programmer under Windows and get the following
|
|||
|
|
error:
|
|||
|
|
|
|||
|
|
@code{avrdude: serial_open(): can't set attributes for device "com1"},
|
|||
|
|
|
|||
|
|
Solution: This problem seems to appear with certain versions of Cygwin. Specifying
|
|||
|
|
@code{"/dev/com1"} instead of @code{"com1"} should help.
|
|||
|
|
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: I'm using Linux and my AVR910 programmer is really slow.
|
|||
|
|
|
|||
|
|
Solution (short): @code{setserial @var{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).
|
|||
|
|
|
|||
|
|
@code{setserial @var{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 @code{drivers/char/serial.c}.
|
|||
|
|
Search the file for @code{UART_FCR_TRIGGER_8} and replace it with @code{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.
|
|||
|
|
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: I'm not using Linux and my AVR910 programmer is really slow.
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: Updating the flash ROM from terminal mode does not work with the
|
|||
|
|
JTAG ICEs.
|
|||
|
|
|
|||
|
|
Solution: None at this time. Currently, the JTAG ICE code cannot
|
|||
|
|
write to the flash ROM one byte at a time.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: Page-mode programming the EEPROM (using the -U option) does
|
|||
|
|
not erase EEPROM cells before writing, and thus cannot overwrite any
|
|||
|
|
previous value != 0xff.
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: How do I turn off the @var{DWEN} fuse?
|
|||
|
|
|
|||
|
|
Solution: If the @var{DWEN} (debugWire enable) fuse is activated,
|
|||
|
|
the @var{/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
|
|||
|
|
@var{/RESET} pin is activated initially using a 12 V pulse (thus the
|
|||
|
|
name @emph{high voltage}), so the target AVR can subsequently be
|
|||
|
|
reprogrammed, and the @var{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 @var{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 @var{DWEN} fuse can be cleared.
|
|||
|
|
|
|||
|
|
The pin mapping for the JTAG-to-ISP adapter is:
|
|||
|
|
|
|||
|
|
@multitable @columnfractions .2 .2
|
|||
|
|
@item @strong{JTAG pin} @tab @strong{ISP pin}
|
|||
|
|
@item 1 @tab 3
|
|||
|
|
@item 2 @tab 6
|
|||
|
|
@item 3 @tab 1
|
|||
|
|
@item 4 @tab 2
|
|||
|
|
@item 6 @tab 5
|
|||
|
|
@item 9 @tab 4
|
|||
|
|
@end multitable
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: Multiple USBasp or USBtinyISP programmers connected simultaneously are not
|
|||
|
|
found.
|
|||
|
|
|
|||
|
|
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 @var{-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 @var{-v} option.
|
|||
|
|
By specifying a string that cannot match any existing device
|
|||
|
|
(for example, @var{-P usb:xxx}), the scan will list all possible
|
|||
|
|
candidate devices found on the bus.
|
|||
|
|
|
|||
|
|
Examples:
|
|||
|
|
@example
|
|||
|
|
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)
|
|||
|
|
@end example
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: I cannot do @dots{} when the target is in debugWire mode.
|
|||
|
|
|
|||
|
|
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 @var{/RESET} line.
|
|||
|
|
DebugWire mode is initiated by activating the @var{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 ROM and EEPROM.
|
|||
|
|
It is also possible to read out the signature.
|
|||
|
|
All other memory areas cannot be accessed.
|
|||
|
|
There is no
|
|||
|
|
@emph{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
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: I want to use my JTAG ICE mkII to program an
|
|||
|
|
Xmega device through PDI. The documentation tells me to use the
|
|||
|
|
@emph{XMEGA PDI adapter for JTAGICE mkII} that is supposed to ship
|
|||
|
|
with the kit, yet I don't have it.
|
|||
|
|
|
|||
|
|
Solution: Use the following pin mapping:
|
|||
|
|
|
|||
|
|
@multitable @columnfractions .2 .2 .2 .2
|
|||
|
|
@item @strong{JTAGICE} @tab @strong{Target} @tab @strong{Squid cab-} @tab @strong{PDI}
|
|||
|
|
@item @strong{mkII probe} @tab @strong{pins} @tab @strong{le colors} @tab @strong{header}
|
|||
|
|
@item 1 (TCK) @tab @tab Black @tab
|
|||
|
|
@item 2 (GND) @tab GND @tab White @tab 6
|
|||
|
|
@item 3 (TDO) @tab @tab Grey @tab
|
|||
|
|
@item 4 (VTref) @tab VTref @tab Purple @tab 2
|
|||
|
|
@item 5 (TMS) @tab @tab Blue @tab
|
|||
|
|
@item 6 (nSRST) @tab PDI_CLK @tab Green @tab 5
|
|||
|
|
@item 7 (N.C.) @tab @tab Yellow @tab
|
|||
|
|
@item 8 (nTRST) @tab @tab Orange @tab
|
|||
|
|
@item 9 (TDI) @tab PDI_DATA @tab Red @tab 1
|
|||
|
|
@item 10 (GND) @tab @tab Brown @tab
|
|||
|
|
@end multitable
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: I want to use my AVR Dragon to program an
|
|||
|
|
Xmega device through PDI.
|
|||
|
|
|
|||
|
|
Solution: Use the 6 pin ISP header on the Dragon and the following pin mapping:
|
|||
|
|
|
|||
|
|
@multitable @columnfractions .2 .2
|
|||
|
|
@item @strong{Dragon} @tab @strong{Target}
|
|||
|
|
@item @strong{ISP Header} @tab @strong{pins}
|
|||
|
|
@item 1 (MISO) @tab PDI_DATA
|
|||
|
|
@item 2 (VCC) @tab VCC
|
|||
|
|
@item 3 (SCK) @tab
|
|||
|
|
@item 4 (MOSI) @tab
|
|||
|
|
@item 5 (RESET) @tab PDI_CLK / RST
|
|||
|
|
@item 6 (GND) @tab GND
|
|||
|
|
@end multitable
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: I want to use my AVRISP mkII to program an
|
|||
|
|
ATtiny4/5/9/10 device through TPI. How to connect the pins?
|
|||
|
|
|
|||
|
|
Solution: Use the following pin mapping:
|
|||
|
|
|
|||
|
|
@multitable @columnfractions .2 .2 .2
|
|||
|
|
@item @strong{AVRISP} @tab @strong{Target} @tab @strong{ATtiny}
|
|||
|
|
@item @strong{connector} @tab @strong{pins} @tab @strong{pin #}
|
|||
|
|
@item 1 (MISO) @tab TPIDATA @tab 1
|
|||
|
|
@item 2 (VTref) @tab Vcc @tab 5
|
|||
|
|
@item 3 (SCK) @tab TPICLK @tab 3
|
|||
|
|
@item 4 (MOSI) @tab @tab
|
|||
|
|
@item 5 (RESET) @tab /RESET @tab 6
|
|||
|
|
@item 6 (GND) @tab GND @tab 2
|
|||
|
|
@end multitable
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: I want to program an ATtiny4/5/9/10 device using a serial/parallel
|
|||
|
|
bitbang programmer. How to connect the pins?
|
|||
|
|
|
|||
|
|
Solution: Since TPI has only 1 pin for bi-directional data transfer, both
|
|||
|
|
@var{MISO} and @var{MOSI} pins should be connected to the @var{TPIDATA} pin
|
|||
|
|
on the ATtiny device.
|
|||
|
|
However, a 1K resistor should be placed between the @var{MOSI} and @var{TPIDATA}.
|
|||
|
|
The @var{MISO} pin connects to @var{TPIDATA} directly.
|
|||
|
|
The @var{SCK} pin is connected to @var{TPICLK}.
|
|||
|
|
|
|||
|
|
In addition, the @var{Vcc}, @var{/RESET} and @var{GND} pins should
|
|||
|
|
be connected to their respective ports on the ATtiny device.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: How can I use a FTDI FT232R USB-to-Serial device for bitbang programming?
|
|||
|
|
|
|||
|
|
Solution: When connecting the FT232 directly to the pins of the target Atmel device,
|
|||
|
|
the polarity of the pins defined in the @code{programmer} definition should be
|
|||
|
|
inverted by prefixing a tilde. For example, the @var{dasa} programmer would
|
|||
|
|
look like this when connected via a FT232R device (notice the tildes in
|
|||
|
|
front of pins 7, 4, 3 and 8):
|
|||
|
|
|
|||
|
|
@example
|
|||
|
|
programmer
|
|||
|
|
id = "dasa_ftdi";
|
|||
|
|
desc = "serial port banging, reset=rts sck=dtr mosi=txd miso=cts";
|
|||
|
|
type = serbb;
|
|||
|
|
reset = ~7;
|
|||
|
|
sck = ~4;
|
|||
|
|
mosi = ~3;
|
|||
|
|
miso = ~8;
|
|||
|
|
;
|
|||
|
|
@end example
|
|||
|
|
|
|||
|
|
Note that this uses the FT232 device as a normal serial port, not using the
|
|||
|
|
FTDI drivers in the special bitbang mode.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: My ATtiny4/5/9/10 reads out fine, but any attempt to program
|
|||
|
|
it (through TPI) fails. Instead, the memory retains the old contents.
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: My ATxmega@dots{}A1/A2/A3 cannot be programmed through PDI with
|
|||
|
|
my AVR Dragon. Programming through a JTAG ICE mkII works though, as does
|
|||
|
|
programming through JTAG.
|
|||
|
|
|
|||
|
|
Solution: None by this time (2010 Q1).
|
|||
|
|
|
|||
|
|
It is said that the AVR Dragon can only program devices from the A4
|
|||
|
|
Xmega sub-family.
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: when programming with an AVRISPmkII or STK600, AVRDUDE hangs
|
|||
|
|
when programming files of a certain size (e.g. 246 bytes). Other
|
|||
|
|
(larger or smaller) sizes work though.
|
|||
|
|
|
|||
|
|
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: @url{http://www.libusb.org/ticket/6}
|
|||
|
|
|
|||
|
|
@item
|
|||
|
|
Problem: after flashing a firmware that reduces the target's clock
|
|||
|
|
speed (e.g. through the @code{CLKPR} register), further ISP connection
|
|||
|
|
attempts fail.
|
|||
|
|
|
|||
|
|
Solution: Even though ISP starts with pulling @var{/RESET} low, the
|
|||
|
|
target continues to run at the internal clock speed as defined by the
|
|||
|
|
firmware running before. 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 @emph{chip erase} using the slow ISP clock
|
|||
|
|
(option @code{-e}), and then start a new session at higher speed.
|
|||
|
|
Option @code{-D} might be used there, to prevent another unneeded
|
|||
|
|
erase cycle.
|
|||
|
|
|
|||
|
|
@end itemize
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
@bye
|
|||
|
|
|