| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Extended parameters are programmer-specific options; they all start with
-x. Generally, each programmer will allow -x help, which
will show a help menu of known extended parameters for this programmer, if
any, and exit. The extended parameters below are all shown without the
necessary -x option lead-in. AVRDUDE allows any number of -x
extended parameters to be specified on the command line.
dryrundrybootBoth dryrun and dryboot programmers emulate programming and accept the following parameters:
initInitialise memories with human-readable patterns. Flash memory will be
randomly configured with respect to bootloader, data and code length.
Patterns can best be seen with fixed-width font and the :I format
by inspecting the generated hex file or by using, eg, -U
flash:r:-:I. Patterns in flash memory are executable and represent benign
AVR code, ie, no I/O memory access. Choose a fixed seed for reproducible
results.
init=<n>Shortcut for -x init -x seed=<n> (see below)
randomInitialise memories with random code and values. Flash memory will be randomly configured with respect to bootloader, data and code length. Random code in flash will be benign, that is, not accessing I/O memories, SRAM or flash. Choose a fixed seed for reproducible results.
random=<n>Shortcut for -x random -x seed=<n>
seed=<n>Seed random number generator with n; the default is
time(NULL). Setting this option with a fixed positive n will
make the random choices reproducible, ie, they will stay the same between
different avrdude runs.
JTAG ICE mkII/3Atmel-ICEPICkit 4MPLAB(R) SNAPPower DebuggerAVR DragonWhen using the JTAG ICE mkII, JTAGICE3, Atmel-ICE, PICkit 4, MPLAB(R) SNAP, Power Debugger or AVR Dragon in JTAG mode, the following extended parameter is accepted:
jtagchain=UB,UA,BB,BASetup the JTAG scan chain for UB units before, UA units after, BB bits before, and BA bits after the target AVR, respectively. Each AVR unit within the chain shifts by 4 bits. Other JTAG units might require a different bit shift count.
hvupdiPower Debugger and Pickit 4 only
High-voltage UPDI programming is used to enable a UPDI pin that has previously
been set to RESET or GPIO mode. Use -x hvupdi to enable high-voltage UPDI
initialization for supported targets.
vtarg=VALUE, vtargPower Debugger only
The voltage generator can be enabled by setting a target voltage.
The current set-voltage can be read by -x vtarg alone.
PICkit 4MPLAB(R) SNAPThe PICkit 4 and MPLAB(R) SNAP programmers accept the following extended parameters:
mode=avr,picSwitch programmer to AVR or PIC mode, then exit: the PICkit 4 and MPLAB(R) SNAP
programmer can only be utilised by Avrdude when in AVR mode.
Use -x mode=avr for switching to AVR mode, or -x mode=pic
for switching to PIC mode.
PICkit 5PICkit 4 (PIC Mode)The PICkit 5 and PICkit 4 (PIC Mode) programmer can accept following extended parameters
vtarg=VALUESpecify a voltage between 1.8 and 5.5 V that the programmer should supply to the target. If there is already a valid voltage applied to the VTG Pin, this setting will be ignored. When AVRDUDE detects an external voltage outside of this range, it will terminate the operation. You can disable this by setting the voltage to 0 V.
hvupdiHigh-voltage UPDI programming is used to enable a UPDI pin that has previously
been set to RESET or GPIO mode. Use -x hvupdi to enable high-voltage UPDI
initialization for supported targets. Depending on the target, the HV pulse will
be applied either on the RST pin, or the UPDI pin.
Xplained MiniThe Xplained Mini/Nano programmer (ISP or UPDI, not TPI) type accepts the following extended parameters:
suffer=VALUE, sufferThe SUFFER register allows the user to modify the behavior of the on-board mEDBG.
The current state can be read by -x suffer alone.
Bit 7 ARDUINO:Adds control of extra LEDs when set to 0
Bit 6..3:Reserved (must be set to 1)
Bit 2 EOF:Agressive power-down, sleep after 5 seconds if no USB enumeration when set to 0
Bit 1 LOWP:forc running the mEDBG at 1 MHz when bit set to 0
Bit 0 FUSE:Fuses are safe-masked when bit sent to 1. Fuses are unprotected when set to 0
vtarg_switch=VALUE, vtarg_switchThe on-board target voltage switch can be turned on or off by writing a 1 or
a 0. The current state can be read by -x vtarg_switch alone.
Note that the target power switch will always be on after a power cycle.
Also note that the smaller Xplained Nano boards does not have a target power switch.
Curiosity NanoThe Curiosity Nano board accepts the following extended parameter:
vtarg=VALUE, vtargThe generated on-board target voltage can be changed by specifying a new voltage.
The current set-voltage can be read by -x vtarg alone.
STK500STK600The STK500 and STK600 boards accept the following extended parameters:
vtarg=VALUE, vtargThe generated on-board target voltage can be changed by specifying a new voltage.
The current set-voltage can be read by -x vtarg alone.
fosc=VALUE[MHz|M|kHz|k|Hz|H], foscSet the programmable oscillator frequency in MHz, kHz or Hz.
The current frequency can be read by -x fosc alone.
varef=VALUE, varefThe generated on-board analog reference voltage can be changed by specifying
a new reference voltage. The current reference voltage can be read by
-x varef alone.
varef[0,1]=VALUE, varef[0,1]STK600 only
The generated on-board analog reference voltage for channel 0 or channel 1 can
be changed by specifying a new reference voltage.
The current reference voltage can be read by -x varef0 or
-x varef1 alone.
attempts[=<1..99>]STK500V1 only
Specify how many connection retry attempts to perform before exiting.
Defaults to 10 if not specified.
xtal=VALUE[MHz|M|kHz|k|Hz|H]Defines the XTAL frequency of the programmer if it differs from 7.3728 MHz of the original STK500. Used by avrdude for the correct calculation of fosc and sck.
AVR109The AVR109 programmer type accepts the following extended parameter:
autoresetToggle RTS/DTR lines on port open to issue a hardware reset.
AVR910The Atmel low-cost AVR910 programmer type accepts the following extended parameter:
devcode=VALUEOverride the device code selection by using VALUE
as the device code.
The programmer is not queried for the list of supported
device codes, and the specified VALUE
is not verified but used directly within the
T command sent to the programmer.
VALUE can be specified using the conventional number notation of the
C programming language.
no_blockmodeDisables the default checking for block transfer capability.
Use
no_blockmode only if your AVR910
programmer creates errors during initial sequence.
ArduinoThe Arduino programmer type accepts the following extended parameter:
attempts[=<1..99>]Specify how many connection retry attempts to perform before exiting. Defaults to 10 if not specified.
noautoresetDo not toggle RTS/DTR lines on port open to prevent a hardware reset.
UrclockThe urclock programmer type accepts the following extended parameters:
showallShow all info for the connected part, then exit. The -x show... options
below can be used to assemble a bespoke response consisting of a subset
(or only one item) of all available relevant information about the
connected part and bootloader.
showidShow a unique Urclock ID stored in either flash or EEPROM of the MCU, then exit.
id=<E|F>.<addr>.<len>Historically, the Urclock ID was a six-byte unique little-endian number
stored in Urclock boards at EEPROM address 257. The location of this
number can be set by the -x id=<E|F>.<addr>.<len> extended parameter. E
stands for EEPROM and F stands for flash. A negative address addr counts
from the end of EEPROM and flash, respectively. The length len of the
Urclock ID can be between 1 and 8 bytes.
showdateShow the last-modified date of the input file for the flash application,
then exit. If the input file was stdin, the date will be that of the
programming. Date and filename are part of the metadata that the urclock
programmer stores by default in high flash just under the bootloader; see also
-x nometadata.
showfilenameShow the input filename (or title) of the last flash writing session, then exit.
title=<string>When set, <string> will be used in lieu of the input filename. The maximum string length for the title/filename field is 254 bytes including terminating nul.
showappshowstoreShow the size of the unused flash between the application and metadata, then exit.
showmetaShow the size of the metadata just below the bootloader, then exit.
showbootShow the size of the bootloader, then exit.
showversionShow bootloader version and capabilities, then exit.
showvectorShow the vector number and name of the interrupt table vector used by the
bootloader for starting the application, then exit. For hardware-supported
bootloaders this will be vector 0 (Reset), and for vector bootloaders this
will be any other vector number of the interrupt vector table or the slot
just behind the vector table with the name VBL_ADDITIONAL_VECTOR.
showpartShow the part for which the bootloader was compiled, then exit.
bootsize=<size>Manual override for bootloader size. Urboot bootloaders put the number of used bootloader pages into a table at the top of the bootloader section, i.e., typically top of flash, so the urclock programmer can look up the bootloader size itself. In backward-compatibility mode, when programming via other bootloaders, this option can be used to tell the programmer the size, and therefore the location, of the bootloader.
vectornum=<n>Manual override for vector number. Urboot bootloaders put the vector number used by a vector bootloader into a table at the top of flash, so this option is normally not needed for urboot bootloaders. However, it is useful in backward-compatibility mode (or when the urboot bootloader does not offer flash read). Specifying a vector number in these circumstances implies a vector bootloader whilst the default assumption would be a hardware-supported bootloader.
eepromrwManual override for asserting EEPROM read/write capability. Not normally needed for urboot bootloaders, but useful for in backward-compatibility mode if the bootloader offers EEPROM read/write.
emulate_ceIf an urboot bootloader does not offer a chip erase command it will tell the urclock programmer so during handshake. In this case the urclock programmer emulates a chip erase, if warranted by user command line options, by filling the remainder of unused flash below the bootloader with 0xff. If this option is specified, the urclock programmer will assume that the bootloader cannot erase the chip itself. The option is useful for backwards-compatible bootloaders that do not implement chip erase.
restoreWrite unchanged flash input files to the AVR and trim below the bootloader if
needed. This is most useful when one has a backup of the full flash and
wants to play that back onto the device. No metadata are written in this
case and no vector patching happens either if it is a vector bootloader.
However, for vector bootloaders, even under the option -x restore an
input file will not be written to the AVR for which the reset vector does not point
to the vector bootloader. This is to avoid loading an input file onto the
device that would render the vector bootloader becoming unreachable after reset.
initstoreOn writing to flash fill the store space between the flash application and the metadata section with 0xff.
nofilenameOn writing to flash do not store the application input filename (nor a title).
nodateOn writing to flash do not store the application input filename (nor a title) and no date either.
nostoreOn writing to flash do not store metadata except the metadata code byte
0xff saying there are no metadata. In particular, no data store
frame is programmed.
nometadataDo not support any metadata. The full flash besides the bootloader is
available for the application. If the application is smaller than the
available space then a metadata code byte 0xff is stored
nevertheless to indicate there are no further metadata available. In
absence of -x nometadata, the default for the urclock programmer is
to write as much metadata (filename, data and store information) as the
size of the application and the other extended options allow. The
subtle difference between -x nometadata and -x nostore is that
the latter always explicitly stores in flash that no further metadata are
available, so that a such prepared flash can always be queried with
avrdude -x showall. In contrast to this, it cannot be guaranteed
that a -x showall query on flash prepared with -x nometadata
yields useful results.
noautoresetDo not toggle RTS/DTR lines on port open to prevent a hardware reset.
delay=<n>Add a <n> ms delay after reset. This can be useful if a board takes a particularly long time to exit from external reset. <n> can be negative, in which case the default 120 ms delay after issuing reset will be shortened accordingly.
strictUrclock has a faster, but slightly different strategy than -c arduino to
synchronise with the bootloader; some stk500v1 bootloaders cannot cope
with this, and they need the -x strict option.
BusPirateThe BusPirate programmer type accepts the following extended parameters:
reset=cs,aux,aux2The default setup assumes the BusPirate’s CS output pin connected to the RESET pin on AVR side. It is however possible to have multiple AVRs connected to the same BP with SDI, SDO and SCK lines common for all of them. In such a case one AVR should have its RESET connected to BusPirate’s CS pin, second AVR’s RESET connected to BusPirate’s AUX pin and if your BusPirate has an AUX2 pin (only available on BusPirate version v1a with firmware 3.0 or newer) use that to activate RESET on the third AVR.
It may be a good idea to decouple the BusPirate and the AVR’s SPI buses from each other using a 3-state bus buffer. For example 74HC125 or 74HC244 are some good candidates with the latches driven by the appropriate reset pin (cs, aux or aux2). Otherwise the SPI traffic in one active circuit may interfere with programming the AVR in the other design.
spifreq=0..70 | 30 kHz (default) |
1 | 125 kHz |
2 | 250 kHz |
3 | 1 MHz |
4 | 2 MHz |
5 | 2.6 MHz |
6 | 4 MHz |
7 | 8 MHz |
rawfreq=0..3Sets the SPI speed and uses the Bus Pirate’s binary “raw-wire” mode instead of the default binary SPI mode:
0 | 5 kHz |
1 | 50 kHz |
2 | 100 kHz (Firmware v4.2+ only) |
3 | 400 kHz (v4.2+) |
The only advantage of the “raw-wire” mode is that different SPI frequencies are available. Paged writing is not implemented in this mode.
pullupsEnable the Bus Pirate’s built-in pull-up resistors. These resistors are useful when working with different voltage levels. VPU pin of the Bus Pirate must be connected to an external voltage. For example: connect VPU pin to the +5V pin or an external power supply.
hizEnable the Bus Pirate’s HiZ mode on SPI, allowing it to work as an open-collector and interface with external pull-up circuits. If the external target circuit does not have pull-ups, the Bus Pirate will not be able to send data.
asciiAttempt to use ASCII mode even when the firmware supports BinMode (binary
mode).
BinMode is supported in firmware 2.7 and newer, older FW’s either don’t
have BinMode or their BinMode is buggy. ASCII mode is slower and makes
the above
reset=, spifreq=
and
rawfreq=
parameters unavailable. Be aware that ASCII mode is not guaranteed to work
with newer firmware versions, and is retained only to maintain compatibility
with older firmware versions.
nopagedwriteFirmware versions 5.10 and newer support a binary mode SPI command that enables whole pages to be written to AVR flash memory at once, resulting in a significant write speed increase. If use of this mode is not desirable for some reason, this option disables it.
nopagedreadNewer firmware versions support in binary mode SPI command some AVR Extended Commands. Using the “Bulk Memory Read from Flash” results in a significant read speed increase. If use of this mode is not desirable for some reason, this option disables it.
cpufreq=125..4000This sets the AUX pin to output a frequency of n kHz. Connecting the AUX pin to the XTAL1 pin of your MCU, you can provide it a clock, for example when it needs an external clock because of wrong fuses settings. Make sure the CPU frequency is at least four times the SPI frequency.
serial_recv_timeout=1...This sets the serial receive timeout to the given value. The timeout happens every time avrdude waits for the BusPirate prompt. Especially in ascii mode this happens very often, so setting a smaller value can speed up programming a lot. The default value is 100 ms. Using 10 ms might work in most cases.
Micronucleus bootloaderThe Micronucleus programmer type accepts the following extended parameter:
wait=timeoutIf the device is not connected, wait for the device to be plugged in. The optional timeout specifies the connection time-out in seconds. If no time-out is specified, AVRDUDE will wait indefinitely until the device is plugged in.
Teensy bootloaderThe Teensy programmer type accepts the following extended parameter:
wait=timeoutIf the device is not connected, wait for the device to be plugged in. The optional timeout specifies the connection time-out in seconds. If no time-out is specified, AVRDUDE will wait indefinitely until the device is plugged in.
WiringThe Wiring programmer type accepts the following extended parameters:
snooze=<n>After performing the port open phase, AVRDUDE will wait/snooze for snooze milliseconds before continuing to the protocol sync phase. No toggling of DTR/RTS is performed if snooze > 0.
delay=<n>Add a <n> milliseconds delay after reset. This can be useful if a board takes a particularly long time to exit from external reset. <n> can be negative, in which case the default 100 ms delay after issuing reset will be shortened accordingly.
PICkit2Connection to the PICkit2 programmer:
(AVR) | (PICkit2) |
RST | VPP/MCLR (1) |
VDD | VDD Target (2) -- possibly optional if AVR self powered |
GND | GND (3) |
SDI | PGD (4) |
SCLK | PDC (5) |
OSI | AUX (6) |
The PICkit2 programmer type accepts the following extended parameters:
clockrate=rateSets the SPI clocking rate in Hz (default is 100kHz). Alternately the -B or -i options can be used to set the period.
timeout=usb-transaction-timeoutSets the timeout for USB reads and writes in milliseconds (default is 1500 ms).
USBaspThe USBasp programmer type accepts the following extended parameter:
section_configProgrammer will erase configuration section with option ’-e’ (chip erase), rather than entire chip. Only applicable to TPI devices (ATtiny 4/5/9/10/20/40).
xbeeThe xbee programmer type accepts the following extended parameter:
xbeeresetpin=1..7Select the XBee pin DIO<1..7> that is connected to the MCU’s
/RESET line. The programmer needs to know which DIO pin to use to
reset into the bootloader. The default (3) is the DIO3 pin
(XBee pin 17), but some commercial products use a different XBee
pin.
The remaining two necessary XBee-to-MCU connections are not selectable
- the XBee DOUT pin (pin 2) must be connected to the MCU’s
RXD line, and the XBee DIN pin (pin 3) must be connected to
the MCU’s TXD line.
jtag2updiserialupdiThe jtag2updi and serialupdi programmer types accept the following extended parameters:
rtsdtr=low,highForces RTS/DTR lines to assume low or high state during the whole programming session. Some programmers might use this signal to indicate UPDI programming state, but this is strictly hardware specific.
When not provided, driver/OS default value will be used.
linuxspiThe linuxspi programmer type accepts the following extended parameter:
disable_no_csEnsures the programmer does not use the SPI_NO_CS bit for the SPI driver. This parameter is useful for kernels that do not support the CS line being managed outside the application.
serprogThe serprog programmer type accepts the following extended parameter:
csSets the chip select (CS) to use on supported programmers. Programmers supporting the 0x16 serprog command can have more than the default CS (0). This option allows to choose these additional CSes (1, 2, ...) for programming the AVR.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Stefan Rueger on August 24, 2024 using texi2html 1.82.